5 ms·
That Rails has an escape_once method is a big part of the reason I stopped using Rails. If you think "double escaping" is a problem to be solved by creating a h
by tmoertel 14y ago
That Rails has an escape_once method is a big part of the reason I stopped using Rails. If you think "double escaping" is a problem to be solved by creating a helper method that won't escape what's already escaped, now you have two problems.
EDIT TO ELABORATE:
Problem 1 is the original problem, that parts of your code do not agree upon what a particular string represents. This is the "strings problem," the mother of XSS and injection vulnerabilities. [1]
Problem 2 is that the escape_once method papers over these problems, making them harder to detect, and preventing you from hunting down the logic errors that cause them. (Since these errors often occur in upstream code, you need to find them before they execute to be safe, which is why compile-time methods [2] work best.)
[1] http://blog.moertel.com/posts/2007-08-15-a-bright-future-security-and-modern-type-systems.html http://blog.moertel.com/posts/2007-08-15-a-bright-future-sec...
[2] http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti...
- TylerE 14y agoWhy is it a problem?
- JulianMorrison 14y agoBecause it hides a problem of repeating work. Even re-re-rescanning it with fast C is slower than scanning it once.
- Tuna-Fish 14y agoThat's not the problem. The amount of work done scanning short strings is completely irrelevant. Using escape_once is a problem because it shows that you have no clue what strings in your codebase are escaped and what are not. If you knew, it would be completely pointless. Instead, people resort to cargo-cult like solutions "hey let's escape everything again here just to be sure, that's gotta catch them all". I've now worked a while in Yesod (Haskell), and I now feel very strongly that this is something they got right. Unescaped strings and html strings should be two completely separate types that can't be cast to each other, except by using transforming functions that clearly define intent.
- saraid216 14y agoI could actually see an argument to subclass String for this kind of clarity. I don't know if it'd solve it (and I'm likely not to try it out since I don't have an active Ruby project at all right now, let alone an active Rails project), but someone might try that?
- stouset 14y agoThat's essentially how Rails 3+ does this.
- lobster_johnson 14y agoThe article should have pointed out that Github is running Rails 2.3, and that this is where the problem exists. Rails 3.x has reworked the entire escaping situation and now avoids the re-escaping trap (strings must be flagged as "HTML safe", otherwise they are escaped on final injection into a document). It still has escape_once, but it's not used by Rails itself. You are of course right to blame 2.x for its flaws, but let's not blame entire projects for problems that have been fixed. (Not that Rails 3.x does not have other egregious inefficiencies, but that's another story.)
- tmoertel 14y agoI stopped using Rails not so much because of the existence of the escape_once method but because of what its introduction in 2006, and its continued use in mainstream Rails methods (until 2010 when Rails 3.0 was released), said about the direction of the project.
- lobster_johnson 14y agoWhat did it say about the direction of the project, in your opinion? I can see how one might conclude that the developers are idiots based on that method, but I have to say that what I get out of Rails vastly outweighs that stupidity.
- tmoertel 14y agoIt made it hard to believe that the project wouldn't be plagued by security problems. For me, that was enough.
- rhizome 14y agoBut the 3.0 change didn't say anything?
- tmoertel 14y agoOf course it did, but what it said wasn't enough to make me want to start using Rails again.