Hi Andrés,

I'd start with following (the payload literaly):

    uniqew3afid"' foo=bar --><fooled app=//evil.tld/; >

The goal is to detect XSS in most variants, so how it works:
    uniqew3afid    - find payload in response (reflected)
    "'             - test if single and/or double quotes are encoded
                     a further check may be if the quotes are escaped
                     like \" (as PHP does) or &quot; and so on ...
    --             - check if HTML comments are injectable
                     Note: this also is a simple check if the payload
                     gets into some XML data
    <fooled >      - try simple HTML injection (aka content spoofing)
                     this is a invalid tag to avoid detection by stupid
                     filters
    app=           - check if we can inject tag attributes
    //evil.tld/    - check if atributes can have values *and* if it can
                     be a URL
    ;              - check if semicolon is escaped 
                     this is important to allow unquoted values serving
                     as valid JavaScript or CSS, like: onfocus=alert(42);

Depending on the results you get, you can start injecting other payloads.
Lucky shot:
    complete string unencode ==> game over, XSS fully exploitable

escaped quotes:
    continue with injections without quotes

escaped or removed angle braces:
    continue with tag or attribute injection

removed or mangled fooled tag:
    continue attribute injection and non-HTML injections like CSS or JS

If you have a vector with vulnerability types to be check, something like:

   vulns=(bracket,quote,attribute,tag,comment); // incomplete list

you can write a recursive loop over this vector and check again according
the results you get.

Just a rough idea ...

More comments below inline ...

Achim



Am 16.02.2012 21:21, schrieb Andres Riancho:
> Martin, Taras,
> 
>     While trying to code the new xss.py I've found myself in a
> situation where I see that it's difficult to cover all cases. Just to
> make sure we're talking about the same thing, what we're trying to do
> is to detect reflected XSS vulnerabilities with the lowest amount of
> HTTP requests, lowest false positive and false negative rate. This is
> the algorithm that I'm implementing and I would like to get your
> feedback on:
> 
>     * Send hN<97>97"97'97(97)hN  or a similar payload  [0]
>     * Analyze the HTML response and identify WHERE in the HTML
> structure the payload is echoed back and WHICH special characters were
> allowed in each context. The context is one or more of the following
> places (taking into account that the input might be echoed more than
> once):
>             TAG
>             ATTR_NAME
>             ATTR_DOUBLE_QUOTE
>             ATTR_SINGLE_QUOTE
>             TEXT
>             COMMENT
>             SCRIPT
>             CDATA

I don't see a reason for CDATA as long as we're in HTML/CSS/JS context.

>     * This should give us a result similar to this:
>         [ (ATTR_NAME, ['<','>', '"' ...]) , (TEXT, ['"', '\'', '(', ')']) ]
>     * Then we could analyze that result and say: "For an XSS
> vulnerability to appear in an ATTR_NAME I have to be able to send a
> double quote". If it is possible in this case then the plugin should
> send a specific payload for that case, something similar to --"
> onload="foo()"--

The assumtion about the quote is wrong. You may use 
   attr=value
   attr = value
   attr='value'
   attr="value"
   attr=`IE only`
   attr
        =
        IE-only


>     * Finally, analyze the second response body and if there is an
> attribute in one of the DOM objects that's called "onload" and it's
> text is "foo()" then we have a XSS.

Hmm, I'd use one more request to avoid false negatives. Again there
might be a stupid blacklist which filters for example onmouseover but
not onclick. So I'd use first: 
    aEvent=confirm();
If it is unencoded in the response, we at least have a potential XSS,
which fires if there is any browser implementing aEvent.
Then we also check if is exploitable actually, we use something like:
   onfocus=prompt();


> 
>     Ideas? Does this cover all major cases? Should we have two or more
> XSS detection algorithms and run them all (configurable by the user)?

Hmm, there're pros and cons to offer configuration.
As it is a automated fuzzing, I don't care how many requests fail if
the filter finally does work correctly.
On the other side an option for advanced users can be helpfull in some
cases.
So my suggestion: first approach with full payload, second approach
configurable, third ...

 
> [0] The problem with this are filters that say: "If special char X in
> input then don't echo anything", where "X" might be "<" and that
> affects our possibility to detect if any of the rest of the chars are
> allowed
> 
> Regards,


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop

Reply via email to