Re: GSoC 2012: Security Enhancements
On 15/04/12 05:23, Rohan Jain wrote: > On 22:50 +0100 / 13 Apr, Luke Plant wrote: >> The reason for the strict referer checking under HTTPS is set out here: >> >> https://code.djangoproject.com/wiki/CsrfProtection >> >> Particularly, it is to fix the 'CSRF + MITM' attack that is possible >> under HTTPS. The key elements are set out in the following scenario >> (although it is not the only variation): >> >> - a client connects to a site via HTTP: http://example.com/ >> - in the response, an active MITM attacker sets a cookie over >>HTTP for example.com >> - this cookie will be used by the client when it connects over HTTPS >>to the same domain (this is the fundamental problem, but we can't >>fix it - it's what browsers do). >> - the MITM also inserts a POST form in the HTTP response. >>The form has a CSRF token that matches the cookie that was >>set by the attacker. >>The forms targets https://example.com/ and is automatically >>submitted by javascript. >> >> Without strict referer checking, the POST request will succeed, even >> though it is forged. >> >> Signing the cookie or token value does no good at all, because the >> attacker can retrieve a valid cookie/token pair directly from >> https://example.com/. > > I am a bit confused about this. How can an attacker extract the token > out of the signed cookie without the private key? There is a > possibility that the attacker deletes and sets the cookie right out, > but since that case won't be correctly signed server can handle it > securely. They don't need to extract the token, they just need to replay an existing good token/cookie pair, which they can get directly from the server any time they want. (Also, signing does nothing to hide the token. Are you actually talking about encryption here? But even if you encrypt it, it doesn't help - the only thing that matters is that the CSRF form token 'matches' the CSRF cookie, whatever your definition of 'match', and that can be achieved by getting the pair from the server.) Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSoC 2012: Security Enhancements
Sorry to reply twice, a comment on a different part: On 15/04/12 05:23, Rohan Jain wrote: > On 22:50 +0100 / 13 Apr, Luke Plant wrote: >> .. At the moment, it seems that few browsers send the >> 'Origin' header for normal HTML requests. (Recent versions of Chrome, >> Firefox and Opera do not, I don't know about IE). > > Page, http://caniuse.com/cors mentions the browsers and their versions > which support CORS. A big share of browser does support it and another > big one (constituting old IE and Opera) does not. We cannot expect > these browsers to go away anytime soon, so we have to keep maintaining > a compatibility system. > > Since http referrer is already being used in case of secure requests, > how about something similar in normal requests? Isn't the argument > about referrer being absent only in 0.2% case or less valid here? Is > 0.2% too significant for normal requests? The page you linked to shows browsers that support CORS, which is quite different from browsers that send Origin with normal HTTP requests (i.e. non XMLHttpRequests requests) - in my own tests I can't find any browser that sends it for normal HTML requests. This means that it might be useful as an alternative way of addressing the problem with AJAX, but even there I think it is of dubious value: if we deploy a method that means that AJAX works automatically (without, for example, the jQuery fix we include in our docs) on the basis of the Origin header, everything will work fine in development, where most people don't test IE regularly, and will fail for Internet Explorer in production, which is not very nice. It is better to fail early. Regards, Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSoC 2012: Security Enhancements
There seems to be some confusion about CORS (a hairy draft spec that is not fully implemented in any browser, and not appropriate for inclusion in Django at this time) and the "Origin" header (aka Web Origin, rfc6454). http://tools.ietf.org/html/rfc6454 https://wiki.mozilla.org/Security/Origin http://www.w3.org/TR/access-control/#origin-request-header The Origin header defined in rfc6454 is compatible with the CORS origin header, but does not require full CORS support from the browser or the server to be useful. In my tests with Firefox and Chrome, both sent the origin header properly when making potentially state-changing cross-origin requests (both AJAX and standard form POST requests). My suggestion here is to include optional support for the Origin header as follows: - if present and null, fail the CSRF check - if present and not null, use in alongside the Referer header - if absent, keep current behavior As a general rule, if a browser sends an origin header, that value is more reliable (harder for malicious sites to manipulate, less often stripped by firewalls, less often disabled by users) than the referer header. This addition won't improve CSRF protection for older browsers, but it also won't break anything for them. For users with newer browsers, it should prevent CSRF even in cases when the CSRF token is stolen due to misconfiguration or user error. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal: Stop supporting MySQL < 5.0 in Django 1.5
Hi all, I've opened ticket [1]#18116 to track this cleanup change. This change would allow to close a handful of tickets about half-backed compatibility with deprecated MySQL 4.x. More specifically the commit would make Django trunk require MySQL 5.0.3 or newer. This will allow avoid a limitation on the length (<= 255) of char fields imposed by older MySQL versions. Opinions on the proposal and the respective patch are welcome. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/18116#comment:7 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
GitHub migration planning
Hey folks! I started a wiki page to help plan a migration to GitHub: https://code.djangoproject.com/wiki/GitHub%20Migration I don't know what I'm doing, but I do know that the current Trac setup (attaching patches, etc) is less accessible to non-core contributors than GitHub and I'd love to do anything I can to help make this better. -Philip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/WT9jb7Zh2d4J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
Em 18 de abril de 2012 18:44, philipn escreveu: > Hey folks! > > I started a wiki page to help plan a migration to GitHub: > > https://code.djangoproject.com/wiki/GitHub%20Migration > > I don't know what I'm doing, but I do know that the current Trac setup > (attaching patches, etc) is less accessible to non-core contributors than > GitHub and I'd love to do anything I can to help make this better. > Maybe the best way to avoid that people create issues on github is to disable it for the official repository. This is possible through the Github's Admin interface. Thanks, -- Dalton Barreto http://daltonmatos.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSoC 2012: Security Enhancements
On 18/04/12 20:05, Paul McMillan wrote: > My suggestion here is to include optional support for the Origin > header as follows: > - if present and null, fail the CSRF check > - if present and not null, use in alongside the Referer header > - if absent, keep current behavior > > As a general rule, if a browser sends an origin header, that value is > more reliable (harder for malicious sites to manipulate, less often > stripped by firewalls, less often disabled by users) than the referer > header. This addition won't improve CSRF protection for older > browsers, but it also won't break anything for them. For users with > newer browsers, it should prevent CSRF even in cases when the CSRF > token is stolen due to misconfiguration or user error. That does sound like a useful additional behaviour. One query: are you sure it is harder to manipulate? In particular, I remember from a while back that Flash allowed some headers to be manipulated, which caused problems, and they fixed it by blacklisting some headers, I think including referer. Did they also fix Origin? The vulnerability I'm thinking about is this one I think: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto wrote: > Em 18 de abril de 2012 18:44, philipn escreveu: >> Hey folks! >> >> I started a wiki page to help plan a migration to GitHub: >> >> https://code.djangoproject.com/wiki/GitHub%20Migration >> >> I don't know what I'm doing, but I do know that the current Trac setup >> (attaching patches, etc) is less accessible to non-core contributors than >> GitHub and I'd love to do anything I can to help make this better. >> > > Maybe the best way to avoid that people create issues on github is to > disable it for the > official repository. This is possible through the Github's Admin interface. > Err, I think the point was that Trac is less accessible than Github so Django *should* be using Github Issues instead. Best, Alex Ogier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
Github Issues are not flexible enough for Django. On Wednesday, April 18, 2012 at 6:53 PM, Alex Ogier wrote: > On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto (mailto:daltonma...@gmail.com)> wrote: > > Em 18 de abril de 2012 18:44, philipn > (mailto:phil...@gmail.com)> escreveu: > > > Hey folks! > > > > > > I started a wiki page to help plan a migration to GitHub: > > > > > > https://code.djangoproject.com/wiki/GitHub%20Migration > > > > > > I don't know what I'm doing, but I do know that the current Trac setup > > > (attaching patches, etc) is less accessible to non-core contributors than > > > GitHub and I'd love to do anything I can to help make this better. > > > > > > > > > Maybe the best way to avoid that people create issues on github is to > > disable it for the > > official repository. This is possible through the Github's Admin interface. > > > > > Err, I think the point was that Trac is less accessible than Github so > Django *should* be using Github Issues instead. > > Best, > Alex Ogier > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
Em 18 de abril de 2012 19:46, Dalton Barreto escreveu: > Em 18 de abril de 2012 18:44, philipn escreveu: >> Hey folks! >> >> I started a wiki page to help plan a migration to GitHub: >> >> https://code.djangoproject.com/wiki/GitHub%20Migration >> >> I don't know what I'm doing, but I do know that the current Trac setup >> (attaching patches, etc) is less accessible to non-core contributors than >> GitHub and I'd love to do anything I can to help make this better. >> > > Maybe the best way to avoid that people create issues on github is to > disable it for the > official repository. This is possible through the Github's Admin interface. > Hmm, this would probably disable pull requests too. Not a good idea, assuming that contributions will be accepted as pull requests on this new repo. -- Dalton Barreto http://daltonmatos.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
On 19 April 2012 00:55, Donald Stufft wrote: > Github Issues are not flexible enough for Django. > That's rather a vague statement. Github issues are actually more *flexible* then Trac as you can define any set of tags for an issue. What Django could possibly want to have is a way to create extra constraints on the tags, but as a matter of fact, the current Trac instance doesn't do that! (you can have an issue with "tests needed" but without "patch needs improvement"). -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
On Wed, Apr 18, 2012 at 6:55 PM, Dalton Barreto wrote: >> Maybe the best way to avoid that people create issues on github is to >> disable it for the >> official repository. This is possible through the Github's Admin interface. >> > > Hmm, this would probably disable pull requests too No, it does not, unless I am mis-understanding what you are saying. https://github.com/django/django/ has no issues (issues is unchecked in admin area), but it has pull requests. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
On Wed, Apr 18, 2012 at 11:55 PM, Dalton Barreto wrote: > Em 18 de abril de 2012 19:46, Dalton Barreto > escreveu: > > Em 18 de abril de 2012 18:44, philipn escreveu: > > Hmm, this would probably disable pull requests too. Not a good idea, > assuming that > contributions will be accepted as pull requests on this new repo. > Fortunately it doesn't. Pull requests can be run independently of issues, if issues have been disabled. Luke GB -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
Github issues do not have the ability for anyone to close, tag, or create milestones. You have to be the creator of the ticket or someone with commit access. Django's track instance allows anyone to participate in this way and is one of the major reasons to my knowledge that Django will keep it's trace instance. On Wednesday, April 18, 2012 at 7:39 PM, Łukasz Rekucki wrote: > On 19 April 2012 00:55, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote: > > Github Issues are not flexible enough for Django. > > > That's rather a vague statement. Github issues are actually more > *flexible* then Trac as you can define any set of tags for an issue. > What Django could possibly want to have is a way to create extra > constraints on the tags, but as a matter of fact, the current Trac > instance doesn't do that! (you can have an issue with "tests needed" > but without "patch needs improvement"). > > -- > Łukasz Rekucki > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
Em 18 de abril de 2012 21:13, Luke Granger-Brown escreveu: > > On Wed, Apr 18, 2012 at 11:55 PM, Dalton Barreto > wrote: >> >> Em 18 de abril de 2012 19:46, Dalton Barreto >> escreveu: >> > Em 18 de abril de 2012 18:44, philipn escreveu: >> >> Hmm, this would probably disable pull requests too. Not a good idea, >> assuming that >> contributions will be accepted as pull requests on this new repo. > > > Fortunately it doesn't. Pull requests can be run independently of issues, if > issues have been disabled. > This is awesome! Thanks Luke and Karen! -- Dalton Barreto http://daltonmatos.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
