7

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?

iso123
  • 95
  • 5
  • 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
  • @Xander - Would that run under the user's context? I can't try at the moment but considering it as a potential vector even if it doesn't use the XSS. – iso123 Nov 23 '16 at 17:43
  • @Arminius - Sorry, I should've mentioned, it doesn't work with drag/drop – iso123 Nov 23 '16 at 17:44
  • 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
  • @so123 the string `Alert()` is not a valid XSS test case. It sounds like you haven't tested the possibility of HTML tag injection. Xander brings up a good point, forms can be populated with a cross-site GET or POST request. – rook Nov 23 '16 at 23:29
  • @xander - thank you for your reply. I've tried to use the GET query via my own controlled site to the same endpoint but the server returns JSON with the content-type set as application/json in the header. If I eval the query, it executes under my contex. Maybe the CSRF isn't possible in this case? – iso123 Nov 24 '16 at 10:01
  • @rook - I've tested all commands and it works well so pretty much anything can be executed it seems but I can't get it to execute without the user typing it in manually. – iso123 Nov 24 '16 at 10:04

1 Answers1

5

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!

Community
  • 1
rook
  • 46,916
  • 10
  • 92
  • 181
  • 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 09: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 00: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 01:13