Achim,
On Thu, Feb 16, 2012 at 6:01 PM, Achim Hoffmann <[email protected]> wrote:
> 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 " 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);
Sounds good so far,
> Depending on the results you get, you can start injecting other payloads.
> Lucky shot:
> complete string unencode ==> game over, XSS fully exploitable
Agreed,
> escaped quotes:
> continue with injections without quotes
If and only if we're NOT injecting into an attr value
> escaped or removed angle braces:
> continue with tag or attribute injection
If and only if we're not in a TEXT (<a>TEXT</a>) section, because
we're never going to be able to execute JS if we don't create some
kind of new tag and are in that context. Correct?
> removed or mangled fooled tag:
> continue attribute injection and non-HTML injections like CSS or JS
Something similar to the above applies but I'm too tired to think ;)
> 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.
Sorry mate, but failed to follow your idea in this last paragraph
> 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"
Yes, I was taking those into account
> attr=`IE only`
> attr
> =
> IE-only
I hate IE , it breaks my XSS detection algorithm ;)
>
>> * 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();
Understood.
>
>>
>> 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,
>
--
Andrés Riancho
Director of Web Security at Rapid7 LLC
Founder at Bonsai Information Security
Project Leader at w3af
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/w3af-develop
