DOM clobbering: Difference between revisions

Add links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
hardly a stub
No edit summary
Line 2: Line 2:


== Vulnerability ==
== Vulnerability ==
The DOM Clobbering vulnerability arises from a naming collission between the Javascript execution context and HTML elements in the [[Document Object Model]] (DOM). When a <code>undefined</code> Javascript variable is declared in the same context as a HTML element with the same <code>name</code> or <code>id</code> parameter, the browser will assign the HTML element to the <code>undefined</code> variable.<ref>{{Cite journal |last1=Lekies |first1=Sebastian |last2=Kotowicz |first2=Krzysztof |last3=Groß |first3=Samuel |last4=Nava |first4=Eduardo Vela |last5=Johns |first5=Martin |date=2017 |title=Code-reuse attacks for the Web: Breaking Cross-Site Scripting Mitigations via Script Gadgets |url=https://acmccs.github.io/papers/p1709-lekiesA.pdf}}</ref> In certain cases, DOM Clobbering can even be used to overshadow legitimate browser APIs by shadowing the property tree using HTML DOM elements. This can lead to the attacker manipulating the execution of various parts of the Javascript code by injecting specific markup.<ref name=":0" /><ref name=":1" />
The DOM Clobbering vulnerability arises from a naming collission between the Javascript execution context and HTML elements in the [[Document Object Model]] (DOM). When a <code>undefined</code> Javascript variable is declared in the same context as a HTML element with the same <code>name</code> or <code>id</code> parameter, the browser will assign the HTML element to the <code>undefined</code> variable.<ref>{{Cite journal |last=Lekies |first=Sebastian |last2=Kotowicz |first2=Krzysztof |last3=Groß |first3=Samuel |last4=Vela Nava |first4=Eduardo A. |last5=Johns |first5=Martin |date=2017-10-30 |title=Code-Reuse Attacks for the Web: Breaking Cross-Site Scripting Mitigations via Script Gadgets |url=https://dl.acm.org/doi/10.1145/3133956.3134091 |journal=Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security |series=CCS '17 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1709–1723 |doi=10.1145/3133956.3134091 |isbn=978-1-4503-4946-8}}</ref> In certain cases, DOM Clobbering can even be used to overshadow legitimate browser APIs by shadowing the property tree using HTML DOM elements. This can lead to the attacker manipulating the execution of various parts of the Javascript code by injecting specific markup.<ref name=":0" /><ref name=":1" />


A skilled attacker might be able to preform arbitrary open redirections, cross-site request forgery or even gain arbitrary code execution via careful manipulation of HTML elements. As part of a study performed in 2023, ''Khodayari et. al.'' showed that out of the top 5K websites in the world (as determined by Tranco), 9.8% of sites were vulnerable to this attack including popular sites like [[Wikibooks]], [[GitHub]], [[Fandom (website)|Fandom]], [[Trello]] etc.<ref name=":0" />
A skilled attacker might be able to preform arbitrary open redirections, cross-site request forgery or even gain arbitrary code execution via careful manipulation of HTML elements. As part of a study performed in 2023, ''Khodayari et. al.'' showed that out of the top 5K websites in the world (as determined by Tranco), 9.8% of sites were vulnerable to this attack including popular sites like [[Wikibooks]], [[GitHub]], [[Fandom (website)|Fandom]], [[Trello]] etc.<ref name=":0" />
Line 9: Line 9:
The existence of DOM Clobbering has been known since over a decade. The first known instance of a DOM Clobbering attack being dicussed in a research paper was in 2010, when researchers from [[University of California, Berkeley|University of Califronia, Berkley]] and [[Carnegie Mellon University]] demonstrated an attack where a iframe called <code>self</code> could be used to navigate a page to a different page violating the [[same-origin policy]].<ref name=":0" /><ref>{{Cite journal |last=Bates |first=Daniel |last2=Barth |first2=Adam |last3=Jackson |first3=Collin |date=2010-04-26 |title=Regular expressions considered harmful in client-side XSS filters |url=https://doi.org/10.1145/1772690.1772701 |journal=Proceedings of the 19th international conference on World wide web |series=WWW '10 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=91–100 |doi=10.1145/1772690.1772701 |isbn=978-1-60558-799-8}}</ref> Over the years, security researchers have found more sophisticated techniques that have allowed for much greater impact than what was initially demonstated<ref name=":0" /><ref name=":2" />
The existence of DOM Clobbering has been known since over a decade. The first known instance of a DOM Clobbering attack being dicussed in a research paper was in 2010, when researchers from [[University of California, Berkeley|University of Califronia, Berkley]] and [[Carnegie Mellon University]] demonstrated an attack where a iframe called <code>self</code> could be used to navigate a page to a different page violating the [[same-origin policy]].<ref name=":0" /><ref>{{Cite journal |last=Bates |first=Daniel |last2=Barth |first2=Adam |last3=Jackson |first3=Collin |date=2010-04-26 |title=Regular expressions considered harmful in client-side XSS filters |url=https://doi.org/10.1145/1772690.1772701 |journal=Proceedings of the 19th international conference on World wide web |series=WWW '10 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=91–100 |doi=10.1145/1772690.1772701 |isbn=978-1-60558-799-8}}</ref> Over the years, security researchers have found more sophisticated techniques that have allowed for much greater impact than what was initially demonstated<ref name=":0" /><ref name=":2" />


While the existence of the attack itself was know for a long time, the term "DOM Clobbering" itself did not emerge untill 2013, when it was popularized by security researcher Gareth Heyes's blog post demonstrating how the vulnerability could be used to gain arbitrary code execution. In 2017, Heiderich et al. proposed a design for a library called JSAgents, (later DOMPurify) that would be effective at santizing markup injection attacks such as those related to cross-site scripting and DOM Clobbering.
While the existence of the attack itself was know for a long time, the term "DOM Clobbering" itself did not emerge untill 2013, when it was popularized by security researcher Gareth Heyes's blog post demonstrating how the vulnerability could be used to gain arbitrary code execution.<ref name=":0" /> In 2015, ''Heiderich et al.'' proposed a design for a library called JSAgents, (later DOMPurify) that would be effective at santizing markup injection attacks such as those related to cross-site scripting and DOM Clobbering.<ref>{{Cite journal |last=Heiderich |first=Mario |last2=Niemietz |first2=Marcus |last3=Schwenk |first3=Jörg |date=2015 |editor-last=Pernul |editor-first=Günther |editor2-last=Y A Ryan |editor2-first=Peter |editor3-last=Weippl |editor3-first=Edgar |title=Waiting for CSP – Securing Legacy Web Applications with JSAgents |url=https://link.springer.com/chapter/10.1007/978-3-319-24174-6_2 |journal=Computer Security -- ESORICS 2015 |series=Lecture Notes in Computer Science |language=en |location=Cham |publisher=Springer International Publishing |pages=23–42 |doi=10.1007/978-3-319-24174-6_2 |isbn=978-3-319-24174-6}}</ref><ref>{{Cite journal |last=Heiderich |first=Mario |last2=Späth |first2=Christopher |last3=Schwenk |first3=Jörg |date=2017 |editor-last=Foley |editor-first=Simon N. |editor2-last=Gollmann |editor2-first=Dieter |editor3-last=Snekkenes |editor3-first=Einar |title=DOMPurify: Client-Side Protection Against XSS and Markup Injection |url=https://link.springer.com/chapter/10.1007/978-3-319-66399-9_7 |journal=Computer Security – ESORICS 2017 |series=Lecture Notes in Computer Science |language=en |location=Cham |publisher=Springer International Publishing |pages=116–134 |doi=10.1007/978-3-319-66399-9_7 |isbn=978-3-319-66399-9}}</ref>


In more recent years, there has been in an resurgence of interest in mitigating this attack especially after DOM Clobbering vulnerabilities were found in Gmail and Google Analytics in 2020.<ref>{{Cite web |date=2020-02-06 |title=DOM Clobbering strikes back |url=https://portswigger.net/research/dom-clobbering-strikes-back |access-date=2023-11-09 |website=PortSwigger Research}}</ref> Over 2020 and 2021, proposals were made at various web standard groups detailing defenses against DOM Clobbering but shutting of named access to DOM elements at the browser level.<ref>{{Cite web |title=Disable DOM clobbering. · Issue #349 · w3c/webappsec-permissions-policy |url=https://github.com/w3c/webappsec-permissions-policy/issues/349 |access-date=2023-11-09 |website=GitHub |language=en}}</ref> However, these were dismissed since as per [[Google Chrome|Chrome]] telemetry data, over 10.5% percent of the web relies on the features working as per their current behaviour.<ref>{{Cite web |title=Chrome Platform Status |url=https://chromestatus.com/metrics/feature/timeline/popularity/1824 |access-date=2023-11-09 |website=chromestatus.com}}</ref>
In more recent years, there has been in an resurgence of interest in mitigating this attack especially after DOM Clobbering vulnerabilities were found in Gmail and Google Analytics in 2020.<ref>{{Cite web |date=2020-02-06 |title=DOM Clobbering strikes back |url=https://portswigger.net/research/dom-clobbering-strikes-back |access-date=2023-11-09 |website=PortSwigger Research}}</ref> Over 2020 and 2021, proposals were made at various web standard groups detailing defenses against DOM Clobbering but shutting of named access to DOM elements at the browser level.<ref>{{Cite web |title=Disable DOM clobbering. · Issue #349 · w3c/webappsec-permissions-policy |url=https://github.com/w3c/webappsec-permissions-policy/issues/349 |access-date=2023-11-09 |website=GitHub |language=en}}</ref> However, these proposals were dismissed since as per [[Google Chrome|Chrome]] telemetry data, over 10.5% percent of the web relies on the features working as per their current behaviour.<ref>{{Cite web |title=Chrome Platform Status |url=https://chromestatus.com/metrics/feature/timeline/popularity/1824 |access-date=2023-11-09 |website=chromestatus.com}}</ref>


== References ==
== References ==

Revision as of 19:44, 9 November 2023

DOM Clobberring is a type of injection attack that revolves around the attacker being able to insert benign non-script HTML code, that can be used to influence the execution of Javascript code.[1][2][3]

Vulnerability

The DOM Clobbering vulnerability arises from a naming collission between the Javascript execution context and HTML elements in the Document Object Model (DOM). When a undefined Javascript variable is declared in the same context as a HTML element with the same name or id parameter, the browser will assign the HTML element to the undefined variable.[4] In certain cases, DOM Clobbering can even be used to overshadow legitimate browser APIs by shadowing the property tree using HTML DOM elements. This can lead to the attacker manipulating the execution of various parts of the Javascript code by injecting specific markup.[1][3]

A skilled attacker might be able to preform arbitrary open redirections, cross-site request forgery or even gain arbitrary code execution via careful manipulation of HTML elements. As part of a study performed in 2023, Khodayari et. al. showed that out of the top 5K websites in the world (as determined by Tranco), 9.8% of sites were vulnerable to this attack including popular sites like Wikibooks, GitHub, Fandom, Trello etc.[1]

History

The existence of DOM Clobbering has been known since over a decade. The first known instance of a DOM Clobbering attack being dicussed in a research paper was in 2010, when researchers from University of Califronia, Berkley and Carnegie Mellon University demonstrated an attack where a iframe called self could be used to navigate a page to a different page violating the same-origin policy.[1][5] Over the years, security researchers have found more sophisticated techniques that have allowed for much greater impact than what was initially demonstated[1][2]

While the existence of the attack itself was know for a long time, the term "DOM Clobbering" itself did not emerge untill 2013, when it was popularized by security researcher Gareth Heyes's blog post demonstrating how the vulnerability could be used to gain arbitrary code execution.[1] In 2015, Heiderich et al. proposed a design for a library called JSAgents, (later DOMPurify) that would be effective at santizing markup injection attacks such as those related to cross-site scripting and DOM Clobbering.[6][7]

In more recent years, there has been in an resurgence of interest in mitigating this attack especially after DOM Clobbering vulnerabilities were found in Gmail and Google Analytics in 2020.[8] Over 2020 and 2021, proposals were made at various web standard groups detailing defenses against DOM Clobbering but shutting of named access to DOM elements at the browser level.[9] However, these proposals were dismissed since as per Chrome telemetry data, over 10.5% percent of the web relies on the features working as per their current behaviour.[10]

References

  1. ^ a b c d e f Khodayari, Soheil; Pellegrino, Giancarlo (2023). "It's (DOM) Clobbering Time: Attack Techniques, Prevalence, and Defenses". 2023 IEEE Symposium on Security and Privacy (SP). pp. 1041–1058. doi:10.1109/SP46215.2023.10179403. ISBN 978-1-6654-9336-9. S2CID 260002685.
  2. ^ a b "DOM clobbering | Web Security Academy". portswigger.net. Retrieved 2023-10-30.
  3. ^ a b "Mitigating DOM clobbering attacks in JavaScript". Snyk. 2023-08-07. Retrieved 2023-10-30.
  4. ^ Lekies, Sebastian; Kotowicz, Krzysztof; Groß, Samuel; Vela Nava, Eduardo A.; Johns, Martin (2017-10-30). "Code-Reuse Attacks for the Web: Breaking Cross-Site Scripting Mitigations via Script Gadgets". Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. CCS '17. New York, NY, USA: Association for Computing Machinery: 1709–1723. doi:10.1145/3133956.3134091. ISBN 978-1-4503-4946-8.
  5. ^ Bates, Daniel; Barth, Adam; Jackson, Collin (2010-04-26). "Regular expressions considered harmful in client-side XSS filters". Proceedings of the 19th international conference on World wide web. WWW '10. New York, NY, USA: Association for Computing Machinery: 91–100. doi:10.1145/1772690.1772701. ISBN 978-1-60558-799-8.
  6. ^ Heiderich, Mario; Niemietz, Marcus; Schwenk, Jörg (2015). Pernul, Günther; Y A Ryan, Peter; Weippl, Edgar (eds.). "Waiting for CSP – Securing Legacy Web Applications with JSAgents". Computer Security -- ESORICS 2015. Lecture Notes in Computer Science. Cham: Springer International Publishing: 23–42. doi:10.1007/978-3-319-24174-6_2. ISBN 978-3-319-24174-6.
  7. ^ Heiderich, Mario; Späth, Christopher; Schwenk, Jörg (2017). Foley, Simon N.; Gollmann, Dieter; Snekkenes, Einar (eds.). "DOMPurify: Client-Side Protection Against XSS and Markup Injection". Computer Security – ESORICS 2017. Lecture Notes in Computer Science. Cham: Springer International Publishing: 116–134. doi:10.1007/978-3-319-66399-9_7. ISBN 978-3-319-66399-9.
  8. ^ "DOM Clobbering strikes back". PortSwigger Research. 2020-02-06. Retrieved 2023-11-09.
  9. ^ "Disable DOM clobbering. · Issue #349 · w3c/webappsec-permissions-policy". GitHub. Retrieved 2023-11-09.
  10. ^ "Chrome Platform Status". chromestatus.com. Retrieved 2023-11-09.
Retrieved from "https://en.wikipedia.org/w/index.php?title=DOM_clobbering&oldid=1184333142"