In internet security, DOM clobbering 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. This can lead to a skilled attacker being able to perform a variety of unwanted behaviours, including the ability to escalate to arbitrary code execution on the website.

While the vulnerability has been known for over a decade, recent efforts to mitigate it completely have been unsuccessful due to a significant amount of usage of the underlying features across the web as of 2021. However, a few defences have been identified that limit the effects of DOM clobbering and prevent some instances of DOM clobbering from occurring.

Vulnerability

The DOM clobbering vulnerability arises from a naming collision 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 an HTML element with the same name or id parameter, the browser will assign the HTML element to the undefined variable.[1] In some instances, 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.[2][3]

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

Threat model

The threat model for a DOM clobbering attack is similar to that of the web attacker model proposed by Akhawe et al. in 2010. This model assumes that the attacker can send emails or, by some other method, phish the victim to specific pages under their control. The model also assumes that the attacker can inject a limited set of markup into victim websites.[4][5] This is crucial since DOM clobbering depends on the attacker being able to inject potentially benign HTML into a website.[2]

History

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

While the existence of the attack itself was known for a long time, the term "DOM clobbering" itself did not emerge until 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.[2] 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.[8][4]

There has been a resurgence of interest in mitigating this attack in recent years, especially after DOM clobbering vulnerabilities were found in Gmail and Google Analytics in 2020.[9] Over 2020 and 2021, proposals were made at various web standard groups detailing defences against DOM clobbering by disallowing named access to DOM elements at the browser level.[10] However, these proposals were dismissed since as per Chrome telemetry data, over 10.5% per cent of the web relies on the features working as per their current behaviour.[11]

Defenses

While the ultimate defence against DOM clobbering would be to turn off access to named DOM elements, this is currently not feasible due to significant active usage of these features as per Chrome telemetry data in 2021.[10][11] However, various secure coding practices can be used to mitigate the effects of DOM clobbering on Javascript code execution.[2]

HTML sanitization libraries

One of the most common techniques to limit DOM clobbering attacks is to use HTML santization libraries.[2] In 2017, Heiderich et al. proposed a mitigation for DOM clobbering that was subsequently added to the DOMPurify library. The mitigation leveraged the use of hashes of existing functions to determine if HTML elements had overwritten them. In addition, DOMPurify parses the id and name attributes of injected elements to identify if they can collide with existing global functions.[4] However, recent vulnerabilities related to DOM clobbering have been found in DOMPurify and similar libraries such as HTML Janitor, which indicate that these libraries only protect against specific cases of DOM clobbering and are largely unaware of the related risks.[2][12][13]

Content security policy

Another popular method to mitigate the effects of DOM clobbering is the use of restrictive Content Security Policies (CSP).[14] While this does not prevent DOM clobbering from altering the execution of already present code,[1] using restrictive content security policies can make it much harder for attackers to elevate a DOM clobbering issue into a arbitrary code execution attack by limiting how scripts can be executed on a website. By leveraging the script-src CSP directive, web developers can restrict where scripts can be loaded to a predetermined set of trusted domains.[14] This thwarts the attacker's ability to load an untrusted attacker-controlled code significantly, if they can compromise the src attribute of a script tag.[15]

See also

References

  1. 1 2 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. pp. 1709–1723. doi:10.1145/3133956.3134091. ISBN 978-1-4503-4946-8. S2CID 8779516.
  2. 1 2 3 4 5 6 7 8 9 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.
  3. ↑ "Mitigating DOM clobbering attacks in JavaScript". Snyk. 2023-08-07. Retrieved 2023-10-30.
  4. 1 2 3 Heiderich, Mario; Späth, Christopher; Schwenk, Jörg (2017). "DOMPurify: Client-Side Protection Against XSS and Markup Injection". In Foley, Simon N.; Gollmann, Dieter; Snekkenes, Einar (eds.). Computer Security – ESORICS 2017. Lecture Notes in Computer Science. Vol. 10493. Cham: Springer International Publishing. pp. 116–134. doi:10.1007/978-3-319-66399-9_7. ISBN 978-3-319-66399-9.
  5. ↑ Akhawe, Devdatta; Barth, Adam; Lam, Peifung E.; Mitchell, John; Song, Dawn (2010). Towards a Formal Foundation of Web Security. pp. 290–304. doi:10.1109/csf.2010.27. ISBN 978-1-4244-7510-0. S2CID 14522899. Retrieved 2023-11-10.
  6. ↑ 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. pp. 91–100. doi:10.1145/1772690.1772701. ISBN 978-1-60558-799-8. S2CID 730078.
  7. ↑ "DOM clobbering | Web Security Academy". portswigger.net. Retrieved 2023-10-30.
  8. ↑ Heiderich, Mario; Niemietz, Marcus; Schwenk, Jörg (2015). "Waiting for CSP – Securing Legacy Web Applications with JSAgents". In Pernul, Günther; Y A Ryan, Peter; Weippl, Edgar (eds.). Computer Security -- ESORICS 2015. Lecture Notes in Computer Science. Vol. 9326. Cham: Springer International Publishing. pp. 23–42. doi:10.1007/978-3-319-24174-6_2. ISBN 978-3-319-24174-6.
  9. ↑ "DOM Clobbering strikes back". PortSwigger Research. 2020-02-06. Retrieved 2023-11-09.
  10. 1 2 "Disable DOM clobbering. · Issue #349 · w3c/webappsec-permissions-policy". GitHub. Retrieved 2023-11-09.
  11. 1 2 "Chrome Platform Status". chromestatus.com. Retrieved 2023-11-09.
  12. ↑ "Publications/pentest-report_dompurify.pdf at master · cure53/Publications" (PDF). GitHub. Retrieved 2023-11-10.
  13. ↑ "Node.js third-party modules disclosed on HackerOne: [html-janitor]..." HackerOne. Retrieved 2023-11-10.
  14. 1 2 Roth, Sebastian; Backes, Michael; Stock, Ben (2020-10-05). "Assessing the Impact of Script Gadgets on CSP at Scale". Proceedings of the 15th ACM Asia Conference on Computer and Communications Security. ASIA CCS '20. New York, NY, USA: Association for Computing Machinery. pp. 420–431. doi:10.1145/3320269.3372201. ISBN 978-1-4503-6750-9. S2CID 222135428.
  15. ↑ "DOM Clobbering Prevention - OWASP Cheat Sheet Series". cheatsheetseries.owasp.org. Retrieved 2023-11-10.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.