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.
Rhonabwy 