4 ms·

I don't understand how this is so widespread - If you're using a major web framework, and most of these sites probably are right? isn't CSRF protection built in

by hogu 15y ago

I don't understand how this is so widespread - If you're using a major web framework, and most of these sites probably are right? isn't CSRF protection built in? are people just turning it off?

tptacek 15y ago
Even in the major frameworks, on-by-default CSRF protection is relatively new. On some popular J2EE platforms, forms still aren't protected by default. We'll get there. This is a much more straightforward problem to solve than XSS, which is the real bitch.
- someone13 15y ago
  I don't know if I'd call XSS "the real bitch". I remember reading a blog post a while ago (that I sadly can't seem to find now) which recommended using a good variable naming system - something like us_blah for unsafe content, and s_blah for safe content - and only writing / storing safe content. Furthermore, the only thing that returns safe content is the appropriate escaping function, so you can look at each line and notice that "s_blah = us_blah2" is wrong. I always wondered if it'd be possible to use the type system of a language to do something similar - make a "safe to output" type, and a "not safe to output" type, which are not mutually convertible, and then write a function that converts between UnsafeStr and SafeStr. Then, you can write all your code to only work on and only print a SafeStr.
  - eurleif 15y ago
    Jinja, a Python template engine, does something like that. When you include a string in a template, it's automatically escaped, but you can disable that by wrapping the string in a Markup object. You can also use the Markup class directly: >>> foo = u'I <3 you.' >>> bar = Markup(u'<h1>') + foo + Markup(u'</h1>') >>> print bar <h1>I <3 you.</h1>
  - nbpoole 15y ago
    It's not nearly as simple as you make it seem: 1. What is "safe content"? That entirely depends on the context in which you're using a particular string. (See https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%... for a summary of the kinds of things you have to think about) 2. The system you're describing is somewhat similar to http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/ http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/. People still find plenty of XSS vulnerabilities in Rails applications. 3. http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/
jurre 15y ago
I was thinking the same thing, Rails (which is used by github and heroku afaik) has this by default. I guess they are still on old versions?
homakov 15y ago
well, you mentioned very interesting thing. Yes, frameworks are protected. But in fact - the more you make easy to develop - the more it's easy to leave hole. Well, I'm about Rails now. Surely they have built-in CSRF protection but they also have ugly practise with routing - that's theme of upcoming post.

by hogu 15y ago

I don't understand how this is so widespread - If you're using a major web framework, and most of these sites probably are right? isn't CSRF protection built in? are people just turning it off?

tptacek 15y ago

Even in the major frameworks, on-by-default CSRF protection is relatively new. On some popular J2EE platforms, forms still aren't protected by default. We'll get there. This is a much more straightforward problem to solve than XSS, which is the real bitch.

someone13 15y ago
I don't know if I'd call XSS "the real bitch". I remember reading a blog post a while ago (that I sadly can't seem to find now) which recommended using a good variable naming system - something like us_blah for unsafe content, and s_blah for safe content - and only writing / storing safe content. Furthermore, the only thing that returns safe content is the appropriate escaping function, so you can look at each line and notice that "s_blah = us_blah2" is wrong. I always wondered if it'd be possible to use the type system of a language to do something similar - make a "safe to output" type, and a "not safe to output" type, which are not mutually convertible, and then write a function that converts between UnsafeStr and SafeStr. Then, you can write all your code to only work on and only print a SafeStr.
- eurleif 15y ago
  Jinja, a Python template engine, does something like that. When you include a string in a template, it's automatically escaped, but you can disable that by wrapping the string in a Markup object. You can also use the Markup class directly: >>> foo = u'I <3 you.' >>> bar = Markup(u'<h1>') + foo + Markup(u'</h1>') >>> print bar <h1>I <3 you.</h1>
- nbpoole 15y ago
  It's not nearly as simple as you make it seem: 1. What is "safe content"? That entirely depends on the context in which you're using a particular string. (See https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%... for a summary of the kinds of things you have to think about) 2. The system you're describing is somewhat similar to http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/ http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/. People still find plenty of XSS vulnerabilities in Rails applications. 3. http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/

jurre 15y ago

I was thinking the same thing, Rails (which is used by github and heroku afaik) has this by default. I guess they are still on old versions?

homakov 15y ago

well, you mentioned very interesting thing. Yes, frameworks are protected. But in fact - the more you make easy to develop - the more it's easy to leave hole. Well, I'm about Rails now. Surely they have built-in CSRF protection but they also have ugly practise with routing - that's theme of upcoming post.