Security is not easy-to-use, not fancy and it is hard to remember all those nasty attack methods. So there are automatic security checks, firewalls, helpers and a lot more. They are built to make your application more secure. But automatic security tools can't help you to find logic faults. What if you have a Cross-Site Scripting scanner that checks each and every field in your web application, but with a little knowledge, an attacker could change one id in the URL and he sees his neighbor's confidential data.
BUT, automatic tools can be of great help, if you won't solely rely on them. The SafeErb plugin reminds you to sanitize output, but it doesn't do it automatically. A mass-assignment scanner might find this kind of security holes in you application. Or a web application firewall may protect holes you are not aware of. And, of course, security is a process and should be incorporated into the entire project life cycle.
That having said, I'd like to show you a nice web application firewall for your .htaccess, if you happen to use Apache. It comes from 0×000000.com, a whitehat hacker site, and it's the result of seven years of server administration. It is not perfect, it is not especially for Rails applications or for your specific application, but it is definitely a good starting point. You can read the tutorial for explanation.
RewriteEngine On
Options +FollowSymLinks
ServerSignature OffRewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC,OR]RewriteCond %{HTTP_REFERER} ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set
|declare|drop|update|md5|benchmark).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]RewriteRule ^(.*)$ access_log.php
6 responses so far ↓
1 Thorben // Jun 17, 2008 at 3:08
Cool thing
But remember to allow the DELETE request method if you are working on a RESTful architecture 
In the file above it is killed by default.
2 Christoph // Jun 17, 2008 at 4:09
Thanks for the link, could be useful.
Speaking of it, do you have any resources for the mentioned automatic tools to check security?
Thanks
3 Clinton R. Nixon // Jun 17, 2008 at 4:24
This is not good advice. Much of this doesn’t apply to a Rails app, but worse, you’re blocking wget and curl, tools people use every day for appropriate purposes. Some people think security and usability are opposite ends of a spectrum: I call that defeat.
Advising people to use an Apache config they do not fully understand is weak sauce.
4 Mike Boone // Jun 17, 2008 at 4:29
This looks interesting. One thing I noticed is that he’s blocking DELETE requests, which would break a RESTful design.
5 Heiko // Jun 17, 2008 at 6:23
@Thorben, Mike: Blocking DELETE is ok if you use the webapp with most browsers, they come in as POST to Rails, and the method is determined by Rails from a hidden field.
@all: As I said, it is not perfect, and the author knows it I’d say. It does block DELETE, which might be wrong. It does block wget, because crackers use it sometimes (just because it’s there) but also legitimate users, so re-enable it when you use it.
In any case: If you use a firewall, you should know how it works, the tutorial of the author helps.
6 Nome do Jogo » Artigo » Rails Podcast Brasil - Episódio 21 // Jun 19, 2008 at 5:14
[…] Automatic security […]
Leave a Comment