|License Type||SaaS | On-Premise|
|Main Product Category||Contrast UI|
How does the Contrast agent handle XXS attacks in Protect?
Our XSS rules are setup to block at perimeter-only. In Protect policy you may still see both blocking options Block or Block at Perimeter. This is to maintain backward compatibility with older agents. However any of our recent agents (beginning in 2020) will Block at Perimeter when either of these are set.
Why do we Block at Perimeter for XSS, unlike other rules?
There is only so much that an agent or WAF can do to stop XSS, since the exploit occurs on the client. The perimeter is the only place you can globally stop 2nd order attacks; before the response, the attacker might get their attack into a database, a cache, another web service, etc.
Blocking at the response is also difficult scale. There are many web rendering technologies that would have to be instrumented in order to add sufficient and consistent protection. With new ones added practically every day it would be very difficult to keep up.
This means that Contrast agents do not know if an XSS payload actually reaches a method vulnerable to XSS (e.g. printing
<script>alert(1)</script> )to the response.
Therefore when in monitor mode, we cannot report XSS as exploited. These will show up as probed events in the Contrast UI.
Rest assured that when Blocking is turned on, the agent will prevent these attacks from being exploited.