18

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?

  • 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 5:05
18

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://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

This has all the common stuff.

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

  • 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 9:41
  • Exactly! Not sure how to incorporate that fact into the post, though. – baordog 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
3

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.

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.