4

This question already has an answer here:

Code

I've seen these types of instances occur quite often, and I'm curious to why (even without a filter) they won't execute... as the code is right there. Every occurrence of this I've noticed that when you inspect in any developer tool the tags aren't formatted; so in a visual perspective, just gray text. I know it's a vague question with not much content/context, but in any sense how is a, seemingly, unfiltered place of input like this, not exploitable and rendered without a XSS issue?

Edit: I used Chrome (with XSS protection disabled), Firefox, and Internet Explorer (there's a warning message when it filter something it believes is cross site scripting). This obviously ended with no results or explanation.

Result

This is the element example I gave when you follow it.

marked as duplicate by Alexander O'Mara, Xander, Steve, CaffeineAddiction, Ohnana Mar 22 '17 at 18:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • To answer this, we would need a bit more information. I tried to give a canonical answer to these types of question here: Why isn't XSS working?, maybe it can solve your question (I would guess it's a problem with CSP or maybe browser filters) or at least help you to add a bit more detail (eg that you can exclude CSP and browser filters as reasons; it would also be helpful to know which browser you are using, etc). – tim Mar 21 '17 at 18:00
  • 2
    Have you looked in the request data to make sure the tags aren't escaped to HTML sequences? And are you sure it's the same on all browsers? In Firefox, you have to right-click on the tag the offending text is contained in and Copy Inner HTML to paste elsewhere to check. – dreamist Mar 21 '17 at 18:07
  • @dreamist , through a proxy I can see that my data (being sent through POST data) is url encoded, but that doesn't seem to be a red flag. Though I've never checked any values through that innerHTML option... "</div> <script>alert(/xss/)</script><div>" --> now that's a red flag. Can you explain what exactly it copies and from where? – Ryan Mar 21 '17 at 19:25
  • It copies anything between a opening and closing tag, but does copying it that way have anything to do with the way it's encoded – Ryan Mar 21 '17 at 19:45
  • Your brackets were escaped for safety. The way you see it copied out there is the way it's truly encoded within the browser. – dreamist Mar 22 '17 at 12:24
2

This doesn't have anything to do with XSS filters, as evidenced by the same behavior across many browsers. It's not a queryString thing, it's just content. The answer is simple and re-assuring.

Inline script tags added via .innerHTML=strHTML, or the DOM method elm.appendChild(script) don't execute. This means you can inject malicious tags in all day; unless such tags hit the browser as hard-coded HTML (can be seen in view-source), they are benign.

jQuery's over-used $(elm).html(strHTML) method WILL run scripts, but only because it parses the string content and sends <script> tag content to the window.eval() function, which executes it. By default though, dynamic script tag content is NOT executed.

Your example uses react, which has a virtual DOM that reconciles existing page HTML and dynamic HTML internally using a non-DOM model. Once the changes are found, a series of small DOM-element replacements are made. Here again, adding <script> tags via the DOM doesn't execute tag contents, so this is safe in any browser.

You still need to look out for attribute-based "event handlers" like onerror, onload, onmouseover, etc, but <script>somethiungBad()</script> is benign if it's not printed by a server or "smartly" added by jQuery. The React framework used in the example might filter those problematic attributes for you, i'm not an expert on React...

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