teh suck for rails – software security

Wow – this is a beautifully detailed example of the security hole that existed in Rails version 1.1.4. I live more in the Django world, but I wouldn’t swear to anyone that similiar holes couldn’t be found there. Jeez, I more than just hope not! But the overview is a great detail for anyone interested in looking at their own code for how it could be abused.

I think that’s almost the key to developing. When you’re coding, you think about what it should do. It’s relatively uncommon to think about what it shouldn’t do – or how it should break. It’s a shame to some extent, but that is exactly what something like test driven development helps to resolve – getting people to think about the failure modes. The analog in security realm would be to think about how this code could be abused – and code defensively.

In the world of C, I know a fair number of folks who complain that they don’t want to use strlcpy() method because it “breaks” things that have already been written using strcpy(). Man, I think – take the hit. Suck it up, repair the off-by-one index errors and assumptions. It’s better than an open invitation to code abuse. Besides, it’s way easier to fix your code than to prove that your error could never be used against you.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s