| CARVIEW |
Select Language
HTTP/2 301
server: envoy
x-frame-options: SAMEORIGIN
cache-control: public, s-maxage=86400, max-age=0, must-revalidate
location: https://www.slideshare.net/slideshow/the-innerhtml-apocalypse/19935120
x-envoy-upstream-service-time: 363
p3p: CP="OTI DSP COR CUR ADM DEV PSD IVD CONo OUR IND"
x-content-type-options: nosniff
accept-ranges: bytes
age: 0
date: Sat, 11 Oct 2025 08:33:23 GMT
via: 1.1 varnish
x-served-by: cache-bom-vanm7210052-BOM
x-cache: MISS
x-cache-hits: 0
x-timer: S1760171603.709700,VS0,VE569
vary: accept-encoding, x-bot
set-cookie: browser_id=5185f441-daf0-4a7a-8758-60aa0742f222; Domain=.slideshare.net; Path=/; Expires=Thu, 10 Oct 2030 08:33:23 GMT
strict-transport-security: max-age=63072000; includeSubDomains; preload
alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
content-length: 70
HTTP/2 200
content-type: text/html; charset=utf-8
server: envoy
x-frame-options: SAMEORIGIN
cache-control: public, s-maxage=86400, max-age=0, must-revalidate
x-powered-by: Next.js
etag: "r5ose895b8rg9a"
content-encoding: gzip
x-envoy-upstream-service-time: 489
p3p: CP="OTI DSP COR CUR ADM DEV PSD IVD CONo OUR IND"
x-content-type-options: nosniff
accept-ranges: bytes
age: 0
date: Sat, 11 Oct 2025 08:33:24 GMT
via: 1.1 varnish
x-served-by: cache-bom-vanm7210052-BOM
x-cache: MISS
x-cache-hits: 0
x-timer: S1760171603.291903,VS0,VE1096
vary: accept-encoding, x-bot
strict-transport-security: max-age=63072000; includeSubDomains; preload
alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
content-length: 170613
The innerHTML Apocalypse | PDF 
![Funny Stuff
● So browsers change the markup
● Sanitize, beautify, optimize
● There's nothing we can do about it
● And it often helps
● Some funny artifacts exist...
● Comments for instance
● Or try CDATA sections for a change...
IN: <!-> OUT: <!----->
IN: <!--> OUT: <!---->
IN: <![CDATA]> OUT: <!--[CDATA]-->](https://image.slidesharecdn.com/innerhtmlapocalypse-130425023611-phpapp02/75/The-innerHTML-Apocalypse-22-2048.jpg)
![IN: <article xmlns="><img src=x onerror=alert(1)"></article>
OUT: <?XML:NAMESPACE PREFIX = [default] ><img src=x
onerror=alert(1) NS = "><img src=x onerror=alert(1)"
/><article xmlns="><img src=x onerror=alert(1)"></article>](https://image.slidesharecdn.com/innerhtmlapocalypse-130425023611-phpapp02/75/The-innerHTML-Apocalypse-30-2048.jpg)
Uploaded byMario Heiderich
35,571 views
The innerHTML Apocalypse
The presentation by Mario Heiderich discusses how MXSS (Mutating XSS) attacks challenge existing beliefs about web security, particularly focusing on the manipulation of the DOM through innerHTML. It highlights the complexities of detecting and preventing various forms of XSS, emphasizing that filters and sanitizers often fail to address fundamental vulnerabilities. Heiderich concludes with strategies for developers and pentesters to mitigate these issues, advocating for stricter standards and a deeper understanding of browser behavior.
In this document
Powered by AI
Introduces mXSS attacks and the speaker, Dr. Mario Heiderich, highlighting his expertise and background.
Details the research focus on HTML, JavaScript, and client-side security; discusses the ubiquity of HTML in various technologies.
Discusses layers of defense against XSS, referencing reflected, stored, and DOMXSS as the primary threat types.
Assumptions about preventing XSS, the importance of filters, and possible bypassing of security tools.
Explains the use of innerHTML for DOM manipulation, its advantages, disadvantages, and common practices.
Discusses the role of innerHTML in rich text editors and potential security risks linked to markup non-idempotency.
Explores real-world mXSS attacks and how different browsers handle malformed HTML, leading to vulnerabilities.
Highlights security risks presented by style attributes, HTML entities, and their exploitation in various browsers.
Offers strategies for mitigating mXSS attacks, including enforcing standards and implementing strict whitelists.
Summarizes key points regarding HTML vulnerabilities, presents takeaways for different stakeholders, and opens the floor for questions.
Downloaded 320 times
![Funny Stuff
● So browsers change the markup
● Sanitize, beautify, optimize
● There's nothing we can do about it
● And it often helps
● Some funny artifacts exist...
● Comments for instance
● Or try CDATA sections for a change...
IN: <!-> OUT: <!----->
IN: <!--> OUT: <!---->
IN: <![CDATA]> OUT: <!--[CDATA]-->](https://image.slidesharecdn.com/innerhtmlapocalypse-130425023611-phpapp02/85/The-innerHTML-Apocalypse-22-320.jpg)
![IN: <article xmlns="><img src=x onerror=alert(1)"></article>
OUT: <?XML:NAMESPACE PREFIX = [default] ><img src=x
onerror=alert(1) NS = "><img src=x onerror=alert(1)"
/><article xmlns="><img src=x onerror=alert(1)"></article>](https://image.slidesharecdn.com/innerhtmlapocalypse-130425023611-phpapp02/85/The-innerHTML-Apocalypse-30-320.jpg)
More Related Content
Viewers also liked
![Creativitate si inventica [pdf]](https://cdn.slidesharecdn.com/ss_thumbnails/creativitatesiinventicapdf-121101052408-phpapp02-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Similar to The innerHTML Apocalypse
More from Mario Heiderich
The innerHTML Apocalypse
- 1. The innerHTML Apocalypse HowmXSS attacks change everything we believed to know so far A presentation by Mario Heiderich mario@cure53.de || @0x6D6172696F
- 2. Our Fellow Messenger ●Dr.-Ing. Mario Heiderich ● Researcher and Post-Doc, Ruhr-Uni Bochum – PhD Thesis on Client Side Security and Defense ● Founder of Cure53 – Penetration Testing Firm – Consulting, Workshops, Trainings – Simply the Best Company of the World ● Published author and international speaker – Specialized in HTML5 and SVG Security – JavaScript, XSS and Client Side Attacks ● HTML5 Security Cheatsheet – @0x6D6172696F – mario@cure53.de
- 3. Research Focus ● Everything inside<> ● HTML 2.0 – 5.1 ● JavaScript / JScript, VBS ● Plug-ins and Controls ● Editable Rich-Text ● SVG, MathML, XLS, XDR ● CSS, Scriptless Attacks ● ES5 / ES6 ● DOM Clobbering ● No binary stuff. My brain cannot :) ● Offense ● Injection Scenarios ● Active File formats ● Parser Analysis ● Archeology & Legacy Porn ● Defense ● XSS Filter / WAF / IDS ● CSP, DOM-based XSS Filter ● DOM Policies ● DOM + Trust & Control
- 4. Why? ● HTML on itsway to ultimate power ● Websites and Applications ● Instant Messengers and Email Clients ● Local documentation and presentations ● Router Interfaces and coffee-machine UIs ● Medical Devices – according to this source ● Operating systems, Win8, Tizen ● HTML + DOM + JavaScript ● “I mean look at friggin' Gmail!” ● I measured the amount of JavaScript on 27th of Jan. 2013 ● It was exactly 3582,8 Kilobytes of text/javascript
- 5. Defense ● Several layersof defense over the years ● Network-based defense, IDS/IPS, WAF ● Server-side defense, mod_security, others ● Client-side defense, XSS Filter, CSP, NoScript ● “We bypassed, they fixed.” ● A lot of documentation, sometimes good ones too! ● Hundreds of papers, talks, blog posts ● Those three horsemen are covered quite well!
- 6. Horsemen? ● Reflected XSS ● TheWhite Horse – “Purity”. Easy to understand, detect and prevent. ● Stored XSS ● The Red Horse – “War”. Harder to detect and prevent – where rich-text of benign nature is needed. ● DOMXSS ● The Black Horse – “Disease”. Harder to comprehend. Often complex, hard to detect and prevent.
- 7. “But what's aproper apocalypse without...”
- 8.
- 9. “Enough with thekitsch, let's get technical”
- 10. Assumptions ● Reflected XSScomes via URL / Parameters ● We can filter input properly ● Persistent XSS comes via POST / FILE ● We can filter output properly ● Tell good HTML apart from bad ● DOMXSS comes from DOM properties ● No unfiltered usage of DOMXSS sources ● We can be more careful with DOMXSS sinks ● We can create safer JavaScript business logic ● Following those rules + handling Uploads properly + setting some headers mitigates XSS. Right?
- 11. That telling apart... ●Advanced filter libraries ● OWASP Antisamy / XSS Filter Project ● HTML Purifier ● SafeHTML ● jSoup ● Many others out there ● Used in Webmailers, CMS, Social Networks ● Intranet, Extranet, WWW, Messenger-Tools, Mail-Clients ● They are the major gateway between ● Fancy User-generated Rich-Text ● And a persistent XSS ● Those things work VERY well! ● Without them working well, shit would break
- 12. “But what ifwe can fool those tools? Just ship around them. Every single one of them?”
- 13.
- 14. Decades Ago... ● MSadded a convenient DOM property ● It was available in Internet Explorer 4 ● Allowed to manipulate the DOM... ● … without even manipulating it... ● … but have the browser do the work! ● element.innerHTML ● Direct access to the elements HTML content ● Read and write of course ● Browser does all the nasty DOM stuff internally
- 15. Look at this //The DOM way var myId = "spanID"; var myDiv = document.getElementById("myDivId"); var mySpan = document.createElement('span'); var spanContent = document.createTextNode('Bla'); mySpan.id = mySpanId; mySpan.appendChild(spanContent); myDiv.appendChild(mySpan); // The innerHTML way var myId = "spanID"; var myDiv = document.getElementById("myDivId"); myDiv.innerHTML = '<span id="'+myId+'">Bla</span>';
- 16. Compared ● Pro ● It'seasy ● It's fast ● It's now a standard ● It just works ● It's got a big brother.. outerHTML ● Contra ● Bit bitchy with tables ● Slow on older browsers ● No XML ● Not as “true” as real DOM manipulation
- 17.
- 18. Rich Text Editors ●The basically exist because of innerHTML ● And of course contentEditable ● And they are everywhere ● CMS ● Webmailers ● Email Clients ● Publishing Tools
- 19. “Now, what's theproblem with all this?”
- 20. Internals ● We mightbe naïve and assume: ● ƒ(ƒ(x)) ≡ ƒ(x) ● Idempotency ● An elements innerHTML matches it's actual content ● But it doesn't ● It's non-idempotent and changes! ● And that's usually even very good! ● Performance ● Bad markup that messes up structure ● Illegal markup in a sane DOM tree
- 21. Examples ● We havea little test-suite for you ● Let's see some examples ● And why non-idempotency is actually good IN: <div>123 OUT: <div>123</div> IN: <Div/class=abc>123 OUT: <div class="abc">123</div> IN: <span><dIV>123</span> OUT: <span><div>123</div></span>
- 22. Funny Stuff ● Sobrowsers change the markup ● Sanitize, beautify, optimize ● There's nothing we can do about it ● And it often helps ● Some funny artifacts exist... ● Comments for instance ● Or try CDATA sections for a change... IN: <!-> OUT: <!-----> IN: <!--> OUT: <!----> IN: <![CDATA]> OUT: <!--[CDATA]-->
- 23. “And what doesit have to do with security again?”
- 24. It was backin 2006... ● .. when a fellow desk-worker noticed a strange thing. Magical, even!
- 25. The Broken Preview ●Sometimes print preview was bricked ● Attribute content bled into the document ● No obvious reason... ● Then Yosuke Hasegawa analyzed the problem ● One year later in 2007 ● And discovered the first pointer to mXSS
- 26. Now let's havea look ● DEMO ● Requires IE8 or older
- 27. IN: <img src="foo"alt="``onerror=alert(1)" /> OUT: <IMG alt=``onerror=alert(1) src="x">
- 28. Pretty bad ● Butnot new ● Still, works like a charm! ● Update: A patch is on the way! ● Update II: Patch is out! ● But not new ● Did you like it though? ● Because we have “new” :)
- 29. Unknown Elements ● Again,we open our test suite ● Requires IE9 or older ● Two variations – one of which is new ● The other discovered by LeverOne
- 30. IN: <article xmlns="><imgsrc=x onerror=alert(1)"></article> OUT: <?XML:NAMESPACE PREFIX = [default] ><img src=x onerror=alert(1) NS = "><img src=x onerror=alert(1)" /><article xmlns="><img src=x onerror=alert(1)"></article>
- 31. IN: <article xmlns="x:img src=x onerror=alert(1)"> OUT: <img src=x onerror=alert(1) :article xmlns="x:img src=x onerror=alert(1) "></img src=x onerror=alert(1) :article>
- 32. Not Entirely Bad ●Few websites allow xmlns ● Everybody allows (or will allow) <article> though ● Harmless HTML5 ● Alas it's a HTML4 browser – as is IE in older document modes ● Wait, what are those again? ● <meta http-equiv="X-UA-Compatible" content="IE=IE5" /> ● Force the browser to fall-back to an old mode ● Old features, old layout bugs... ● And more stuff to do with mutations
- 33. “Now for somereal bad things!”
- 34. Style Attributes ● Everybodyloves them ● It's just CSS, right? ● XSS filters tolerate them ● But watch their content closely! ● No CSS expressions ● No behaviors (HTC) or “scriptlets” (SCT) ● Not even absolute positioning... ● ...or negative margins, bloaty borders
- 35. Let's have alook ● And use our test suite again ● All IE versions, older Firefox
- 36. IN: <p style="font-family:'223bx:expression(alert(1))/*'"> OUT:<P style="FONT-FAMILY: ; x: expression(alert(1))"></P>
- 37. “And there's somany variations!” And those are just for you, fellow conference attendees, they are not gonna be on the slides So enjoy!
- 38. HTML Entities ● Chromemessed up with <textarea> ● Found and reported by Eduardo ● Firefox screwed up with SVG <svg><style><img src=x onerror=alert(1)></svg> ● IE has problems with <listing> ● <listing><img src=x onerror=alert(1)></listing> ● Let's have another look again and demo... ● Also...text/xhtml! ● All CDATA will be decoded! ● That's also why inline SVG and MathML add more fun
- 39. Who is affected? ●Most existing HTML filters and sanitizers ● Thus the software they aim to protect ● HTML Purifier, funny, right? ● JSoup, AntiSamy, HTMLawed, you name it! ● Google Caja (not anymore since very recently) ● All tested Rich-Text Editors ● Most existing Web-Mailers ● This includes the big ones ● As well as open source tools and libraries ● Basically anything that obeys standards... ● .. and doesn't know about the problem
- 43.
- 44. Wait... it's encoded! <p style="font-family:'foo&#x5c;27&am p;#x5c;3bx:expr&#x65;ession(alert( 1))'"> Yep.Encoded. But does it matter? NO! mXSS mutations work recursively! Just access innerHTML twice! For your health!
- 46. How to Protect? ●Fancy Websites ● Enforce standards mode ● Avoid getting framed, use XFO ● <!doctype html> ● Use CSP ● Motivate users to upgrade browsers ● Avoid SVG and MathML ● Actual Websites ● Patch your filter! ● Employ strict white-lists ● Avoid critical characters in HTML attribute values ● Be extremely paranoid about user-generated CSS ● Don't obey to standards ● Know the vulnerabilities And for Pentesters? Inject style attributes + backslash or ampersand and you have already won. Nothing goes? Use the back-tick trick.
- 47. Alternatives ● mXSS Attacksrely on mutations ● Those we can mitigate in the DOM ● Behold... TrueHTML ● Here's a small demo ● We intercept any innerHTML access ● And serialize the markup... XML-style ● Mitigates a large quantity of attack vectors ● Not all though ● Know thy CDATA sections ● Avoid SVG whenever possible ● Inline-SVG is the devil :) And MathML isn't much better...
- 48. Takeaway? ● So, whatwas in it for you? ● Pentester: New wildcard-bug pattern ● Developer: Infos to protect your app ● Browser: Pointer to a problem-zone to watch ● Specifier: Some hints for upcoming specs
- 50. Wrapping it up ●Today we saw ● Some HTML, DOM and browser history ● Some old yet unknown attacks revisited ● Some very fresh attacks ● A “pentest joker” ● Some guidelines on how to defend ● The W3C's silver bullet. For 2015 maybe.
- 51. The End ● Questions? ●Comments? ● Can I have a drink now? ● Credits to ● Gareth Heyes, Yosuke Hasegawa, LeverOne, ● Eduardo Vela, Dave Ross, Stefano Di Paola