1

I understand why allowing arbitrary JS code enter persistent storage (e.g., in a database table that contains user comments) is a huge vulnerability since it may end up being served to other users.

But let's say the unescaped user input is never used or stored anywhere apart from being substituted into the HTML response immediately sent back to the same user? Does this open any vulnerability?

In other words, is there any harm in sending back to the user the HTML response that contains (in the worst case) arbitrary JS code created by the same user?

max
  • 135
  • 4
  • How do you know it is really entered by the user? Take for example `http://domain/reflected-xss`. This might be entered by the user or might be just a link the user clicked. And it can be more complex so that you cannot really decide if the input was produced *knowingly* by the user or not. – Steffen Ullrich Nov 03 '16 at 07:20
  • if the code was created by the user, then no, and further; devtools is a far easier way to run arbitrary JS. – dandavis Nov 03 '16 at 20:06

1 Answers1

2

You definitely shouldn't do it. Why do it wrong if it is so easy to do right? You should have mechanisms in place that automatically HTML encode all output variables (which will catch most but not all XSS issues); If you have to consider the dangers for each and every output, you will make a mistake at some point.

XSS in a user area can still be exploited if other vulnerabilities exist as well, either by using CSRF or by placing the XSS payload into an account the attacker controls and then forcefully logging the victim into that account (via Login CSRF, Session Fixation, or various other vulnerabilities).

Reflected XSS in a user area may also still be exploited via CSRF, or possibly via ClickJacking, if the browser allows drag/drop into a frame. Depending on the application, there may also be further corner-cases which allow an exploitation of this issue.

tim
  • 29,018
  • 7
  • 95
  • 119
  • Cool, I was just curious because some tutorials gave this example as the reason for escaping. I guess this example isn't ideal for learning (since it does not present any vulnerability on its own). But of course I understand I shouldn't actually allow this to happen in practice. – max Nov 03 '16 at 07:28
  • @max I would actually say that it does present a vulnerability on its own (which may or may not be exploitable at the current time). The same can be said about CSRF in this case. If the request just echoes input but doesn't change the server-state, you wouldn't technically need CSRF protection. But if you don't encode and don't have CSRF protection, your application is suddenly vulnerable. – tim Nov 03 '16 at 14:10