6

I have a textbox which makes a call to an API everytime the text has changed. The API returns JSON but executes any Javascript within the JSON returned (tested with Alert()). This textbox value is not persistent so saving does not result in a stored XSS. If the Javascript is pasted into the textbox, it's automatically encoded and rendered safely, it's only vulnerable if the script is typed in.

Other than a phishing attack where the user types in a script into the textbox, are there any other attacks that can be performed from this point? Can this self-XSS be chained to another attack or is it essentially only valid for phishing?

  • 2
    Check to see if you can chain it to a CSRF. If you can submit the form from an attacker controlled page and get it to run the script, then you've got a practical exploit. – Xander Nov 23 '16 at 16:49
  • @Xander: in that scenario, would the self-XSS make a difference? If the CSRF originates from the attacker's site and what is returned by the victim application is JSON and not HTML, this is only just CSRF yes? Or is the CSRF attack originating from the textbox on the victim application's page? – katrix Nov 23 '16 at 17:01
  • @katrix Ah, yes, you're right. I didn't think carefully enough about it. I don't see how it could work. – Xander Nov 23 '16 at 17:07
  • Will it also be escaped if you drag and drop the payload into the textbox instead of pasting? – Arminius Nov 23 '16 at 17:35
  • 1
    If there is no CSRF protection, then yes, it would run under the user's context. If the app doesn't have CSRF protection, I agree with you that that should be a finding in and of itself. – Xander Nov 23 '16 at 17:45
4

It is not normal or acceptable behavior for UI elements to execute user-supplied JavaScript. Although these bugs maybe difficult to exploit, they need to be patched because running malicious JavaScript means full account takeover.

UI Redress (aka clickjacking) can be used to populate the textbox. This technique was used to exploit self-inflicted XSS on google. The X-Frame-Options header element can be used to mitigate this attack.

Self-inflected javascript worms have spread on Facebook. Bad guys are always trying to convince the user into doing bad things. Some users are more than happy to shoot themselves in the foot, the attacker just needs to ask. Facebook has shown us that asking the user to copy/pasting malicious text is enough for a worm to spread.

tldr; fix your damn bugs!

| improve this answer | |
  • Thanks for your reply. I'll have a read through those links. The site itself can't be iframe due to the X-Frame-Options header and I've tried calling the GET endpoint myself but that just returns JSON (which when used with eval executes under my domain so no CSRF). Is it possible to send text to a particular element of another page if x-frame-options is being used? – iso123 Nov 24 '16 at 10:03
  • @iso123 Please spend some time reading bout the Same-Origin Policy - this isn't magic. – rook Nov 24 '16 at 20:57
  • Although the site in my case wouldn't load within an iFrame the answer is correct in what could be possible on other sites so marked as answer. I don't think there's another way of exploiting the JS being executed without the user typing it manually in my case. Thanks – iso123 Nov 25 '16 at 9:17
  • @iso123 it is not normal or acceptable behavior for a UI element to execute JavaScript. Stop asking if you should fix bugs, just do it. – rook Nov 27 '16 at 0:27
  • I can see my wording is ambiguous but it's not my site. I've reported the issue to the owner but this question was purely for my learning as this type of XSS isn't one I've come across in the wild and I wanted to see what ways an attack vector could surface. I have no control over their bug fixing but hopefully it'll be patched soon. – iso123 Nov 27 '16 at 1:13

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.