DOM Based XSS - Revision history

Jmanico: adding link to client side xss

2015-06-25T05:54:57Z

adding link to client side xss

Dimisec: updated DOMinator references

2013-02-13T13:20:15Z

updated DOMinator references

Wichers: /* Testing Tools and Techniques */

2011-11-17T18:16:47Z

‎Testing Tools and Techniques

Wichers: /* Testing Tools and Techniques */

2011-11-08T18:49:10Z

‎Testing Tools and Techniques

Wichers: /* Extensions */

2011-11-08T15:52:16Z

‎Extensions

Roman: Added link to OWASP Testing Guide

2010-10-20T00:38:33Z

Added link to OWASP Testing Guide

Wichers: /* Advanced Techniques and Derivatives */

2009-10-08T19:46:55Z

‎Advanced Techniques and Derivatives

Wichers: /* References */

2009-01-30T14:57:46Z

‎References

Wichers: /* Advanced Techniques and Derivatives */

2009-01-30T14:55:38Z

‎Advanced Techniques and Derivatives

Wichers at 14:06, 30 January 2009

2009-01-30T14:06:18Z

← Older revision		Revision as of 05:54, 25 June 2015
Line 7:		Line 7:

	This is in contrast to other XSS attacks ([[XSS#Stored_and_Reflected_XSS_Attacks \|stored or reflected]]), wherein the attack payload is placed in the response page (due to a server side flaw).		This is in contrast to other XSS attacks ([[XSS#Stored_and_Reflected_XSS_Attacks \|stored or reflected]]), wherein the attack payload is placed in the response page (due to a server side flaw).
		+
		+	Please note research from David Wichers seeking to reclassify DOM XSS more strictly as CLIENT SIDE XSS. https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#DOM_Based_XSS_.28AKA_Type-0.29

	=== Example ===		=== Example ===

@@ Line 75: / Line 75: @@
 === Testing Tools and Techniques ===
-Minded Security has been doing some significant research into DOM based XSS. They are working on two publically available projects to help with DOM Based XSS:
+Minded Security has been doing some significant research into DOM based XSS. They are working on two projects to help with DOM Based XSS:
-. The DOMinator Tool - A FireFox based plugin that helps testers identify and verify DOM based XSS flaws
+. The DOMinator Tool - A commercial tool based on the Firefox browser with modified Spidermonkey Javascript engine that helps testers identify and verify DOM based XSS flaws
-See: http://code.google.com/p/dominator/
+See: https://dominator.mindedsecurity.com/ (https://github.com/wisec/DOMinator for the open source part)
 . The DOM XSS Wiki - The start of a Knowledgebase for defining sources of attacker controlled inputs and sinks which could potentially introduce DOM Based XSS issues. Its very immature as of 11/17/2011. Please contribute to this wiki if you know of more dangerous sinks and/or safe alternatives!!

@@ Line 81: / Line 81: @@
 See: http://code.google.com/p/dominator/
-. The DOM XSS Wiki - A Knowledgebase for defining sources of attacker controlled inputs and sinks which could potentially introduce DOM Based XSS issues.
+. The DOM XSS Wiki - The start of a Knowledgebase for defining sources of attacker controlled inputs and sinks which could potentially introduce DOM Based XSS issues. Its very immature as of 11/17/2011. Please contribute to this wiki if you know of more dangerous sinks and/or safe alternatives!!
 See: http://code.google.com/p/domxsswiki/
 === Defense Techniques ===

← Older revision		Revision as of 18:49, 8 November 2011
Line 84:		Line 84:

	See: http://code.google.com/p/domxsswiki/		See: http://code.google.com/p/domxsswiki/
		+
		+	=== Defense Techniques ===
		+
		+	See: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

	=== References ===		=== References ===

@@ Line 72: / Line 72: @@
 Ory Segal gave an example (section “Javascript flow manipulation” in [2]) of how a target page can be framed and the frame’s parent (in the attacker’s control) can be devised in such manner that it affects the execution of the target page in a way desired by the attacker. The technique shows how DOM manipulation can be useful to modify the execution flow of scripts in the target page.
 Kuza55 and Stefano Di Paola discussed more ways in which the concept of DOM manipulation and DOM based XSS can be extended in [3].
 === References ===

← Older revision		Revision as of 00:38, 20 October 2010
Line 95:		Line 95:

	http://www.owasp.org/images/c/c2/OWASPAppSec2007Milan_ProtectingWebAppsfromUniversalPDFXSS.ppt		http://www.owasp.org/images/c/c2/OWASPAppSec2007Milan_ProtectingWebAppsfromUniversalPDFXSS.ppt
		+
		+	[6] OWASP Testing Guide
		+
		+	[[Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)]]

@@ Line 52: / Line 52: @@
 === Advanced Techniques and Derivatives ===
-In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.  The “DOM Based XSS” paper ([1]) details a technique to avoid server side detection. It also describes several other possible locations for the payload, besides document.location.
+In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.  The [http://www.webappsec.org/projects/articles/071105.shtml “DOM Based XSS” paper] ([1]) details a technique to avoid server side detection. It also describes several other possible locations for the payload, besides document.location.
 The technique to avoid sending the payload to the server hinges on the fact that URI fragments (the part in the URI after the “#”) is not sent to the server by the browser. Thus, any client side code that references, say, document.location, may be vulnerable to an attack which uses fragments, and in such case the payload is never sent to the server. For example, the above DOM based XSS can be modified into:
@@ Line 60: / Line 60: @@
 which mounts the same attack without it being seen by the server (which will simply see a request for page.html without any URL parameters).
-In December 2006, Stefano Di Paola and Giorgio Fedon described a universal XSS attack against the Acrobat PDF plugin ([4]). This attack applied the fragment variant of DOM based XSS to PDF documents. The researchers discovered that a PDF document served to the browser, when rendered by the Acrobat plugin, may end up executing part of the fragment as Javascript. Since the Javascript is executed in the context (DOM) of the current site, all an attacker needed to exploit this flaw was to simply find a PDF link somewhere on the site for the XSS condition to be met. If the attacker then tricked a user into clicking on (or submitting) a link like:
+In December 2006, Stefano Di Paola and Giorgio Fedon described a [http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf universal XSS attack against the Acrobat PDF plugin] ([4]). This attack applied the fragment variant of DOM based XSS to PDF documents. The researchers discovered that a PDF document served to the browser, when rendered by the Acrobat plugin, may end up executing part of the fragment as Javascript. Since the Javascript is executed in the context (DOM) of the current site, all an attacker needed to exploit this flaw was to simply find a PDF link somewhere on the site for the XSS condition to be met. If the attacker then tricked a user into clicking on (or submitting) a link like:
 <pre>
 http://www.some.site/somefile.pdf#somename=javascript:attackers_script_here

← Older revision		Revision as of 14:57, 30 January 2009
Line 91:		Line 91:

	http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf		http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf
		+
		+	[5] "Protecting Web Applications from Universal PDF XSS" (2007 OWASP Europe AppSec presentation) Ivan Ristic, May 2007
		+
		+	http://www.owasp.org/images/c/c2/OWASPAppSec2007Milan_ProtectingWebAppsfromUniversalPDFXSS.ppt

@@ Line 64: / Line 64: @@
 http://www.some.site/somefile.pdf#somename=javascript:attackers_script_here
 </pre>
 then a victim using an un-patched Acrobat reader would succumb to the attack. Adobe patched their reader after they were made aware of this flaw, but if not all users have downloaded the patch then those users are still vulnerable to this type of attack.
 === Extensions ===

← Older revision		Revision as of 14:06, 30 January 2009
Line 1:		Line 1:
		+	{{template: Attack}}
	== DOM Based XSS ==		== DOM Based XSS ==