[WEB SECURITY] XSS filter Bypass

[Achim Hoffmann]

Am 18.06.2012 08:57, schrieb Appsec User:
> Apologies for late reply, I tried for <<script..filter is
> recursive.

How does the filter define "recursive"? Have you tested with:
   <s<cript
   <s<script>cript
   <script<script
   <sc<sc<sc<sc<sc<sc<script>ript>ript>ript>ript>ript>ript>

<%73script and <%53scriptinvokes the filter with 302
> response.

Hmm, what is your intention with doubling the s ?

> <%2573 i.e double encoding gives 500 error with the message
> that "The request is rejected by HTTP Filter.."

Assuming you tested with  <%2573cript
Then I'd guess that the filter is not in the front-end web server, but
in the application (or the application server).


> This is different from
> standard filter behaviour so when I use <%73script filter redirects me
> to with 302 message with double encoding it throws 500 error with
> above message. Also I notice char-set is not defined in response. I am
> testing on IE8, Can I leverage this fact to test XSS. Can some one
> point me to place which can help me understand how and in which
> schenarios I should test for encoding like, UTF8/7 ASCII unicodeetc, I
> am really confused about these, not sure in which specific scenario I
> shoudl try these currently I just run burp intruder with every payload
> inside it but fails to understand the basic behind few of the
> encodings.

Up to now I don't see any charset dependencies as everything is plain
7-bit ASCII.
Things may be different if you use UTF-7 like
  +ADw-script
  +ADwAcwBjAHIAaQBwAHQ-

If you do that in the URL, the web server needs to be stupid enough to
accept and convert UTF-7 there. Otherwise it only makes sense in POSTed
data as there the server has been informed by the preceeding HTTP
header which charset to use.