3
votes

DOM-based (type 0) XSS do not require sending malicious code to the server and thus they can also use static HTML pages as an attack vector. An example of a dummy attack string here would be the following:

http://www.xssed.edu/home.html#<script>alert("XSS")</script> 

I am familiar that ModSecurity offers protection against XSS attacks in PDFs which are considered type 0 attacks, however my question is if ModSecurity does in general prevent against this type of XSS and also in your opinion what are the impacts of such a vulnerability.

2

2 Answers

0
votes

Every web application firewall is working using signatures of attacks. Type-0 XSS generates the same signature as reflected XSS so this would probably be stopped by any WAF. Type-0 XSS does not occur due to server site code vulnerability but the request obviously reaches the server in the process of the page loading. The only issue that could prevent the WAF from stopping this kind of attack is the extension of the file, but I believe that in your example this would probably be stopped.

0
votes

It is actually possible if you were to rewrite the body of the rules. Lets take two example, eval and innerHTML sink which are vulnerable to DOM XSS. All we have to do is the rewrite the body of the output.

 SecRule REQUEST_URI "/sitestoprotect/" "chain,phase:4,t:none,t:urlDecode,t:lowercase,t:normalizePath"
    SecRule STREAM_OUTPUT_BODY "@rsub s/innerHTML/textContent/" "chain"
    SecRule STREAM_OUTPUT_BODY "@rsub s/var load/var msg = JSON.parse(e.data);var load"