Re: XSS vulnerabilities via errors at requests to DB

["MustLive" <mustlive () websecurity com ua>]

Hello Michele!

Thank you for paying attention at my small article about my researches.

Yes, I agree with you and Mostafa that better to not have DB errors on
production sites. It's my own approach. I wrote in detail about it in my
answer to Mostafa's letter to WASC Mailing List
(http://www.webappsec.org/lists/websecurity/archive/2009-12/msg00061.html).

> written about Information Disclosure/Leakage (as you want to call it).

Yes, there are also often Information Leakages in SQL errors and I often
found them at different web sites and web applications (about many of such
cases I wrote at my site). In this particular article I wrote about XSS
attacks via SQL errors. Because many web developers don't care about
Information Leakages (especially "small" ones) and they don't know, that
often there are also XSS holes in SQL error messages. So with my researches
and articles (and also during live speeches with web developers who are
turning to me for security audit), I'm trying to inform them about risks of
XSS holes in SQL errors and other common places of XSS.

> More informations about some of my advisories on my blog

Thanks for information. I'll certainly read your advisories.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michele Orru" <antisnatchor () gmail com>
To: "MustLive" <mustlive () websecurity com ua>
Cc: <full-disclosure () lists grok org uk>
Sent: Saturday, December 19, 2009 9:25 PM
Subject: Re: [Full-disclosure] XSS vulnerabilities via errors at requests to
DB


> 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/