4 ms·

Django Security Releases Issued

61 points by zain 16y ago

ubernostrum 16y ago
Since this also affected Rails, a minor clarification: We spoke with Ben Bangert of Pylons/Pyramid, and did some checking of source code there and in other projects, and as far as we knew last week, Django was the only Python framework affected by the CSRF issue. If you find another project which is affected, please notify them ASAP.
nbpoole 16y ago
Cross-posting the recent discussion about the new Ruby on Rails release, which included a fix for the same CSRF issue: http://news.ycombinator.com/item?id=2195283 http://news.ycombinator.com/item?id=2195283
aston 16y ago
These guys are not the only ones to make this mistake. Check the first line of Tornado's XSRF check: def check_xsrf_cookie(self): """Verifies that the '_xsrf' cookie matches the '_xsrf' argument. To prevent cross-site request forgery, we set an '_xsrf' cookie and include the same '_xsrf' value as an argument with all POST requests. If the two do not match, we reject the form submission as a potential forgery. See http://en.wikipedia.org/wiki/Cross-site_request_forgery """ if self.request.headers.get("X-Requested-With") == "XMLHttpRequest": return token = self.get_argument("_xsrf", None) if not token: raise HTTPError(403, "'_xsrf' argument missing from POST") if self.xsrf_token != token: raise HTTPError(403, "XSRF cookie does not match POST argument")
- nbpoole 16y ago
  I wouldn't call it a mistake. If you had asked me before this afternoon whether trusting X-Requested-With would protect against CSRF, I would have said yes. I still have no idea how you can send arbitrary cross-domain requests in Java and Flash: the fact that you can do so is a security vulnerability in and of itself. That being said, I'm going to let them know to fix that code. ;)
- marcinw 16y ago
  Tipfy looks to be as well: http://code.google.com/p/tipfy/source/browse/tipfyext/wtforms/form.py#60 http://code.google.com/p/tipfy/source/browse/tipfyext/wtform...
  - moraesmoraes 16y ago
    A new release fixed this issue. Thank you!
- bdarnell 16y ago
  This has been fixed in the just-released Tornado 1.1.1.
svlla 16y ago
"This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case." Good choice. I wonder when weak password hashing in Django will be given the same exception.
- nbpoole 16y ago
  Good password hashing is important. However, every single Django application being vulnerable to CSRF is a much bigger deal. ;-)
- ylem 16y ago
  I've been looking at this recently. I'm still not sure about using bcrypt (SHA512 for example is part of the python standard library), but we should at least be using SHA2 instead of SHA1. One possibility is to use google's KeyGen to encrypt the password, but bottom line, I think that the password hashing should be the responsibility of the backend (with the default doing the "right" thing). I've also been looking at trying to make an username===email backend for django (instead of a user generated--part of the battle of avoiding too many user names that people just forget) and it's hard because a lot of things in the auth module are fairly fixed--regardless of the backend that you choose (for example, the regex on the username, or the length of fields). There have been some other attempts (like emailauth) to address this, but it's actually a large undertaking if you want the same functionality as the auth module. How responsive are the django developers? They seemed fairly certain that they weren't going to change the defaults for the username/email address to preserve backwards compatibility. Is it better to make a whole new authorization module (complete with middleware) or to patch theirs?
  - bryanh 16y ago
    Why couldn't they use SHA2 and make it go around X times? The bcrypt plugin [1] maintains backwards compatibility with old passwords just fine. Also, if you are cool with rolling your own registration forms/etc. you can easily just set the email as the username and email. You lose the more obscure but technically valid characters for email (a-z A-Z 0-9 @.+-_ are all fine), but 99% of emails work fine in the Django username field. Or maybe I just haven't hit some obvious problem with that implementation yet... [1] https://github.com/dwaiter/django-bcrypt/ https://github.com/dwaiter/django-bcrypt/
bryanh 16y ago
A bothersome change, especially for all those employing jQuery plugins that don't have a quick method to add the CSRF token to AJAX requests. I think I might just add @csrf_exempt, as long as we aren't changing vital info via the request...
- nbpoole 16y ago
  Out of curiosity, why doesn't hooking beforeSend (as suggested in the blog post) work?
  - bryanh 16y ago
    I haven't had a chance to try it, but if it gracefully handles every jQuery plug-ins' use of the .ajax() method, I don't see why it wouldn't work.
    - Pewpewarrows 16y ago
      This is correct. So long as the plugins themselves are using jQuery's own $.ajax() method (or one of its derivatives that in turn call it), then anything in ajaxSetup will be reflected in those requests.

