> According to Wikipedia:
> =======================================================================
> With DOM-based cross-site scripting vulnerabilities, the problem exists
> within a page's client-side script itself. For instance, if a piece of
> JavaScript accesses a URL request parameter and uses this information to
> write some HTML to its own page, and this information is not encoded
> using HTML entities, an XSS hole will likely be present, since this
> written data will be re-interpreted by browsers as HTML which could
> include additional client-side script.
> =======================================================================
>
> So does that mean I'd have to monitor all GET/POST requests made to the
> server, and their related responses to see if a string from the REQUEST
> could be found in the response?
No. The whole point of DOM-based XSS issues is that the problem exists
in client-side code. The server isn't vulnerable in the sense that it
isn't executing code that injects user-supplied content. Instead, code
provided by the website to the user is executing in the user's browser
and is injecting into the page, which may be completely undetectable on
the server side.
In order to test if an input string is written to a page unencoded,
you'd need a full JavaScript (at least) interpreter which provided you
with an interpreted version of a resulting page after document.write()s,
eval()s, and similar injection points had finished executing.
> Does anyone have any code snippets I could look at, or at least some
> conceptual guidance they can give me?
Off the top of my head (totally untested), here's a vulnerable page
which won't send the injection string to the server:
> =======================================================================
> With DOM-based cross-site scripting vulnerabilities, the problem exists
> within a page's client-side script itself. For instance, if a piece of
> JavaScript accesses a URL request parameter and uses this information to
> write some HTML to its own page, and this information is not encoded
> using HTML entities, an XSS hole will likely be present, since this
> written data will be re-interpreted by browsers as HTML which could
> include additional client-side script.
> =======================================================================
>
> So does that mean I'd have to monitor all GET/POST requests made to the
> server, and their related responses to see if a string from the REQUEST
> could be found in the response?
No. The whole point of DOM-based XSS issues is that the problem exists
in client-side code. The server isn't vulnerable in the sense that it
isn't executing code that injects user-supplied content. Instead, code
provided by the website to the user is executing in the user's browser
and is injecting into the page, which may be completely undetectable on
the server side.
In order to test if an input string is written to a page unencoded,
you'd need a full JavaScript (at least) interpreter which provided you
with an interpreted version of a resulting page after document.write()s,
eval()s, and similar injection points had finished executing.
> Does anyone have any code snippets I could look at, or at least some
> conceptual guidance they can give me?
Off the top of my head (totally untested), here's a vulnerable page
which won't send the injection string to the server:
<script>
document.write(document.location.hash);
</script>
HTH,
tim
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Top 5 Common Mistakes in
Securing Web Applications
Get 45 Min Video and PPT Slides
www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------
[ reply ]