[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH8yC8nRwocnpLsnTK0x4tpFQA3g7ouuOMR+fOp6k7pbkuxpcQ@mail.gmail.com>
Date: Tue, 26 Mar 2013 18:47:02 -0400
From: Jeffrey Walton <noloader@...il.com>
To: safe3q@...il.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Report OWASP WAF Naxsi bypass Vulnerability
Tracked through issue 65
(http://code.google.com/p/naxsi/issues/detail?id=65), fixed at
check-in R545 (http://code.google.com/p/naxsi/source/detail?spec=svn545&r=545).
On Mon, Mar 25, 2013 at 10:00 PM, <safe3q@...il.com> wrote:
> OWASP WAF Naxsi bypass Vulnerability
>
> Certain unspecified input is not properly handed in
> naxsi_src/naxsi_utils.c naxsi_unescape_uri(u_char **dst, u_char **src,
> size_t size, ngx_uint_t type) before being used to filtered. This can
> be exploited to bypass some WAF rules.
>
> Naxsi site
> https://code.google.com/p/naxsi/
>
> Affected
> All the version
>
> My site
> http://safe3.com.cn/
>
> My nick name is Safe3
>
> It happens like that,the naxsi_unescape_uri function process the % url
> decode,if the next char after the % is a hex char and not after the
> hex char,then it will drop the % and the next char.So if we input a
> sql keyword "s%elect",it will come to "slect" instead,this is not the
> standard url decode way.Such as the IIS asp,it will process the
> "s%elect" as a result of "select",so we can bypass some
> WAF rules just like that.
>
> I afford a standard url decode function patch as the follow to fix this issue:
> ...
Powered by blists - more mailing lists