Re: XSS vulnerabilities via errors at requests to DB

[Michele Orru <antisnatchor () gmail com>]

I agree with Mostafa.
Leaving DB errors on a production web application is not a good thing:
more than that, hundreds of articles
have been written about Information Disclosure/Leakage (as you want to call it).

Some months about I was blogging on reflected XSS in Java Exception
stack trace: nice to find it (as Stefano did many years ago about SQL
errors), really funny:

More informations about some of my advisories on my blog:

http://antisnatchor.com/2008/12/18/eclipse-birt-reflected-xss/
http://antisnatchor.com/2009/03/10/riotfamily-release-80-xss/

Greetz
Michele "antisnatchor" Orru'

On Fri, Dec 18, 2009 at 3:58 PM, MustLive <mustlive () websecurity com ua> wrote:
> Hello participants of Full-Disclosure.
>
> Let's continue a series of my articles about the most common places of XSS.
>
> Earlier I wrote already about XSS vulnerabilities at 404 pages
> (http://lists.grok.org.uk/pipermail/full-disclosure/2009-November/071664.html).
> And already at 2008 I planned to tell about one interesting and widespread
> vector of XSS attacks - it's the attacks via errors at requests to DB.
>
> I had occasions to discover Cross-Site Scripting vulnerabilities in
> different web applications, and also in browsers and web servers. And
> besides XSS holes at Error 404 pages, I also often found XSS vulnerabilities
> in messages about errors at requests to databases (XSS via SQL Error).
>
> Standard vector of the attack in case of XSS via SQL Error - it's setting of
> XSS-code as value of parameter which is sending to DB (at this it's needed
> that this SQL query becomes incorrect). Which will lead to showing of web
> application's message about error at request to DB, with mentioning of the
> query's line where there is an error, and to executing of JavaScript code in
> browser of the user.
>
> XSS:
>
> http://site/script?param=%27%3Cscript%3Ealert(document.cookie)%3C/script%3E
>
> Such vulnerabilities I found multiple times at different sites and in
> different web applications, particularly in WordPress
> (http://websecurity.com.ua/298/), Relay (http://websecurity.com.ua/2075/)
> and Hydra Engine (http://websecurity.com.ua/3453/).
>
> For example, in WordPress to execute JS-code in error message, it was needed
> to send special symbol (in this case %A0), which I wrote about already in
> detail (http://websecurity.com.ua/298/).
>
> XSS:
>
> http://site/?s=%A0%3Cscript%3Ealert(document.cookie)%3C/script%3E
>
> In some cases (particularly in PHP-applications which use MySQL), it's
> needed to use not script tag, but body tag to conduct XSS attack, so the
> code will be completely showed in message about error in SQL query. As, for
> example, in case of vulnerability at www.zemerl.com
> (http://websecurity.com.ua/3327/).
>
> XSS:
>
> http://site/script?param='%20and%20%3Cbody%20onload=alert(document.cookie)%3E
>
> Note, that already in 2006 there was found vulnerability in PHP
> (http://websecurity.com.ua/225/), which concerned with function mysql_error.
> Which returns value of error of last SQL-query to MySQL in unfiltered form,
> which can lead to XSS attack. This vulnerability was found in PHP 4.4.x and
> 5.1.x. So web applications, which use this function and show its results,
> can be vulnerable to XSS.
>
> So web developers always need to check their projects on presence of XSS
> vulnerabilities in messages about errors at requests to DB. To not allow
> such vulnerabilities.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/