2

I have this vulnerable code which takes a GET parameter, and puts it inside a HTML element (h1) as well as inside a HTML attribute (data-text):

$data = $_GET["payload"];
echo "<h1>" .$data. "</h1>";
echo '<div data-role="button"  data-text="' .$data.'"></div>';

The Chrome XSS auditor will block <script>alert(1)</script> in the first echo (inside the element), but not in the second (inside the attribute) even though the payload could be executed through a script gadget.

Why is that?

2

Because there is no vulnerability resulting from the HTML code in the second case (you would need to close the tags first, eg '"><script>alert(1)</script>; this would be caught by the auditor).

You may have JavaScript code which further processes your HTML code and thus introduces an XSS vulnerability in the second case as well (eg via script gadgets), but that is not what the XSS Auditor monitors:

The XSS Auditor runs during the HTML parsing phase and attempts to find reflections from the request to the response body. It does not attempt to mitigate Stored or DOM-based XSS attacks.

The JavaScript interpreter will be run after the HTML parser, so any vulnerabilities introduced by JavaScript will not be caught by the XSS auditor.

  • Only to the body of the response? so if the input from the request goes to the data-text attribute on the div element its ok? – Niv May 13 '18 at 12:34
  • @Niv I'm not sure I understand your question. – tim May 13 '18 at 12:35
  • in both request the input is the same, the only different is that in the first case the input goes between h1 tags and in the second case the input goes into data-text attribute. so this why the xss auditor dont block it? – Niv May 13 '18 at 12:38
  • @Niv Right, the input is the same, but the result is different. In the first case, you introduce an XSS vulnerability in the HTML code. In the second case, there is no vulnerability; the browser will correctly interpret the input as text value for an attribute and not execute the malicious JavaScript code. A vulnerability might be introduced by a JavaScript library, but that is not what the XSS auditor monitors. – tim May 13 '18 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.