###################################################################################################################
# XSS injections
# html paranoid xss regex base exp (traps lots of false +)
0=log all ^(.*?)(?i)((\\%3C)|\\<)[^\\n]+((\\%3E)|\\>)(.*?)$
# http://www.owasp.org/index.php/HTTP_Response_Splitting
1=log all ^(.*?)(?i)((\\r\\n)+|\\r|\\n|(%0d%0a)+|%0d|%0a)(.*?)$
2=log all ^(.*?)(?i)(\\<|(\\%3C)|slt;|&lt;|<|<|<)(script|img|%0D)(.*?)$
3=log all ^(.*?)(?i)eval\\((.*)\\)(.*?)$
4=log all ^(.*?)(?i)[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\'](.*?)$
# SQL-ANSI naive meta keywords injections
#paranoid: ^(.*?)(?i)(delete|grant|insert|drop|replace|truncate|update|create|rename|describe|union|exec|openquery|openrowset|xp_cmdshell|addextendedproc)(.*?)$
5=log all ^(.*?)(?i)[(\\%27)|(\\')]{1}[%20|\\s|:cntrl:]*[(\\%6F)|o|(\\%4F)][(\\%72)|r|(\\%52)]{1}((\\s|\\+|:cntrl:)+).*(delete|grant|insert|drop|alter|replace|truncate|update|create|rename|describe|union)((\\s|\\+|:cntrl:)+)(.*?)$
# MS-SQL-SVR specific meta keywords + hex 0x
6=log all ^(.*?)(?i)(exec|openquery|openrowset|xp_cmdshell|addextendedproc|0x)((\\s|\\+|:cntrl:)+)(.*?)$
###################################################################################################################
Reference source link.
Cheers!
Sunday, October 31, 2010
XSS + SQL Injection Filter
The dangers are vast from blindly accepting requests these days for any public service that receives requests from clients in the web galaxy out there which could potentially lead to malicious xss | sql | etc injections, last week we started installing mod_security for apache httpd which is an open source intrusion detection that can run embedded or as a reverse proxy. The problem is, what if you do not run httpd in front of your servlet container or jee app server, then you need to have a way to intercept all requests before they reach your application, that's where filters come to the rescue, here's a naive reference implementation filter that wraps the HttpServletRequest object by cloning the parameters state and sanitising them via naive regex token replacement, I recommend reading the OWASP instructions for XSS and SQL there you'll see the top 10 most important rules to follow to avoid becoming a victim of sneaky malicious intents from our widely open and untrustworthy www.
I see two approaches here, a pessimistic IDS as intrusion detection (kind of mod_security) or a more optimistic one via content sanitation, take source as a reference implementation and adjust it to your needs, configure the rules with "log" and watch the noise and also the false positives (paranoid rules) and craft then specific regular expressions since I'm sure there'll be new tricky permutations over time. I included the OWASP encoding api calls there for you to investigate, drop me a line with your experiences | discoveries, again this is by no means a full fledged silver bullet but it'll give you an idea on how to approach xss via a filter, security is a huge matter as we know it.
I'm kind of troubled to see how much overhead mod_security will add to the farm by pre-processing hundreds of crazy regular expressions on every request (on top of the ones that the load balancer already does prior), seems to me a bit too exhaustive, so we'll just have to find out soon :)
Few rules with their corresponding regex, the paranoid ones should always log, once a specific rule+expression behaves as intended then promote it to deny (just make sure you're certain it won't deny on false positive, the tricky part!).
Subscribe to:
Post Comments (Atom)

0 comments:
Post a Comment