0

We are developing a website for a trucking company and it recently been subjected to penetration testing. One of the attacks done was injecting a XSS script into the request url:

ourcompanyhostname.com/abc/authorize<script>alert('xss');</script>

Since our web server is Apache, we have fixed the issue by setting up the ff. in the httpd.conf file. basically, rather reflecting the script in the 404 response erorr, a generic 400 response is thrown instead.

RewriteRule ^/abc/authorize/.*[^A-Za-z0-9./\-_]+ "-" [L,R=400]

The issue is when the attack was changed to the one below, it no longer can be caught:

ourcompanyhostname.com/abc/authorize%3c%3cSCRIPT%3ealert(%22XSS%22)%3b%2f%2f%3c%3c%2fSCRIPT%3e

Response still was 404 instead of 400.

Is there another way to achieve what we want? We already have tried doing the one below but it still won't work. We just want it to return an http 400 error when a XSS attack is done.

RewriteCond %{REQUEST_URI} ^.*(\*|;|<|>|\)|%0A|%0D|%3C|%3E|%00).* [NC]
RewriteCond %{REQUEST_URI} abc
RewriteRule ^(.*)$ "-" [L,R=400]
lecarpetron dookmarion
  • 519
  • 2
  • 7
  • 18

1 Answers1

0

I don't think the encoding matters, mod_rewrite sees the path in the URL after decoding.

I think you may have missed that your original rule requires matching a trailing slash after "authorize" and the new malicious request doesn't have it.

Your final rule works fine for me, if you get an unexpected result for a particular URL you have to study the rewritelog/logelvel trace8 output.

If the 404 is generated by Apache, just use a custom ErrorDocument for 404. If it is generated by your EE server, do the same in your web.xml.

covener
  • 17,402
  • 2
  • 31
  • 45