3

I have a webpage that blindly removes < and > as hardcoded rule. I know XSS doesn't always need < and > since it is not needed in HTML attribute and javascript contexts.

But is it possible to carry out XSS in HTML context without < and >? I saw it is possible in UTF-7(IE) where they can be replaced by other characters to make a valid HTML construct. Is it possible to do in any other way?

Or is it true that for HTML contexts just stripping < and > is sufficient since without them everything is treated as plaintext?

3
  • If it's getting reflected at the top of the page then it might be vulnerable to bom injection : security.stackexchange.com/a/180718/110133
    – Xavier59
    Nov 21, 2019 at 22:22
  • What about hex values with an & where you can encode the characters with it?
    – Cyberduck
    Nov 25, 2019 at 10:28
  • OWASP suggests you escape < > ' " & / in HTML context, but I've never understood the reason. It seems to me that just escaping < would actually be enough in practice. Maybe they are generalizing the advice for XML, but I'm still not sure why all those characters actually need to be escaped.
    – reed
    Apr 19, 2020 at 16:39

1 Answer 1

0

Generally I would not suggest to strip the tags from an input. This won't work sometimes and it would still be possible to generate a valid XSS attack like in your example. If you want to sanitize your input try using something like htmlspecialchars. This converts all your characters into HTML entities. So they are safe to display. If you want to allow HTML tags on your site I would suggest to use a html purifier so you can allow all tags you want. (Whitelist approach)

Regarding your question: This would generate a valid XSS on your site without the three mentioned elements:

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

This type of attack is called double encoding if you want to search for it. If you want more information about XSS try using the cheatsheat from OWASP or Github.

2
  • 2
    A double encoding attack will only work if the application in question is vulnerable to it (which not all are, and most probably aren't). As a result while that is certainly something to suggest, I think it's a bit unreasonable to assert that your proposed payload would generate an XSS. Nov 21, 2019 at 15:34
  • @ConorMancone 's comment makes sense & it is not open to double encoding. Any other way? Or is stripping < & > character is enough?
    – random1145
    Nov 22, 2019 at 5:55

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.