2

I've downloaded a part of .htaccess to prevent from using base64_encode or <script> or _REQUEST within URL. Is this secure enough to help me out for partial security, or is it just a waste of time and resources?

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]  
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]  
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]  
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})  
RewriteRule .* index.php [F]
Alireza
  • 1,280
  • 1
  • 20
  • 26
  • In respect of partial security, sure - it will help. I guess the core info we'd need to try and answer whether it is an appropriate level of security is around what you are protecting, what your risk appetite is, and how your environment is structured. – Rory Alsop Dec 29 '11 at 14:07
  • Inside our web app every user has a wallet to store his money, every user can comment on the site, and they can of course participate in our online quizzes. they can upload their avatars. If somebody finds a loop hole to my DB, then everything would fall apart! @RoryAlsop – Alireza Dec 30 '11 at 03:18
  • I would be very worried if that's actual money! Handling user-submitted content properly is hard, especially uploaded files. WAF-style input scanning as discussed here can never make a vulnerable application properly secure, what it does is to obfuscate the issues from the most obvious attacks. The rules listed in the question are, in themselves, entirely useless. – bobince Dec 30 '11 at 11:39
  • well, that's not all @bobince. this is just part of my web app. I've done different kinds of XSS attack control. securing uploaded files by converting them to jpg to strip vulnerable headers, renaming them and many many more, but I know it's not enough and I want to hear more about security. – Alireza Dec 30 '11 at 12:11

1 Answers1

8

It is partial security as you mentioned, but this blacklisting approach will get you nowhere. For one, these snippets supposedly protect you from various attack vectors:

  • base64_encode looks for (most likely) PHP Remote Code Execution payload
  • script rule tries protect from XSS
  • the others are weird and possibly related to RCE or old PHP vulnerabilities where you could overwrite global variables.

Obfuscation

All of the rules you give are very simple to bypass, even with basic obfuscation. For example, XSS payload does not require <script> at all. For example, attacker might execute Javascript by sending <img src=1 onerror=js_code_here> and many, many other ways.

Obfuscation techniques are really advanced now and are often used to bypass application filters. If you're interested in obfuscation techniques, I recommend you read "Web Application Obfuscation" - it's an excellent book describing multiple ways of dealing with the filters you described.

What should I do then?

If you want to protect from malicious input to your application, the only way is to do both positive (i.e. not based on a blacklist) input validation and output escaping - you already should know how to do that from your previous question.

Web Application Firewalls

If you don't have control over application code (e.g. it's a legacy code deployed on a server that you need to maintain) or wish to take the 'defense in depth' route think about implementing Web Application Firewall e.g. based on mod_security. These firewalls are still base on a blacklists, so they won't offer 100% protection, but these blacklists are way more complete than the one you cite. For example, look at the problems mod_security faced & fixed when they announced a contest to bypass their SQL injection protection

Having said that, it's always best to fix the code of vulnerable application than to try to hide the vulnerability behind a firewall rule.

Community
  • 1
Krzysztof Kotowicz
  • 4,068
  • 20
  • 30