lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 19 Dec 2009 20:25:25 +0100
From: Michele Orru <>
To: MustLive <>
Subject: Re: XSS vulnerabilities via errors at requests to

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:

Michele "antisnatchor" Orru'

On Fri, Dec 18, 2009 at 3:58 PM, MustLive <> 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
> (
> 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
> (, Relay (
> and Hydra Engine (
> 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 (
> 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
> (
> XSS:
> http://site/script?param='%20and%20%3Cbody%20onload=alert(document.cookie)%3E
> Note, that already in 2006 there was found vulnerability in PHP
> (, 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
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> Hosted and sponsored by Secunia -

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists