Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [REVS] DOM Based Cross Site Scripting |
|---|---|
| Date: | 2 Aug 2005 18:16:11 +0200 |
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com - - promotion The SecuriTeam alerts list - Free, Accurate, Independent. Get your security news from a reliable source. http://www.securiteam.com/mailinglist.html - - - - - - - - - DOM Based Cross Site Scripting ------------------------------------------------------------------------ SUMMARY We all know what Cross Site Scripting (XSS) is, right? It's that vulnerability wherein one sends malicious data (typically HTML stuff with Javascript code in it) that is echoed back later by the application in an HTML context of some sort, and the Javascript code gets executed. Well, wrong. There is a kind of XSS that does not match this description, at least not in some of its fundamental properties. The XSS attacks described above are either non-persistent / reflected (i.e. the malicious data is embedded in the page that is returned to the browser immediately following the request) or persistent / stored (in which case the malicious data is returned at some later time). But there s also a third kind of XSS attacks - the ones that do not rely on sending the malicious data to the server in the first place! While this seems almost contradictory to the definition or to common sense, there are, in fact, two well described examples for such attacks. This technical note discusses the third kind of XSS, dubbed "DOM Based XSS". No claim is made to novelty in the attacks themselves, of course, but rather, the innovation in this write-up is about noticing that these belong to a different flavor, and that flavor is interesting and important. DETAILS Application developers and owners need to understand DOM Based XSS, as it represents a threat to the web application, which has different preconditions than standard XSS. As such, there are many web applications on the Internet that are vulnerable to DOM Based XSS, yet when tested for (standard) XSS, are demonstrated to be "not vulnerable". Developers and site maintainers (and auditors) need to familiarize themselves with techniques to detect DOM Based XSS vulnerabilities, as well as with techniques to defend against them, both there which are different than the ones applicable for standard XSS. The reader is assumed to possess basic knowledge of XSS ([1], [2], [3], [4], [8]). XSS is typically categorized into "non-persistent" and "persistent" ([3], "reflected" and "stored" accordingly, as defined in [4]). "Non-persistent" means that the malicious (Javascript) payload is echoed by the server in an immediate response to an HTTP request from the victim. "Persistent" means that the payload is stored by the system, and may later be embedded by the vulnerable system in an HTML page provided to a victim. As mentioned in the summary, this categorization assumes that a fundamental property of XSS is having the malicious payload move from the browser to the server and back to the same (in non-persistent XSS) or any (in persistent XSS) browser. This paper points out that this is a misconception. While there are not many counterexamples in the wild, the mere existence of XSS attacks which do not rely on the payload embedded by the server in some response page, is of importance as it has a significant impact on detection and protection methods. This is discussed in the document. To read more about the subject please visit: <http://www.webappsec.org/projects/articles/071105.shtml> http://www.webappsec.org/projects/articles/071105.shtml ADDITIONAL INFORMATION The information has been provided by <mailto:contact@webappsec.org> Robert Auger. The article has been written by Amit Klein The original article can be found at: <http://www.webappsec.org/projects/articles/071105.shtml> http://www.webappsec.org/projects/articles/071105.shtml ======================================== This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com ==================== ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [NEWS] MySQL AB Eventum Multiple Vulnerabilities, SecuriTeam |
|---|---|
| Next by Date: | [EXPL] Baby Web Server Command Validation (Exploit), SecuriTeam |
| Previous by Thread: | [NEWS] MySQL AB Eventum Multiple Vulnerabilities, SecuriTeam |
| Next by Thread: | [EXPL] Baby Web Server Command Validation (Exploit), SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |