Remove

-----Original Message-----
From: nginx-request@nginx.org [mailto:nginx-request@nginx.org]
Sent: Thursday, April 21, 2011 4:00 AM
To: nginx@nginx.org
Subject: nginx Digest, Vol 18, Issue 55

Send nginx mailing list submissions to
nginx@nginx.org

To subscribe or unsubscribe via the World Wide Web, visit
http://nginx.org/mailman/listinfo/nginx
or, via email, send a message with subject or body 'help' to
nginx-request@nginx.org

You can reach the person managing the list at
nginx-owner@nginx.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of nginx digest..."


Today's Topics:

1. Re: Block SQL Injection (Cliff Wells)
2. Re: Block SQL Injection (Edho P Arief)
3. Re: Block SQL Injection (Cliff Wells)
4. Re: Upload Progress Issue -- do not have "uploading" state
(Yanxin Z.)
5. Re: Upload Progress Issue -- do not have "uploading" state
(Yanxin Z.)
6. Re: Upload Progress Issue -- do not have "uploading" state
(Yanxin Z.)
7. Re: Upload Progress Issue -- do not have "uploading" state
(Yanxin Z.)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Apr 2011 20:31:43 -0700
From: Cliff Wells <cliff@develix.com>
To: nginx@nginx.org
Subject: Re: Block SQL Injection
Message-ID: <1303356703.10898.184.camel@portable-evil>
Content-Type: text/plain; charset="UTF-8"

On Wed, 2011-04-20 at 20:07 -0700, Payam Chychi wrote:
> I was easy... So you would use some admins stupidity to backup 23
> years of experience?

The fact that it happened to be the admin who was inept only made the attack
simpler and more direct. It could have been any user's account.

Any and all information is valuable in compromising a system. Databases are
not only a source, but often the primary source of such information.

> That makes no sense to me but hey its ok, its the internet after all

Yes, I'm aware it's often a veritable race to the bottom, no need to
demonstrate.

> Hope you find an answer to your problem

I don't have any problems that I've aired in this thread, but thanks.

Cliff





------------------------------

Message: 2
Date: Thu, 21 Apr 2011 10:40:42 +0700
From: Edho P Arief <edhoprima@gmail.com>
To: nginx@nginx.org
Subject: Re: Block SQL Injection
Message-ID: <BANLkTi=5Sr8g9Ovo5J_KXVRa-BYcH8MjHA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 21, 2011 at 8:36 AM, Cliff Wells <cliff@develix.com> wrote:
> Easy. What data does your database store? Quite probably usernames and
> passwords. A fundamental truth is that people often use the same
> passwords for multiple services. If you can obtain the password for a
> company's CMS or Webmail application, chances are you now have their
> password for multiple services.
>

There is a good reason why bcrypt is recommended as password hashing method.



------------------------------

Message: 3
Date: Wed, 20 Apr 2011 20:59:05 -0700
From: Cliff Wells <cliff@develix.com>
To: nginx@nginx.org
Subject: Re: Block SQL Injection
Message-ID: <1303358345.10898.192.camel@portable-evil>
Content-Type: text/plain; charset="UTF-8"

On Thu, 2011-04-21 at 10:40 +0700, Edho P Arief wrote:
> On Thu, Apr 21, 2011 at 8:36 AM, Cliff Wells <cliff@develix.com> wrote:
> > Easy. What data does your database store? Quite probably usernames
> > and passwords. A fundamental truth is that people often use the same
> > passwords for multiple services. If you can obtain the password for
> > a company's CMS or Webmail application, chances are you now have
> > their password for multiple services.
> >
>
> There is a good reason why bcrypt is recommended as password hashing
method.

Yes, adaptive hashes are a huge improvement over the raw MD5/SHA hashes so
many people still use. Still, it's best if no one gains access to even try.


Also, for certain application domains, even if you don't crack the
passwords, just gaining access via SQL injection can lead to immediate
system compromise (hosting control panels, system monitoring tools, etc).

Regards,
Cliff





