remove

Webservant at COGNWM.ORG webservant at cognwm.org
Thu Apr 21 16:03:37 MSD 2011


Remove

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

Send nginx mailing list submissions to
	nginx at 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 at nginx.org

You can reach the person managing the list at
	nginx-owner at 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 at develix.com>
To: nginx at nginx.org
Subject: Re: Block SQL Injection
Message-ID: <1303356703.10898.184.camel at 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 at gmail.com>
To: nginx at nginx.org
Subject: Re: Block SQL Injection
Message-ID: <BANLkTi=5Sr8g9Ovo5J_KXVRa-BYcH8MjHA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 21, 2011 at 8:36 AM, Cliff Wells <cliff at 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 at develix.com>
To: nginx at nginx.org
Subject: Re: Block SQL Injection
Message-ID: <1303358345.10898.192.camel at 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 at 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 at ruby-forum.com>
To: nginx at nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <a7ee656e082c754c2e8b1b2c84137e37 at 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 at ruby-forum.com>
To: nginx at nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <cce057a824c28cabb14bb083d4ccfd5c at 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 at ruby-forum.com>
To: nginx at nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <de68c313d0cea7eadd6fb117755ff7f6 at 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 at ruby-forum.com>
To: nginx at nginx.org
Subject: Re: Upload Progress Issue -- do not have "uploading" state
Message-ID: <19b67b8df0d3023b42d8c69d7c908d48 at 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 at nginx.org
http://nginx.org/mailman/listinfo/nginx


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





More information about the nginx mailing list