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);
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/w3af-develop