------------------------------

Message: 4
Date: Thu, 21 Apr 2011 06:46:19 +0200
From: "Yanxin Z." <lists@ruby-forum.com>
To: nginx@nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <a7ee656e082c754c2e8b1b2c84137e37@ruby-forum.com>
Content-Type: text/plain; charset=UTF-8

Hello Martin,
Thank you for your reply.
I tried with your suggestion on your blog, with 0.8.2 However, I have
initial error from beginning.

nginx: [emerg] no "events" section in configuration

Another thing is I use fastcgi to process PHP request.
In your blog, I do not see fastcgi backend.

I also tried 0.8.2 with my previous config, no good luck either.

Could you take a look at my config. I really do not know where "uploading"
state come from. Could you give me some hint?


Thanks,
Yanxin

--
Posted via http://www.ruby-forum.com/.



------------------------------

Message: 5
Date: Thu, 21 Apr 2011 08:24:06 +0200
From: "Yanxin Z." <lists@ruby-forum.com>
To: nginx@nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <cce057a824c28cabb14bb083d4ccfd5c@ruby-forum.com>
Content-Type: text/plain; charset=UTF-8

I print out the debug


2021 2011/04/20 17:28:07 [debug] 28372#0: *6 http script var:
"/opt/nginx/html/api/1.0/web/ upload_internal/"
2022 2011/04/20 17:28:07 [debug] 28372#0: *6 http script copy: "^@"
2023 2011/04/20 17:28:07 [debug] 28372#0: *6 http script file op
0000000000000005 "/opt/nginx/ html/api/1.0/web/upload_internal/"
2024 2011/04/20 17:28:07 [debug] 28372#0: *6 http script if
2025 2011/04/20 17:28:07 [debug] 28372#0: *6 http script regex:
"(.*)/upload$"
2026 2011/04/20 17:28:07 [notice] 28372#0: *6 "(.*)/upload$" does not
match "/api/1.0/web/ upload_internal/", client: 10.31.1.100,
server: localhost, request: "POST /api/1.0/web/
upload_internal/?X-Progress-ID=db298fe5d036a8ae19d2a55b9d1d0ca9
HTTP/1.1", host: "10.1.4. 243", referrer:
"https://10.1.4.243/api/1.0/web/upload"
2027 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: "/"
2028 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: "progress"
2029 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: "50x.html"
2030 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: ~
"/api/1.0/web/upload.php"
2031 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: ~
"/api/1.0/web/.*php$"
2032 2011/04/20 17:28:07 [debug] 28372#0: *6 test location: ~
"/api/1.0/web/upload_internal"
2033 2011/04/20 17:28:07 [debug] 28372#0: *6 using configuration
"/api/1.0/web/upload_internal"
2034 2011/04/20 17:28:07 [debug] 28372#0: *6 http cl:29308 max:10485760
2035 2011/04/20 17:28:07 [debug] 28372#0: *6 rewrite phase: 2
2036 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress:
get_tracking_id
2037 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress:
get_tracking_id no header found
2038 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress:
get_tracking_id no header found, args found
2039 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress:
get_tracking_id found args: X-
Progress-ID=db298fe5d036a8ae19d2a55b9d1d0ca9 HTTP/1.1^M
2040 Host
2041 2011/04/20 17:28:07 [debug] 28372#0: *6 malloc: 0000000010B7CF40:16
2042 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress:
get_tracking_id found args: db298fe5d036a8ae19d2a55b9d1d0ca9
2043 2011/04/20 17:28:07 [debug] 28372#0: *6 trackuploads id found:
db298fe5d036a8ae19d2a55b9d1d0ca9
2044 2011/04/20 17:28:07 [debug] 28372#0: *6 trackuploads hash 5351D33B
for id: db298fe5d036a8ae19d2a55b9d1d0ca9
2045 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress: find_node
db298fe5d036a8ae19d2a55b9d1d0ca9
2046 2011/04/20 17:28:07 [debug] 28372#0: *6 upload-progress: can't find
node
2047 2011/04/20 17:28:07 [debug] 28372#0: *6 add cleanup:
0000000010B7F670
2048 2011/04/20 17:28:07 [debug] 28372#0: slab alloc: 136 slot: 5
2049 2011/04/20 17:28:07 [debug] 28372#0: slab alloc: 00002B65BDE08000
2050 2011/04/20 17:28:07 [debug] 28372#0: *6 trackuploads: 5351D33B
inserted in rbtree
2051 2011/04/20 17:28:07 [debug] 28372#0: event timer add: 7:
15000:1303345702489
2052 2011/04/20 17:28:07 [debug] 28372#0: *6 rewrite phase: 3
2053 2011/04/20 17:28:07 [debug] 28372#0: *6 http script var
2054 2011/04/20 17:28:07 [debug] 28372#0: *6 http script var: "POST"
2055 2011/04/20 17:28:07 [debug] 28372#0: *6 http script value: "POST"
2056 2011/04/20 17:28:07 [debug] 28372#0: *6 http script equal

