[WEB SECURITY] XSS filter Bypass

Daniel Herrera daherrera101 at yahoo.com
Tue May 29 12:28:37 EDT 2012

My first email was half-assed, its early and I needed coffee...

Single encoding will test to see if the filter is applied prior to the value being unencoded or normalized through default behavior of the webserver/framework being used or custom cgi on the target application.


The example uses URL HEX encoding but I would check other encoding types as well.

Double encoding will test for several conditions: it will test to see if the unencoding or normalization done prior to the filter is recursive, or it will test to see if unencoding or normalization is done after the filter is applied to the value. The second condition is common any time user data crosses multiple environment boundaries, like in SOA environments or if its passed to a data storage layer prior to being accessed and returned to the user.


The example uses URL HEX encoding but I would check other encoding types as well, keep in mind you can mix and match the encoding type you use for each iteration they do not need to be the same as you are targeting functionally different portions of the cgi so the behavior could be very different.

An easy tool for doing multiple encoding types on a string is https://hackvertor.co.uk/public

I recommend that if you find yourself doing alot of blackbox testing, generate a set of test strings as well as the match conditions and save them as seperate files to load into the proxy of your choice, similar to fuzzdb. I also recommend you learn and use burp proxy.

Have fun.


--- On Thu, 5/24/12, Appsec User <pentestguy.cs at gmail.com> wrote:

> From: Appsec User <pentestguy.cs at gmail.com>
> Subject: [WEB SECURITY] XSS filter Bypass
> To: websecurity at lists.webappsec.org
> Date: Thursday, May 24, 2012, 3:16 AM
> Hi,
> I am probing for XSS in an application. Application has a
> filter which
> triggers if I put anything after less than sign '<'
> except space, %
> and >. So application accepts < character but only
> allows space, % and
> > after it. So e.g < script(note space in b/w) is
> allowed but <script
> will be rejected(no space). I have tested for various
> encoding also
> <%00script is allowed but it puts space between < and
> script and
> browser does not treat it as mark up. I cannot probe for
> javascript
> events as Payloads are reflecting in HTML context not in
> javascript
> context. Any suggestions how can I by-pass this filter.
> _______________________________________________
> The Web Security Mailing List
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> http://twitter.com/wascupdates
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

More information about the websecurity mailing list