[WEB SECURITY] XSS filter Bypass

[Appsec User]

Hi Achim,

Thanks for your response! Yes I tried for recursive payloads

<s<cript
  <s<script>cript
  <script<script
  <sc<sc<sc<sc<sc<sc<script>ript>ript>ript>ript>ript>ript>

Actually as per my understanding just when filter sees a character
after < it sends 302 redirect except if the character is space or %,
for % it URL decodes and then checks I  guess.

It was not double 's its <%73cript'. My mistake.

How did you confirmed that filtering is happening at application
server layer. So is it like Webserver is url decoding and then
appserver is doing the filtering? Why I am getting different message
with double URL encoding, Is it like Webserver is URL decoding and
Later AppSever is not expecting URL encoded string and hence throwing
500 error message "The request is rejected by HTTP Filter."

I am targeting IIS server and was looking to leverage HPP for XSS but
it adds a comma in between so my script comes back as <,script If I
provide redundand parameter value as < and script.

Is there any other way I can try?



On 6/19/12, Achim Hoffmann <websec10 at sic-sec.org> wrote:
> 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.
>
>
>