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 W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop