Good tip and easy to implement. I always feel more comfortable knowing that the data is secure and safe before it gets near the database.

Does RoR have the equivilent of PHP's strip_tags() in which you can define certain HTML tags that are allowed, or would you just need to write out a regexp for it?

Let's say you where going to implement a simple forum.  You most certainly would allow somone to post an off-site image, right?  I mean, you'd not filter out <img ...> from a forum.  What kind of a forum would not allow images?

I'm running a very old phpBB based website, and am up to my gills in XSS, and possibly CSRF vulnerabilities.  A good article to read is: Foiling Cross-Site Attacks.

If you look at that article, and then go to the Excellent set of XSS test cases, and you'll find you've got a pretty big mess on your hands.
Example:

The point is that an IMG tag can point to an off-site image.  How do you know that the offsite resource really is an image and not a piece of code that injects javascript or simply a redirect back to your site, which in turn tries to activate some administrative function?

Let's say you have an admin called "jeff", and a hacker called "hacker".

Step 1:
Hacker posts a message with an img tag that goes to his own server.  He sets up his server to not serve an image, but instead redirect the browser back to your sites administrative function to delete a user.  You'd not know this by looking at the IMG tag.

Step 2:
Jeff logs into the site.  He authentiactes as usual, and evertyhing is fine.  Jeff browses the forums, and comes across the post written by hacker.  Jeffs' browser goes off to fetch that "image" that hacker posted -- but instead of getting an image, your browser is redirected to the admin function.  You'd not know it, because the IMG tag looks like it's going to a normal image.  It's hacker's server that did a bait-and-switch on you (with the specified redirect).

Step 3: 
The redirect that hacker wrote goes and executes, and because jeff is authenticated as an admin, the browser and session is authenticated as an admin.  Although jeff didn't mean to, the redirect just gone and performed some administrative function for him to delete some user (maybe even himself?).

Yes there are ways of writing your application to protect from a redirect attack, but if you sit down and read though the hacker page (http://ha.ckers.org/xss.html), and spend some time really understanding the implications -- I think it will make your skin crawl.

My point is that your website is vulnerable to this kind of attack if you trust all third-party IMG tags, and allow people to embed the graphics into your website -- and you are not super careful in how you deal with admin functionality.  Again, we're talking about a vulnerability that exploits the proper function of your website after a trusted user & admin (Jeff) has been authenticated.

It is dangerous to whitelist tags in general and think you're safe. 

Most of the time no one is going to go through the trouble of hacking your site like that.  The issue is that when you have a website for an online game (like I do), and you have people that declare "war" on you because they violated your community rules, and you had to ban them -- well, some people just seem to have infinite time to think about how to attack your site and "get back" at you.

I'm highly annoyed about all of this.  It's not like I'm some ivry-tower what-if guy that likes to theorize about highly unlikeley attacks and then spend uncountable number of hours securing something that didn't need to be secured in the first place.

That is a good point, and the controller should make sure that a delete or modify action are written to ensure the proper request type.  Good thing rails has verify :method => :post, :only => [...]

The biggest point I'm trying to make is that whitlisting tags cannot be the whole story to your security.  As you point out, controllers must also make sure certain create/update/deletes require a post or put.  But when you think about it, the reason why create/update/delete should not be executed on a get isn't so much about security, but about "clean" and "good" implementation style that embraces original thinking of the W3C spec.  It's more about what can "safely be cached" etc.

So it's a technicality that can also make your application more secure.  Clearly whitelisting wasn't the whole story to making your application more secure if you rely on this line of protection.

I would not be surprised that there are other attacks to consider.  I just raised this one example because it's somewhat unexpected.  I certainly never thought about what could be done with a simple IMG tag.  If you look at the hackers site, it seems a good amount of attacks are used by putting unexpected things into the IMG tag.  My point is, if you allow an IMG tag, and you care about security, can you be sure that none of these methods are going to bite you?