--- type: Whitepaper title: "Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials" description: Generates 12 million mutation-prone HTML fragments, sanitizes each with 11 server-side sanitizers, then renders the output in three browsers in both document and fragment mode, comparing parse trees by a bag-of-XPaths score. Text-content tags such as iframe and noscript, SVG/MathML namespace switches, CDATA and the --!> comment close are mishandled everywhere; with unencoded text nodes they bypass 9 of 11, and 19,843 payloads only turned dangerous after sanitizing. resource: "https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf" tags: [whitepaper, webseclist-reference, sanitizer-bypass, parser-differential, mutation-xss, xss, fuzzing, measurement-study, encoding, owasp-a03-2021, owasp-a05-2021] generated: by: webseclist-refs/1 at: "2026-08-14T22:36:05+00:00" status: stable stale_after: 2027-08-14 sources: - id: original resource: "https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf" title: "Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials" author: David Klein, Martin Johns also_at: [] authors: - David Klein - Martin Johns canonical_url: "" cited_by: - "2024.md:113" commit: "" content_sha256: 5d22ae6287462f02b7aeeba848635f75f04dc8431a2e02978c6fff31e7c51a84 depth: full depth_reason: default kind: whitepaper language: "" licence: unknown original_url: "https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf" published: "" publisher: "" publisher_english: "" raw_sha256: c30129a01ccf1fd656ca00e6420099ebf4d553f14d3516bdd9403be09a1136e2 retrieved_from: "https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf" retrieved_kind: manual-import retrieved_utc: "2026-08-14T22:36:05+00:00" slug: parse-me-baby-one-more-time-bypassing-html-sanitizer-parsing-differentials snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials **Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials** - David Klein, Martin Johns, Publisher not stated. - Published: date not stated - Original: - Preserved from: https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf (manual-import) on 2026-08-14 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials Parse Me, Baby, One More Time: Bypassing HTML Sanitizer via Parsing Differentials David Klein and Martin Johns Technische Universität Braunschweig {david.klein,m.johns}@tu-braunschweig.de Abstract—Websites rely on server-side HTML sanitization to Instead, we propose to take a step back and ask the defend against the ever-present threat of cross-site scripting question: Is server-side HTML sanitization even possible attacks. Parsing arbitrary pieces of markup to assess whether without mangling benign input? they contain an exploit payload is far from trivial. This Over the last years, the security community realized that complexity leads to divergences between the parsing results of accurate HTML sanitization is only possible with detailed the sanitizer and the user’s browser. These so-called parsing information on where in the website the sanitized result is differentials open the door for the unexplored category of inserted [14]. While this information is possibly available for mutation-based attacks. Here, an attacker abuses the sanitizer’s client-side sanitization, as the currently proposed Sanitizer incorrect HTML parser to either directly bypass it or coerce it API shows, it is out of reach for server-side sanitizers. This to transform benign markup into a dangerous exploit payload. context sensitivity influenced the design of the sanitizer In this work, we study the prevalence of such parsing API, which does not allow to perform a string-to-string differentials and their security impact. To this end, we built a transformation [15], declaring it generally unsafe to do so. generator for HTML fragments that are difficult to parse and On the server, this is the only type of transformation available, as ultimately, the sanitizer’s output ends up in an HTTP evaluated how 11 sanitizers across five programming languages response, which is text-based. deal with such inputs. We found that parsing differentials are Server-side sanitization routines face an additional chal- commonplace, as each assessed sanitizer has at least several lenge. To accurately sanitize an HTML fragment, that is, functional deficiencies leading to overzealous removal of benign only to remove the actively dangerous part, a sanitizer has input. Even worse, we were able to automatically bypass all to parse it in the same fashion as a browser. A cursory but two of the 11 sanitizers, painting a dire picture of the state glance at the HTML specification suffices to highlight the of server-side HTML sanitization. complexity of writing such a parser. Even if the sanitizer implements the specification perfectly, this does not suffice 1. Introduction either, as browsers can and do diverge from the specification. Therefore, to accurately sanitize, a sanitizer would have to parse its input exactly like the user’s browser would. This There are two frontiers to protect against cross-site requires information on the client’s browser, the parsing scripting (XSS): on the client and on the server-side. Tra- mode, and the exact injection context to adjust the sanitizer’s ditionally, client-side XSS protection has been seen as the behavior accordingly. This is not supported by any server-side difficult one, as the client offers no protection mechanisms, sanitizer. This problem is further aggravated by browsers and writing custom sanitization code is notoriously error- accepting invalid HTML input. Instead of aborting the parsing prone [1]. Google, for example, directly acknowledges this process, they try to rewrite and correct the input, i.e., mutating fact in their report on Trusted Type adoption: “More than it and changing the HTML structure in the process. While half of the DOM XSS root causes were due to bugs in HTML this behavior is partially specified, it adds another difficulty sanitizers” [2]. The academic community has also mainly for the authors of parsing and sanitization routines: Their focused on client-side XSS, from prevalence scanning [3– software would need to support the same behaviors to assess 8] to studying employed protection mechanisms [1, 9], the the security impact of HTML fragments correctly. Otherwise, body of work is extensive. Conversely, the exploration of it opens the door to mutation-based XSS vulnerabilities. server-side XSS remains notably underrepresented. Large- These issues raise two interesting questions: Is it feasible scale server-side security scanning is comparatively scarce, to write a sanitizer that is both accurate, i.e., does not mangle primarily due to ethical and legal challenges [10]. benign content, and secure? And how do popular open-source Due to modern server-side web development’s heavy sanitizing libraries fare in this respect? reliance on frameworks, one might assume robust defense These are the questions we will answer in this work. mechanisms are in place. Such defenses could come in the To assess the prevalence of parsing divergences, we first form of automatic sanitizer placement, as suggested in past analyzed the HTML specification, selecting HTML tags and work [11–13]. However, after inspecting the documentation edge cases that might lead to interesting parsing behavior. of 11 popular web frameworks about their XSS protections, We then present MutaGen, an HTML fragment generator we found this assumption to be lacking. with a special focus on fragments prone to mutations, and evaluate such fragments on our testbed. Here, we sanitize A stream-based HTML parser, i.e., a parser that emits the each generated fragment with 11 different sanitizers and result of each step in the tree construction stage, can never evaluate their outputs in all major browsers. We also record be specification-compliant. Scattered across the specification the DOM-like structure resulting from both the sanitizers as are points where the parser has to rearrange previously well as the browsers’ parsing processes. This allows us to processed elements. For example, inside a table, if the automatically assess if and where parsing behavior diverges parser encounters a tag that is not allowed to occur in and how this can lead to sanitizer bypasses. We detect severe this position, the foster parenting algorithm is invoked to parsing discrepancies between the evaluated sanitizers as rearrange the DOM and rehome the offending tag [18]. For well as between the major browsers. the input,
a stream parser would Our contributions are the following: emit the opening tags table, div and tbody. As the div • MutaGen: A generator for HTML fragments prone to tag is not a valid child of table, the parser invokes the mutations during parsing. foster parenting algorithm to correct the input. This results • An analysis framework that detects diverging parsing in
, i.e., it moves div behavior between sanitizers and web browsers. in front of the opening table. Consequently, a stream • We then use these building blocks to assess how 11 parser has to invalidate already emitted events, defeating its sanitization libraries are affected by parsing differentials. purpose. Thus, accurately parsing HTML is only possible in We found new bypass vectors for all but two and parsing a single pass. This complexity is a direct result of the desire deficiencies in all of them. to be always able to render a website, even if it violates The remainder of this paper is structured as follows: First, the HTML specification in one way or another. Instead we provide a recap on the required background in Section 2. of rejecting invalid markup, modern browsers attempt to We then detail the design of MutaGen and our evaluation repair the input and display it regardless. This repair step and analysis framework (Section 3), followed by an overview involves the aforementioned DOM transformations, such as of our findings and the efficacy of the presented approach foster parenting, effectively mutating the input. Websites in Section 4. Afterward, we discuss some major takeaways violating the specification are commonplace even today [19], and mitigation approaches (Section 5) and related work preventing browser vendors from tightening the parsing (Section 6) before we conclude in Section 7. process without breaking the web. Another noteworthy aspect is that modern browsers sup- 2. Background port two HTML parsing algorithms, document and fragment parsing [20]. Document parsing is the regular parsing mode In this section, we first introduce the intricacies of which processes a whole document. The fragment parsing HTML parsing. Afterward, we discuss (mutation) cross- mode instead relies on a context element and returns a DOM site scripting and how sanitization can protect against such fragment, i.e., a tree of nodes rooted at the context element. attacks. Lastly, we showcase how parsing differentials lead It is, for example, used for .innerHTML assignments. to HTML sanitizer bypasses. Differences in the behavior of these two modes are another source of potential issues. A well-known difference between 2.1. Complexities of HTML Parsing the two parsing modes is the handling of script tags, which are only executed in the document parsing mode. HTML is the premiere markup language on the web, The HTML standard mandates support for both of these supported by all browsers. However, its evolution has not two parsing algorithms. However, modern browsers might been straightforward. This is acknowledged in the official implement several parsers for each parsing mode. Chromium, specification, which states “that many aspects of HTML for example, has two fragment parsing algorithms. The appear at first glance to be nonsensical and inconsistent.” [16]. fastpath parser is used if the fragment only contains tags that Despite being seemingly simple, parsing and rendering do not require DOM rearrangements, and upon encountering HTML is a very involved process. From a visual point such a tag, it bails out to the regular one, which supports the of view, one would assume that parsing HTML and XML whole tag range [21]. By not considering all the intricacies of has many commonalities. They both derive from SGML HTML, the fastpath parser is generally faster. To top things and consequently share most syntax. Modern XML parsers off, HTML allows embedding so-called foreign content to offer two profiles: SAX-based [17] parsing and DOM-based support increasingly complex use cases. Both typesetting parsing. For the latter, the whole document is parsed into instructions for math formulas (via MathML [22]) and vector a tree structure and returned at once. SAX parsing has a graphics (via SVG [23]) can be directly inserted into HTML lighter memory footprint as it is a stream-based parsing documents. As they also share HTML’s ancestry, they also approach. As the parser reads the input, it emits parsing share some syntactic structure (and even tag names at times), events (e.g., opening tags) as it comes across them. One but additional complexities arise due to this combination. would assume the same is possible for HTML, but this would be a misconception. HTML parsing is divided into two stages: Example. Consider the input from Figure 2a, which tokenization, i.e., turning incoming bytes into tokens, and serves as the running example throughout this section. When tree construction, which builds a Document Object Model assigning it to the .innerHTML attribute of a div element, (DOM) tree from said tokens. Chromium parses the first img tag as an HTML element div context div img math img math img math img iframe iframe iframe #text (a) Chrome parsing the running example (c) Chrome parsing the result (b) Sanitizer parse tree Figure 1: Parsing differential leading to sanitizer bypass 1 (a) User input To prevent XSS, special care is required to ensure user 1 input is free from unwanted HTML markup. In this case, unwanted means tags executing code (such as the img tag (b) Sanitized result in the example) but can also include tags changing the Figure 2: Payload before (2a) and after (2b) sanitization. website’s layout in an undesirable fashion. The process of removing such unwanted markup is called sanitization. To do this accurately, the sanitizer has to determine whether a and adds it as the context nodes (i.e., the div element), first specific piece of text includes markup that might execute child. Then, upon encountering the math tag, the parser code. A common approach to sanitization is to parse the switches to the MathML mode (i.e., nodes are added with input according to the HTML specification and to operate their namespace set to MathML) and adds math as the on the resulting DOM tree. The sanitizer then traverses the second child. The following iframe tag is also parsed in DOM and removes or transforms nodes according to, e.g., MathML mode and added as the first child of math. Next, an allowed list of harmless tags or a block list of tags to the second img is processed. It is among the list of elements remove. Afterward, the sanitized DOM is serialized back that cause the parser to switch back to the HTML [24]. To into its textual representation and returned to the caller. do so, it closes the currently open elements (i.e., iframe For example, a sanitizer configured to allow both math and math) and inserts the img tag as the context’s third and iframe tags and to remove all img tags. When child, resulting in Figure 1a. HTML nodes are depicted in processing the running example from Figure 2a, its parsing blue, and those in the MathML namespace are in yellow. result is depicted in Figure 1b with a synthetic node as its root. To remove harmful tags, it considers each node in the 2.2. Cross-Site Scripting tree and removes the first image node, highlighted in red. All other nodes (colored green) are in its allow list (text nodes Cross-site scripting (XSS) is the most common vulnera- implicitly) and, therefore, stay untouched. The serialization bility class on the web. The goal behind an XSS attack is step again traverses the tree and converts each node to its for the attacker to execute code within the security domain HTML representation. Here, the input is usually cleaned of the website. This allows them to exfiltrate data such as beyond removing XSS payloads. As depicted in Figure 2b, cookies or inputs, perform actions on behalf of the user, the sanitizer adds closing tags that were omitted from the or manipulate the website’s content to trick the user into input. performing unwanted actions. An XSS vulnerability requires Sanitization stands in contrast to encoding, another pop- the attacker to be able to control some parts of the markup ular form of ensuring attacker-controlled input is free from of the website. Due to the fact that in HTML, there is no markup. The difference is that sanitization allows certain tags distinction between markup and data, at every point where to pass through and only removes (or encodes) potentially user-controlled data ends up on a website, there is a potential dangerous parts of the string. Encoding, on the other hand, XSS vulnerability. replaces control characters with their escaped form. If a Consider a website allowing users to leave comments, a string is inserted in the HTML context, e.g., inside a div basic form of community building. If a malicious user puts tag
${name}
, it would suffice to replace all in the running example from Figure 2a, every other visitor’s control characters with their character references. Turning browser parses the supposed comment as in Section 2.1. The 6.1. (Differential) Fuzzing of Web Technologies 2 Detecting vulnerabilities via automated test case gen- Figure 7: Two inline scripts, one with nonce and one without eration is the domain of the so-called fuzz testing. When applied to the web, it is mainly used to detect memory errors inside the browser. Fuzzing JIT compilers to detect which, e.g., bans inline event handlers and requires miscompilations leading to crashes and potential remote nonces or hashes to execute inline scripts, would pre- code execution vulnerabilities is a particularly active field vent typical XSS vulnerabilities, even in the presence of research [e.g., 59–61]. Similarly, the browser’s HTML of a sanitizer bypass. Such a CSP realizing such a parser implementation can and has been tested via fuzzing, separation could look like this: script-src ’self’ for example, by Xu et al. [62] with FREEDOM. https://jscdn.com ’nonce-rAnd0m’;. This pol- Semantic errors, i.e., bugs that do not manifest in crashes icy allows loading JavaScript files from both the same origin but unexpected or undesirable behavior, are a target less as the site (due to the ’self’ source) as well as from frequently considered for automated testing. This is due jscdn.com over HTTPS. Additionally, it allows inline scripts to fuzzing relying on so-called oracles to detect unexpected declared with nonce attribute set to r4nd0m. Inline event behavior. Adding an oracle to detect, e.g., buffer overflows handlers and scripts without a matching nonce are blocked. only requires compiling the browser with modified settings. In Figure 7, the first script declares a nonce matching the Creating an oracle detecting semantic issues is much more header, and g(’HTML’) executes. The second script has involved, as it requires analysis of the semantics of the no nonce attribute and is blocked due to the CSP. Such a application output. separation requires care, however. This nonce-based approach One recent example where fuzzing was applied to detect is easily defeated by directly putting attacker-controlled input semantic errors is by Kim et al. [63], who searched for into the script’s content, e.g., if an attacker can influence the universal cross-site scripting (UXSS) vulnerabilities. UXSS value ’HTML’. is universal in the sense that it does not only affect a single In general, deploying secure CSPs has proven to be origin but allows the attacker to run their code in all origins. challenging for most websites. Difficulties stem from third- A fuzzing technique focused on detecting divergences party code relying on inline scripts, forcing to forgo strict in behavior among different implementations for the same separation of markup and code by requiring directives such specification is differential fuzzing [64]. Here, inputs are gen- as unsafe-inline, which break the separation as shown erated and fed into several applications that, if correct, should by Steffens et al. [53]. Integrating third-party code is far behave the same. Differential fuzzing has been successfully from the only issue with deploying secure CSPs, as a wide applied to detect bugs in JavaScript JIT compilers [59], range of research shows [e.g., 54–57]. CPUs [65] and implementations of various protocols [66– 68] or specifications [69]. While we consider a similar setting, 5.6. Limitations & Future Work applying differential testing to HTML parsing is problematic. When validating a certificate, implementations are expected to always return the same result. This is not necessarily the In its current version, MutaGen only generates outputs case for HTML parsing, as some aspects are underspecified containing HTML, SVG, and MathML structure. All three and the negative consequences much less obvious. of these are syntactically similar. Consequently, all sanitizers process them accordingly. However, HTML has additional 6.2. Cross-Site Scripting integration points. Both CSS (Cascading Style Sheets) as well as JavaScript can be integrated directly into HTML As the most prevalent vulnerability class on the web, documents. As they are entirely different from a syntactical XSS has undergone extensive study. point of view, sanitizers must implement additional parsing Client-side XSS is the easiest to detect, as it takes place modes to support this. Some of the tested sanitizers, such as inside the client’s browser. Using a taint-tracking enabled AntiSamy, do this, for example, by integrating an additional browser, one can readily detect data flows susceptible to parsing library for CSS. However, the interaction between client-side XSS. This approach was successfully used to these languages is also a cause for bypasses, highlighted study the prevalence of client-side XSS [3–6, 8], improved by a recent vulnerability in rgrove/sanitize [58]. Extending exploit generation strategies [7] and potential defenses [70]. MutaGen to generate such payloads might be an exciting Similarly, Steffens et al. [71] studied the prevalence of client- opportunity for future work. side stored cross-site Scripting via dynamic taint tracking. The most related aspects to this work are those covering the generation of XSS exploit payloads [e.g., 3–7]. However, all 6. Related Work the noted works rely on detailed insights into the application gained via taint-tracking to craft targeted exploits. Our We group related work into three categories: (differential) approach, on the other hand, has no information into the fuzzing of web technologies, differential fuzzing, cross-site inner workings of the sanitizers or the browser’s HTML scripting, and security analysis of sanitizing routines. parser. The complexity of HTML parsing and its impact on parsing algorithms, but we were also able to bypass all but sanitizers has received less attention. Louw and Venkatakr- two of them automatically. These findings highlight the sorry ishnan [72] suggested circumventing this issue by making the state of server-side HTML parsing and sanitization, a topic browser build the DOM programmatically without relying left unexplored for far too long. on it parsing the response in the same fashion. Simplifying the HTML specification is another seemingly attractive idea. Acknowledgments By removing problematic tags and features, most of the issues presented in this work could be prevented. However, We gratefully acknowledge funding by the Deutsche according to a recent study by Hantke and Stock [19], a large Forschungsgemeinschaft (DFG, German Research Founda- tion) under Germany’s Excellence Strategy – EXC 2092 portion of Websites rely on HTML parsing quirks. Thus, CASA – 390781972 as well as from the European Union’s simplifying the parsing process is not a realistic option in the Horizon 2020 research and innovation programme under near future. mXSS vulnerabilities have seen comparatively project TESTABLE, grant agreement No 101019206. little academic attention, with only the seminal work by Heiderich et al. [25] covering it in depth. Its primary focus, References however, was on browser-based mXSS vectors, while we [1] D. Klein, T. Barber, S. Bensalim, B. Stock, and M. Johns, “Hand focus on what they called “mutation based attacks” [25]. Sanitizers in the Wild: A Large-scale Study of Custom JavaScript Sanitizer Functions,” in European Symposium on Security and Privacy, 6.3. Sanitizer Analysis 2022. [2] K. Kotowicz, “Trusted types - mid 2021 report,” https://research. google/pubs/pub50512, Google Research, Tech. Rep., 2021. A lot of work has studied the security properties of [3] S. Lekies, B. Stock, and M. Johns, “25 Million Flows Later: Large- HTML sanitizers, both on the client [1, 9, 37] as well on the scale Detection of DOM-based XSS.” in Conference on Computer server-side [36, 73–75]. However, These works focus on and Communications Security, 2013. implementation mistakes in the actual sanitizer code, i.e., by [4] W. Melicher, A. Das, M. Sharif, L. Bauer, and L. Jia, “Riding out DOMsday: Towards Detecting and Preventing DOM Cross-Site analyzing string modification chains. The bugs we consider Scripting.” in Network and Distributed Systems Security, 2018. are frequently outside the sanitizer’s direct control due to [5] B. Stock, M. Johns, M. Steffens, and M. Backes, “How the Web the used HTML parsers returning false parsing results. Tangled Itself: Uncovering the History of Client-Side Web (In)Security.” That relying on custom HTML parsing code is prob- in USENIX Security Symposium, 2017. [6] B. Stock, S. Pfistner, B. Kaiser, S. Lekies, and M. Johns, “From lematic has been highlighted by and integrated into DOM- Facepalm to Brain Bender: Exploring Client-Side Cross-Site Scripting.” Purify [47]. However, as shown in Section 4, the chosen in Conference on Computer and Communications Security, 2015. approach only works reliably on the client, as the sanitizer [7] S. Bensalim, D. Klein, T. Barber, and M. Johns, “Talking About can access the browser’s HTML parsing logic. My Generation: Targeted DOM-based XSS Exploit Generation using Dynamic Data Flow Analysis,” in European Workshop on Systems Security, 2021. 7. Conclusion [8] D. Klein, M. Musch, T. Barber, M. Kopmann, and M. Johns, “Accept All Exploits: Exploring the Security Impact of Cookie Banners,” in While HTML has an official specification codifying Proc. of the Annual Computer Security Applications Conference, 2022. [9] D. Bates, A. Barth, and C. Jackson, “Regular Expressions Considered expected parsing behavior, implementing it correctly is Harmful in Client-Side XSS Filters,” in WWW, 2010. challenging. This even affects the major browsers, which can [10] F. Hantke, S. Roth, R. Mrowczynski, C. Utz, and B. Stock, “Where not always agree on how a piece of markup shall be parsed. are the red lines? towards ethical server-side scans in security and The situation is even worse for server-side HTML sanitizers privacy research,” in IEEE Symposium on Security and Privacy, 2024. [11] J. Weinberger, P. Saxena, D. Akhawe, M. Finifter, E. Shin, and D. Song, despite them being an integral part of most websites’ security “A Systematic Analysis of XSS Sanitization in Web Application apparatus. On the server, HTML sanitizers are fighting a Frameworks,” in ESORICS, 2011. losing battle, as they do not have sufficient information to [12] M. Samuel, P. Saxena, and D. Song, “Context-sensitive auto- accurately parse attacker-controlled input in the same way sanitization in web templating languages using type qualifiers,” in Conference on Computer and Communications Security, 2011. a browser does. The used parsing mode, dynamic parsing [13] P. Saxena, D. Molnar, and B. Livshits, “SCRIPTGARD: Automatic state flags, the employed browser, and its quirks are all Context-Sensitive Sanitization for Large-Scale Legacy Web Appli- information out of reach for the sanitizer. Lacking this cations,” in Conference on Computer and Communications Security, information, it has to make an educated guess, frequently 2011. [14] W. P. I. C. Group, “HTML Sanitizer API,” https://wicg.github.io/ with devastating consequences. Parsing differentials, i.e., sanitizer-api, 2022, accessed 8.12.2023. diverging parsing behaviors between sanitizer and browser, [15] ——, “HTML Sanitizer API,” https://wicg.github.io/sanitizer-api/ are one consequence of these problems and a direct security #strings, 2022, accessed 8.12.2023. threat: Either allowing nefarious actors to bypass the sanitizer [16] WHATWG, “HTML Standard: 1.7 Design Notes,” https://html.spec. whatwg.org/#design-notes, accessed 8.12.2023. completely or to abuse the supposed protection mechanisms, [17] D. Megginson, “SAX,” http://www.saxproject.org/, 2004, accessed: making it transform benign input into harmful exploits. 8.12.2023. In this paper, we presented MutaGen, a generator for [18] WHATWG, “HTML Standard: 13.2.10.3 Unexpected markup in tables,” mutation-prone pieces of HTML. Using MutaGen and our https://html.spec.whatwg.org/multipage/parsing.html#unexpected- markup-in-tables, accessed 8.12.2023. evaluation testbed, we assessed how 11 sanitizers across five [19] F. Hantke and B. Stock, “HTML Violations and Where to Find Them: programming languages deal with these kinds of inputs. Not A Longitudinal Analysis of Specification Violations in HTML,” in only did we uncover functional deficiencies in each of their Internet Measurement Conference, 2022. [20] WHATWG, “HTML Standard: 13.4 Parsing HTML fragments,” https:// comment,” https://html.spec.whatwg.org/multipage/parsing.html#parse- html.spec.whatwg.org/multipage/parsing.html#fragment-case, accessed error-incorrectly-closed-comment, accessed 8.12.2023. 8.12.2023. [44] ——, “HTML Standard: 13.2.6.4.16 The ”in select” insertion [21] T. C. Authors, “html document parser fastpath.cc,” https: mode,” https://html.spec.whatwg.org/multipage/parsing.html#parsing- //source.chromium.org/chromium/chromium/src/+/main:third party/ main-inselect, accessed 8.12.2023. blink/renderer/core/html/parser/html document parser fastpath.cc, [45] T. Nidecki, “Mutation XSS in Google Search,” https://www.acunetix. accessed 8.12.2023. com/blog/web-security-zone/mutation-xss-in-google-search, 2019, ac- [22] W3C, “Mathematical Markup Language (MathML) Version 3.0 2nd cessed: 8.12.2023. Edition,” https://www.w3.org/TR/MathML3, accessed 8.12.2023. [46] W3C, “Document Structure – SVG 2,” https://svgwg.org/svg2-draft/ [23] ——, “Scalable Vector Graphics (SVG) 2,” https://svgwg.org/svg2- struct.html#DescriptionDefinitions, accessed 8.12.2023. draft, accessed 8.12.2023. [47] M. Heiderich, C. Späth, and J. Schwenk, “DOMPurify: Client-Side [24] WHATWG, “HTML Standard: 13.2.6.5 the rules for parsing tokens Protection against XSS and Markup Injection,” in ESORICS, 2017. in foreign content,” https://html.spec.whatwg.org/multipage/parsing. [48] W. Kahn-Greene, “bleach is deprecated; statement on project going html#parsing-main-inforeign, accessed 8.12.2023. forward (2023-01-23),” https://github.com/mozilla/bleach/issues/698, [25] M. Heiderich, J. Schwenk, T. Frosch, J. Magazinius, and E. Z. 2023, accessed 8.12.2023. Yang, “mXSS Attacks: Attacking well-secured Web-Applications [49] N. Demir, T. Urban, K. Wittek, and N. Pohlmann, “Our (in)Secure by using innerHTML Mutations,” in Conference on Computer and Web: Understanding Update Behavior of Websites and Its Impact on Communications Security, 2013. Security,” in Passive and Active Network Measurement Conference, [26] D. Klein, “HTML Parsing Differentials,” https://github.com/ias-tubs/ 2021. HTML parsing differentials, 2023, accessed: 8.12.2023. [50] web-platform-tests contributors, “The web-platform-tests project,” [27] M. Bentkowski, “HTML sanitization bypass in Ruby Sanitize https://github.com/web-platform-tests/wpt, accessed 8.12.2023. <5.2.1,” https://research.securitum.com/html-sanitization-bypass-in- [51] Y. Nadji, P. Saxena, and D. Song, “Document structure integrity: ruby-sanitize-5-2-1, 2020, accessed 8.12.2023. A robust basis for cross-site scripting defense.” in Network and [28] ——, “Write-up of DOMPurify 2.0.0 bypass using mutation XSS,” Distributed System Security Symposium, 2009. https://research.securitum.com/dompurify-bypass-using-mxss, 2019, [52] M. V. Gundy and H. Chen, “Noncespaces: Using randomization to accessed 8.12.2023. enforce information flow tracking and thwart cross-site scripting [29] ——, “Mutation XSS via namespace confusion – DOM- attacks.” in Network and Distributed System Security Symposium, Purify <2.0.17 bypass,” https://research.securitum.com/mutation- 2009. xss-via-mathml-mutation-dompurify-2-0-17-bypass, 2019, accessed [53] M. Steffens, M. Musch, M. Johns, and B. Stock, “Who’s Hosting the 8.12.2023. Block Party? Studying Third-Party Blockage of CSP and SRI,” in [30] E. Yalon, “Mutation Cross-Site Scripting (mXSS) Vulnerabilities Network and Distributed System Security Symposium, 2021. Discovered in Mozilla-Bleach,” https://securityboulevard.com/2020/ [54] M. Weissbacher, T. Lauinger, and W. K. Robertson, “Why Is CSP 07/mutation-cross-site-scripting-mxss-vulnerabilities-discovered-in- Failing? Trends and Challenges in CSP Adoption,” in Research in mozilla-bleach, 2020, accessed 8.12.2023. Attacks, Intrusions and Defenses, 2014. [31] WHATWG, “HTML Standard: 4 The elements of HTML,” https: [55] S. Calzavara, A. Rabitti, and M. Bugliesi, “Content security problems?: //html.spec.whatwg.org/multipage/semantics.html#semantics, accessed Evaluating the effectiveness of content security policy in the wild,” in 8.12.2023. Conference on Computer and Communications Security, 2016. [32] ——, “HTML Standard: 13.2 Parsing HTML documents,” https://html. [56] L. Weichselbaum, M. Spagnuolo, S. Lekies, and A. Janc, “CSP is dead, spec.whatwg.org/multipage/parsing.html, accessed 8.12.2023. long live CSP! On the insecurity of whitelists and the future of content [33] ——, “HTML Standard: 4.8.5 the iframe element,” https: security policy,” in Conference on Computer and Communications //html.spec.whatwg.org/multipage/iframe-embed-object.html#the- Security, 2016. iframe-element, accessed 8.12.2023. [57] S. Roth, T. Barron, S. Calzavara, N. Nikiforakis, and B. Stock, [34] ——, “HTML Standard: 3.2.5.1 the ”nothing” content model,” “Complex Security Policy? A Longitudinal Analysis of Deployed https://html.spec.whatwg.org/multipage/dom.html#the-nothing- Content Security Policies,” in Network and Distributed Systems content-model, accessed 8.12.2023. Security, 2020. [35] ——, “HTML Standard: 13.2.2 Parse errors,” https://html.spec.whatwg. [58] R. Grove, “Insufficient neutralization of ‘style‘ element content may org/multipage/parsing.html#parse-errors, accessed 8.12.2023. allow XSS in Sanitize,” https://github.com/rgrove/sanitize/security/ [36] D. Balzarotti, M. Cova, V. Felmetsger, N. Jovanovic, E. Kirda, advisories/GHSA-f5ww-cq3m-q3g7, 2023, accessed 8.12.2023. C. Kruegel, and G. Vigna, “Saner: Composing Static and Dynamic [59] L. Bernhard, T. Scharnowski, M. Schloegel, T. Blazytko, and T. Holz, Analysis to Validate Sanitization in Web Applications.” in IEEE “JIT-Picking: Differential Fuzzing of JavaScript Engines,” in Confer- Symposium on Security and Privacy, 2008. ence on Computer and Communications Security, 2022. [37] M. Alkhalaf, T. Bultan, and J. L. Gallegos, “Verifying Client-Side [60] H. Han, D. Oh, and S. K. Cha, “CodeAlchemist: Semantics-Aware Input Validation Functions using String Analysis,” in International Code Generation to Find Vulnerabilities in JavaScript Engines,” in Conference on Software Engineering, 2012. Network and Distributed System Security Symposium, 2019. [38] M. Alkhalaf, A. Aydin, and T. Bultan, “Semantic Differential Repair [61] S. Groß, S. Koch, L. Bernhard, T. Holtz, and M. Johns, “Fuzzilli: for Input Validation and Sanitization,” in International Symposium on Fuzzing for JavaScript JIT Compiler Vulnerabilities,” in Network and Software Testing and Analysis, 2014. Distributed Systems Security, 2023. [39] S. Joshi, N. Agrawal, R. Krishnapuram, and S. Negi, “A Bag of Paths [62] W. Xu, S. Park, and T. Kim, “FREEDOM: Engineering a State-of-the- Model for Measuring Structural Similarity in Web Documents,” in Art DOM Fuzzer,” in Conference on Computer and Communications International Conference on Knowledge Discovery and Data Mining, Security, 2020. 2003. [63] S. Kim, Y. M. Kim, J. Hur, S. Song, G. Lee, and B. Lee, “FuzzOrigin: [40] WHATWG, “HTML Standard: 13.2.5.2 RCDATA state,” https:// Detecting UXSS vulnerabilities in browsers through origin fuzzing,” html.spec.whatwg.org/multipage/parsing.html#rcdata-state, accessed in USENIX Security Symposium, 2022. 8.12.2023. [64] T. Petsios, A. Tang, S. J. Stolfo, A. D. Keromytis, and S. Jana, [41] ——, “HTML Standard: 13.2.4.5 Parse state: Other parsing “NEZHA: Efficient Domain-Independent Differential Testing,” in IEEE state flags,” https://html.spec.whatwg.org/multipage/parsing.html# Symposium on Security and Privacy, 2017. other-parsing-state-flags, accessed 8.12.2023. [65] J. Hur, S. Song, D. Kwon, E. Baek, J. Kim, and B. Lee, “DifuzzRTL: [42] ——, “HTML Standard: 13.2.2 Parse errors: cdata-in-html-content,” Differential Fuzz Testing to Find CPU Bugs,” in IEEE Symposium on https://html.spec.whatwg.org/#parse-error-cdata-in-html-content, ac- Security and Privacy, 2021. cessed 8.12.2023. [66] B. Jabiyev, S. Sprecher, K. Onarlioglu, and E. Kirda, “T-Reqs: HTTP [43] ——, “HTML Standard: 13.2.2 Parse errors: incorrectly-closed- Request Smuggling with Differential Fuzzing,” in Conference on Computer and Communications Security, 2021. encoding(): Returns an encoding function applicable to [67] G. S. Reen and C. Rossow, “DPIFuzz: A Differential Fuzzing another value. Possible values are {None, Xml} with Framework to Detect DPI Elusion Strategies for QUIC,” in Annual Computer Security Applications Conference, 2020. P(N one) = 0.4 and P(Xml) = 0.1. [68] C. Brubaker, S. Jana, B. Ray, S. Khurshid, and V. Shmatikov, quote(): This function returns an optionally encoded “Using Frankencerts for Automated Adversarial Testing of Certificate quote character. Possible values are chosen from: Validation in SSL/TLS Implementations,” in IEEE Symposium on {Backtick(e), Single(e), Double(e)} where e = encoding() Security and Privacy, 2014. [69] S. Wi, T. T. Nguyen, J. Kim, B. Stock, and S. Son, “DiffCSP: with respective probabilities of P(Single) = 0.45, Finding Browser Bugs in Content Security Policy Enforcement through P(Double) = 0.45 and P(Backtick) = 0.1. Differential Testing,” in Network and Distributed System Security This function is used to determine how attributes are Symposium, 2023. quoted. Only single and double quotes are valid according [70] B. Stock, S. Lekies, T. Mueller, P. Spiegel, and M. Johns, “Precise to the specification, so they are generated more frequently. Client-side Protection against DOM-based Cross-Site Scripting,” in USENIX Security Symposium, 2014. quoted(v): Determines how an attribute’s value (provided [71] M. Steffens, C. Rossow, M. Johns, and B. Stock, “Don’t Trust the as v ) is quoted. Possible values are chosen from the set: Locals: Investigating the Prevalence of Persistent Client-Side Cross- Site Scripting in the Wild.” in Network and Distributed System Security {Unquoted, Enclosed(quote()), Symposium, 2019. [72] M. T. Louw and V. N. Venkatakrishnan, “Blueprint: Robust preven- Front(quote()), Back(quote()), tion of cross-site scripting attacks for existing browsers.” in IEEE Mixed(quote(), quote())} Symposium on Security and Privacy, 2009. [73] P. Hooimeijer, B. Livshits, D. Molnar, P. Saxena, and M. Veanes, Unquoted results in an unquoted value and Mixed in a “Fast and Precise Sanitizer Analysis with BEK.” in USENIX Security value with potentially mismatching quotes, depending on Symposium, 2011. [74] G. Argyros, I. Stais, A. Kiayias, and A. D. Keromytis, “Back in Black: the return values of its parameters. Both Front and Back Towards Formal, Black Box Analysis of Sanitizers and Filters,” in result in a quote on either side of the value, and Enclosed IEEE Symposium on Security and Privacy, 2016. properly quotes the value. Their respective probabilities [75] J. Dahse and T. Holz, “Experience Report: An Empirical Study of are P(U nquoted) = 0.5, P(M ixed) = 0.25, P(F ront) = PHP Security Mechanism Usage,” in International Symposium on Software Testing and Analysis, 2015. 0.25, P(Back) = 0.25 and P(Enclosed) = 1.0. attr key(): Returns a string from the set {id, name, title, foo, data-foo} with equal Appendix A. probability. We chose this selection to cover different Implementation attribute types that do not execute JavaScript on their own. We avoided generating event handlers that might directly cause JavaScript execution, as testing the completeness of The payload generation is based on randomly selecting block lists would offer no additional insight into the parsing a sequence of transformations to consecutively build up the behavior. final payload. attr form(): To represent invalid attribute values, we in- Whenever a transformation or one of its parameters is troduce the possibility of generating incorrectly format- selected, each option is chosen with a relative probability ted attributes. This function returns values from the set P. Take the div and br tags as an example, their relative {Regular, Space, Slash}, modeling such issues. Their probabilities are: P(div) = 1.0 and P(br) = 0.5. This means probabilities are P(Regular) = 0.9, P(Space) = 0.05 and MutaGen generates twice as many div tags as br tags. P(Slash) = 0.05. attr(v): Generates a potentially quoted HTML attribute with A.1. Parameterized Transformations the value v . Based on the return values of k = attr key(), f = attr f orm() and q = quoted() an attribute is se- Most of the transformations applied by MutaGen are rialized as follows: An attribute is serialized as follows parameterized. We now give a short overview of the different k = quoted(v) if f = Regular. For f equals Space, a parameter types, their respective values, and how likely they whitespace character precedes the value, and if f is Slash, are applied. the initial space is replaced with a slash character. payload(): This function returns an initial payload. They are tag(): Selects one of the HTML, SVG, or MathML tags chosen from the following set: {Img, Image, Script} listed in Table 7 with a sequence of attributes with static with relative probability of P(Img) = 0.6, P(Image) = 0.2, values. The relative probabilities for each tag are provided P(Script) = 0.2. Each payload is serialized as follows: in column P. These probabilities were assigned manually • Img: to group similar elements such as mi, mo, mn, and ms to • Image: uncover a wide breadth of different payloads. • Script: bracket(): Returns either an opening or closing angle bracket We decided to mainly generate XSS payloads based on img with equal possibility. tags as it is the most universally applicable tag. bang(): Selects whether the generated XML comment should place(): Returns whether the transformation should change be closed according to the HTML specification (i.e., -->) the beginning or the end of P , returning either Prepend or with a bang comment (i.e., --!>). Values are chosen or Append with equal probability. from the set: {No_bang, Bang} with equal probability. Table 6: Complete List of Transformations Applied to the Accumulated Payload P Name P Parameters Effect Description Payload pl = payload() P = pl ( Select an initial Payload t = tag() P, if p = Prepend Open tag 1.0 P= Add opening tag t to P p = place() P , if p = Append ( t = tag(), P, if p = Prepend Self closing tag 1.0 P= Add self closing tag t to P p = place() P , if p = Append Enclose tag 1.0 t = tag() P = P Enclose P in tag t t = tag(), Enclose tag attr 0.75 P = Enclose P in attribute a of tag t a = attr() ( t = tag() P, if p = Prepend Close tag 1.0 P= Add closing tag t to P p = place() P , if p = Append ( P, if p = Prepend Close XML Comment 0.125 P= Add closing XML comment to P b = bang() P - -b>, if p = Append Enclose XML Comment 0.125 b = bang() P = Enclose P with XML comment Enclose JS Comment 0.01 P=/ (*P */ Enclose P in JavaScript comment /*P, if p = Prepend Open JS Comment 0.005 p = place() P= Add opening JavaScript comment to P P /*, if p = Append ( /P, if p = Prepend Close JS Comment 0.005 p= place() P= * Add closing JavaScript comment to P P */, if p = Append Enclose CDATA 0.05 P = Enclose P in CDATA section. P, if p = Prepend End CDATA 0.05 p = place() P= Add end CDATA directive to P P ]]>, if p = Append (