I look at the code, in find_node(), I find out node and sentinel are
NULL.
So it does not go into while loop.

350 static ngx_http_uploadprogress_node_t *
351 find_node(ngx_str_t * id, ngx_http_uploadprogress_ctx_t * ctx,
ngx_log_t * log)
352 {
353 uint32_t hash;
354 ngx_rbtree_node_t *node, *sentinel;
355 ngx_int_t rc;
356 ngx_http_uploadprogress_node_t *up;
357
358 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, log, 0, "upload-progress:
find_node %V", id);
359
360 hash = ngx_crc32_short(id->data, id->len);
361
362 node = ctx->rbtree->root;
363 sentinel = ctx->rbtree->sentinel;
364
365 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, log, 0, "upload-progress:
node: %V sentinel: %V", node, sentinel);
366
367 while (node != sentinel) {
368
369 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, log, 0,
"upload-progress: hash: %V node->key: %V", hash, node->key);
370 if (hash < node->key) {
371
372 node = node->left;
373 continue;
374 }
375
376 if (hash > node->key) {
377 node = node->right;
378 continue;
379 }
380
381 /* hash == node->key */
382
383 do {
384
385 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, log, 0,
"upload-progress: In while");
386 up = (ngx_http_uploadprogress_node_t *) node;
387
388 rc = ngx_memn2cmp(id->data, up->data, id->len, (size_t)
up->len);
389
390 if (rc == 0) {
391 ngx_log_debug0(NGX_LOG_DEBUG_HTTP, log, 0,
392 "upload-progress: found node");
393 return up;
394 }


I want to know which function to initialize node and sentinel.

--
Posted via http://www.ruby-forum.com/.



------------------------------

Message: 6
Date: Thu, 21 Apr 2011 09:09:07 +0200
From: "Yanxin Z." <lists@ruby-forum.com>
To: nginx@nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <de68c313d0cea7eadd6fb117755ff7f6@ruby-forum.com>
Content-Type: text/plain; charset=UTF-8

I did some debug, and realize ngx_http_uploadprogress_event_handler() is
never been called.

That's the reason I see starting and done state, but never see
"uploading" state.

I want to know which nginx configure and html part will call

ngx_http_uploadprogress_event_handler

Thanks,
Yanxin

--
Posted via http://www.ruby-forum.com/.



------------------------------

Message: 7
Date: Thu, 21 Apr 2011 09:23:26 +0200
From: "Yanxin Z." <lists@ruby-forum.com>
To: nginx@nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <19b67b8df0d3023b42d8c69d7c908d48@ruby-forum.com>
Content-Type: text/plain; charset=UTF-8

One possible reason is I am using track_uploads on default port 80,
however, the fastcgi in my config is using port 9000.

Could anyone tell me how to monitor port 9000 in upload progress?

Thanks,
Yanxin

--
Posted via http://www.ruby-forum.com/.



------------------------------

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx


End of nginx Digest, Vol 18, Issue 55
*************************************



_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx