On 02/16/2012 11:58 PM, Andres Riancho wrote:
> Martin,
>
> On Thu, Feb 16, 2012 at 6:36 PM, Martin Holst Swende <mar...@swende.se> wrote:
>> Hi,
>> on n900, so I'll be brief.
>> There are lots of xss filters, and many of them sends you to a different
>> page (frontpage or errorpage) when it detects xss attempts. Therefore, I
>> think it is better to start with a non-malicious payload and go from there:
>>
>> 1. Check reflection with unique string.
>> 2. For *all* reflected places (slot), figure out their html context, which
>> gives chars required to break context (or exec xss directly)
> I'm not sure if I like that option :( What if the XSS is in the error
> handling code? Something like:
>
> if input_is_good( input ):
> echo do_something( input )
> else:
> echo 'Invalid input %s' % input
>
> Then your initial (good/non-malicious) payload won't get to the part
> of the code that malicious payloads would.
Well no, but if it is a generic error page because we sent in something
unexpected, we are bound to find it anyway with our initial vector
(something randomized like awef123123). If, on the other hand, it is an
error page due to xss protection, I don't think it is very common to
have this scenario:
if not input_is_malicious( input ):
echo do_something( input )
else:
echo 'This is malicious input %s' % input
Anyway, isn't he fuzzing engine meant locate pages, and the plugins to
analyse the page (fuzzed url) ? If the xss plugin starts analyzing
another page, it may miss important stuff on the original page. This is
also a reason why I don't want to rely to much on automatic
exploitaition - but be sure to see all vulnerabilities.
Regards,
Martin
>> 3. For each 'slot', send a customized string and test required chars
> But in the example above the slots might change significantly, in the
> good case the string might be echoed 23 different times and in the
> error handling it could be echoed once.
>
>> 4. If we managed to break context, mark vulnerability
>> 5. Find a matching xss vector that can execute. Filters on other levels than
>> charlevel may stop these, but keep going with esoteric variants. Use an
>> extensive list. If found, mark as more severe vulnerability.
> Agreed
>
>> Config option: stop before step 5.
> Sounds good
>
>> Also, I just learned that IE does not urlencode lt and gt from the address
>> bar, so those should be present in the characterset both as urlencoded and
>> not urlencoded.
> That I'm not sure if we can do so easily with the framework :(
>
>> /M
>>
>> ----- Ursprungsmeddelande -----
>>
>>> 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
