Re: [Full-disclosure] XSS vulnerabilities via errors at requests to DB
Hello Michal! First of all, Happy New Year. And thank you for paying attention at my small article about my researches. Thank you this excellent research! You are welcome. In this case I was talking not about something new for security community (security professionals have to deal with XSS via SQL errors many times), but about most common places of XSS holes. Such as XSS in search engines (local and global), XSS at 404 error pages and XSS via errors at requests to DB (in last article). As I already wrote to Michele (http://lists.grok.org.uk/pipermail/full-disclosure/2009-December/072123.html), with my researches and articles, and also during live speeches with web developers, I'm trying to inform them about risks of XSS holes in common places of XSS. Given your contributions in this area, I was hoping you could offer me some advice: I see you have a sense of humor. But I give you advice (which you asked me): irony is not best type of humor, so next time try other type of humor ;-). Because, Google with no doubts have a sense of humor (http://lists.grok.org.uk/pipermail/full-disclosure/2009-December/072111.html). As I said before, in this article I wrote about not new classes of XSS holes or attacks, but about most common places of XSS. I.e. I'm showing examples of bad practices to force web developers to make more secure web sites. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: Michal Zalewski lcam...@coredump.cx To: MustLive mustl...@websecurity.com.ua Cc: full-disclosure@lists.grok.org.uk Sent: Saturday, December 19, 2009 9:19 PM Subject: Re: [Full-disclosure] XSS vulnerabilities via errors at requests to DB Dear MustLive, 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. Thank you this excellent research! Given your contributions in this area, I was hoping you could offer me some advice: I recently stumbled upon an XSS flaw on a page with vaguely turquoise background. I am not sure whether to classify this as a separate class of a web vulnerability, or merely a novel extension of well-established XSS attacks against sky blue targets? Sincerely, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] XSS vulnerabilities via errors at requests to DB
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 antisnatc...@gmail.com To: MustLive mustl...@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 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
[Full-disclosure] XSS vulnerabilities via errors at requests to DB
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/
Re: [Full-disclosure] XSS vulnerabilities via errors at requests to DB
Dear MustLive, 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. Thank you this excellent research! Given your contributions in this area, I was hoping you could offer me some advice: I recently stumbled upon an XSS flaw on a page with vaguely turquoise background. I am not sure whether to classify this as a separate class of a web vulnerability, or merely a novel extension of well-established XSS attacks against sky blue targets? Sincerely, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
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 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/