61 points by zain 16y ago

Since this also affected Rails, a minor clarification: We spoke with Ben Bangert of Pylons/Pyramid, and did some checking of source code there and in other projects, and as far as we knew last week, Django was the only Python framework affected by the CSRF issue. If you find another project which is affected, please notify them ASAP.

nbpoole 16y ago

Cross-posting the recent discussion about the new Ruby on Rails release, which included a fix for the same CSRF issue: http://news.ycombinator.com/item?id=2195283 http://news.ycombinator.com/item?id=2195283

aston 16y ago

These guys are not the only ones to make this mistake. Check the first line of Tornado's XSRF check: def check_xsrf_cookie(self): """Verifies that the '_xsrf' cookie matches the '_xsrf' argument. To prevent cross-site request forgery, we set an '_xsrf' cookie and include the same '_xsrf' value as an argument with all POST requests. If the two do not match, we reject the form submission as a potential forgery. See http://en.wikipedia.org/wiki/Cross-site_request_forgery """ if self.request.headers.get("X-Requested-With") == "XMLHttpRequest": return token = self.get_argument("_xsrf", None) if not token: raise HTTPError(403, "'_xsrf' argument missing from POST") if self.xsrf_token != token: raise HTTPError(403, "XSRF cookie does not match POST argument")

nbpoole 16y ago
I wouldn't call it a mistake. If you had asked me before this afternoon whether trusting X-Requested-With would protect against CSRF, I would have said yes. I still have no idea how you can send arbitrary cross-domain requests in Java and Flash: the fact that you can do so is a security vulnerability in and of itself. That being said, I'm going to let them know to fix that code. ;)
marcinw 16y ago
Tipfy looks to be as well: http://code.google.com/p/tipfy/source/browse/tipfyext/wtforms/form.py#60 http://code.google.com/p/tipfy/source/browse/tipfyext/wtform...
- moraesmoraes 16y ago
  A new release fixed this issue. Thank you!
bdarnell 16y ago
This has been fixed in the just-released Tornado 1.1.1.

svlla 16y ago

"This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case." Good choice. I wonder when weak password hashing in Django will be given the same exception.

nbpoole 16y ago
Good password hashing is important. However, every single Django application being vulnerable to CSRF is a much bigger deal. ;-)
ylem 16y ago
I've been looking at this recently. I'm still not sure about using bcrypt (SHA512 for example is part of the python standard library), but we should at least be using SHA2 instead of SHA1. One possibility is to use google's KeyGen to encrypt the password, but bottom line, I think that the password hashing should be the responsibility of the backend (with the default doing the "right" thing). I've also been looking at trying to make an username===email backend for django (instead of a user generated--part of the battle of avoiding too many user names that people just forget) and it's hard because a lot of things in the auth module are fairly fixed--regardless of the backend that you choose (for example, the regex on the username, or the length of fields). There have been some other attempts (like emailauth) to address this, but it's actually a large undertaking if you want the same functionality as the auth module. How responsive are the django developers? They seemed fairly certain that they weren't going to change the defaults for the username/email address to preserve backwards compatibility. Is it better to make a whole new authorization module (complete with middleware) or to patch theirs?
- bryanh 16y ago
  Why couldn't they use SHA2 and make it go around X times? The bcrypt plugin [1] maintains backwards compatibility with old passwords just fine. Also, if you are cool with rolling your own registration forms/etc. you can easily just set the email as the username and email. You lose the more obscure but technically valid characters for email (a-z A-Z 0-9 @.+-_ are all fine), but 99% of emails work fine in the Django username field. Or maybe I just haven't hit some obvious problem with that implementation yet... [1] https://github.com/dwaiter/django-bcrypt/ https://github.com/dwaiter/django-bcrypt/

bryanh 16y ago

A bothersome change, especially for all those employing jQuery plugins that don't have a quick method to add the CSRF token to AJAX requests. I think I might just add @csrf_exempt, as long as we aren't changing vital info via the request...

nbpoole 16y ago
Out of curiosity, why doesn't hooking beforeSend (as suggested in the blog post) work?
- bryanh 16y ago
  I haven't had a chance to try it, but if it gracefully handles every jQuery plug-ins' use of the .ajax() method, I don't see why it wouldn't work.
  - Pewpewarrows 16y ago
    This is correct. So long as the plugins themselves are using jQuery's own $.ajax() method (or one of its derivatives that in turn call it), then anything in ajaxSetup will be reflected in those requests.