23

If a website encodes < to &lt; and > becomes &gt;, is it still possible to perform cross site scripting? What would you enclose the script tags in?

For example, on one of my sites I can use <script>alert(1)</script> normally, but how can I do the same thing when encoding takes place?

Bob John
  • 343
  • 1
  • 2
  • 6
  • It could still be possible if parameters are directly used in javascript without being sanitized. I'd recommend to use output encoding all the time, not just for the characters < and >. – Jeroen Feb 17 '15 at 05:05

2 Answers2

21

Oh yes it is!

Consider this HTML:

<a href="{{str}}">

and consider an input like:

" onmouseover="alert('GOTCHA')"

You get the picture.

If your javascript is being injected within a tag then you don't need the angle brackets. I borrowed this off this similar S/O post: https://stackoverflow.com/questions/5696244/xss-is-escaping-and-sufficient

If you are interested in filter evasion like this consult:

https://owasp.org/www-community/xss-filter-evasion-cheatsheet

This has all the common stuff.

As far as safety is concerned: Encode all the things! You never know how clever the attacker is.

Yura Loginov
  • 103
  • 3
MrSynAckSter
  • 2,020
  • 10
  • 16
  • Remember that the console is your friend and enemy. I can watch all the XHR calls and then watch all the parameters being sent. Using the console, you can fake different requests that may bring your system to self-destruction. It's not only the input *in* the page, but **whatever you send**. Even what you receive must be carefully handled! – Ismael Miguel Feb 17 '15 at 09:41
  • Exactly! Not sure how to incorporate that fact into the post, though. – MrSynAckSter Feb 17 '15 at 14:52
  • honestly, me neither :/ But it would be precious information. Maybe someone who is better at words might be able to make a nice text. – Ismael Miguel Feb 17 '15 at 15:38
4

When it comes to Cross-site scripting, the most important thing is context. The context in which it gets reflected or stored.I will demonstrate this with a real example from my experience. Once while bug-hunting i noted that a URL parameter was getting reflected inside a variable:

http://www.example.com/blah.php?id=test&var=101011

The value of var was being reflected in the source of the page at page load, in roughly the following format, inside a script block:

var a = "101011";

and injecting as much as a '<' would divert the request to the WAF which would throw an error page, so my actual payload to deal with this was:

prompt(1)";eval(a);

which bypassed the WAF and became a successful case of reflected XSS. So, the payload should be modified according to context and you might not need the tags. Hope that helped.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
racec0ndition
  • 581
  • 4
  • 10