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]
Improve this question
4
  • 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 ♦
    Commented Dec 29, 2011 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
    Commented Dec 30, 2011 at 3: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
    Commented Dec 30, 2011 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
    Commented Dec 30, 2011 at 12:11

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .