4

This OWASP article mentioned that "Using data validation, only reflected XSS can be detected and prevented, persistent XSS cannot be detected, DOM-based XSS only to be limited degree if part of the attack is sent in parameters of the request." Why is it so?

I understand once the malicious script gets stored in the application, now any GET/POST request won't look like malicious but the script will get executed at victim side. However to carry out a persistent XSS, an attacker has to send a malicious looking request to the server which should be sensed by WAF and hence should be stopped to get executed.

Improve this question

2 Answers 2

Reset to default
6

If you tightly adjust your WAF to your application so that it can fully distinguish valid from invalid input for specific input fields than you should be able to detect attempts to inject persistent XSS through the use of input fields.

But, usually WAF are not adapted that tightly to the specific application and in this case only employ some heuristics to detect common attacks. Apart from that persistent XSS can have different origins and don't even need to be added to the application by the use of input fields or even using the web interface at all. For example there was a stored XSS vulnerability within the amazon kindle store where the XSS was caused by script inside the metadata of the book description: Amazon.com Stored XSS via Book Metadata.

Improve this answer
2
  • can I say then even reflected xss can go un-noticed through fiewalls? It would depend a lot on rules of the firewalls?
    – one
    Commented Jul 5, 2016 at 12:33
  • @RuchShuk: Detection of reflected XSS is only done with some heuristics and thus might have false positives and false negatives. Like the reflected XSS detection inside current browsers they usually prefer to not block possibly innocent data and instead rather let possibly bad data pass.
    – Steffen Ullrich
    Commented Jul 5, 2016 at 13:29
4

I think that the point isn't phrased ideally, as a WAF can indeed catch some persistent XSS attacks.

But there are at least two problems:

  • persistent XSS attacks do not just happen via web requests, but could happen via a variety of other means, such as email. The vulnerability is really only introduced when data is read from the data storage - eg the db - and then printed. If you WAF doesn't listen on the connection between db and server - which isn't very common as far as I know - then it cannot detect this.
  • The context is missing. A WAF may look at the incoming request as well as the generated output. Thus, it can tell in what context user input is echoed, and if it is safe to do so. For persistent XSS, this context is missing, so it is not clear if eg ');alert('1 is safe input or not (or how the input is handled, and if it is made safe via encoding).
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .