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 <mustl...@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/