Re: DoS using POST via hash algorithm collision
> invasive to app code. It seems that this crafted-hash-collision > vector doesn't have a clean answer like that. There are workarounds, > but they may not apply to particular codebases. Yeah. The discussion going on over at python-dev suggests that Python itself may actually implement support after all, which would be really nice. -- 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: DoS using POST via hash algorithm collision
On Thu, Dec 29, 2011 at 12:10 PM, Paul McMillan wrote: ... >> That seems like a simpler workaround than arch upgrade or replacing >> dict implementation. > > This problem has nothing to do with slowloris. > > Replacing dict implementation prevents an attacker from producing keys > which are intentionally n^2 hard for dictionary operations. Sure, I understand these are 2 different attack vectors. I just meant that putting a proxy in front is a general solution that isn't invasive to app code. It seems that this crafted-hash-collision vector doesn't have a clean answer like that. There are workarounds, but they may not apply to particular codebases. -- 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: DoS using POST via hash algorithm collision
> Slow Loris can be avoided by putting a proxy capable of buffering > requests until completion between the app server and the web, right? Yes, use nginx or similar. Slowloris is generally not a problem when that is properly configured. > That seems like a simpler workaround than arch upgrade or replacing > dict implementation. This problem has nothing to do with slowloris. Replacing dict implementation prevents an attacker from producing keys which are intentionally n^2 hard for dictionary operations. -- 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: DoS using POST via hash algorithm collision
On Thu, Dec 29, 2011 at 8:19 AM, Christophe Pettus wrote: ... > It's an interesting result, but I'm not sure how much to be worried about it > in the field. A SlowLoris or similar attack would seem to be far more > effective and less implementation-dependent. Slow Loris can be avoided by putting a proxy capable of buffering requests until completion between the app server and the web, right? That seems like a simpler workaround than arch upgrade or replacing dict implementation. -- 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: DoS using POST via hash algorithm collision
Thanks On Thu, Dec 29, 2011 at 11:36 AM, Alex Gaynor wrote: > > > On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski < > daniel.sokolow...@klinsight.com> wrote: > >> Would someone be so kind and explain why POST variables are stored in >> hash tables? What is the reasoning behind it? Speed? Or is this simply done >> at the Python level when using a dictionary type? Thank you >> >> >> On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus wrote: >> >>> >>> On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote: >>> >>> > So this would effect django because of the CSRF token check --- which >>> requires the hash to be regenerated before comparing it yes? >>> >>> No, the problem is somewhat different. The attacker constructs a POST >>> request in which the field names are constructed to be a degenerate case of >>> a hash table. Since pretty much every web framework in existence >>> (including Django) automatically takes the incoming POST fields and inserts >>> them into a hash table (a Python dict being implemented as a hash table), >>> the framework will grind through this degenerate case very, very slowly. >>> >>> If I'm reading the paper correctly, it only applies to 32-bit Python >>> implementations, as the 64-bit ones are not practically vulnerable to this >>> attack. >>> >>> It's an interesting result, but I'm not sure how much to be worried >>> about it in the field. A SlowLoris or similar attack would seem to be far >>> more effective and less implementation-dependent. >>> -- >>> -- Christophe Pettus >>> x...@thebuild.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. >>> >>> >> >> >> -- >> Daniel Sokolowski >> Web Engineer >> KL Insight >> http://klinsight.com/ >> Tel: 613-344-2116 | Fax: 613.634.7029 >> 993 Princess Street, Suite 212 >> Kingston, ON K7L 1H3, Canada >> >> >> Notice of Confidentiality: >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain confidential and/or privileged >> material. Any review re-transmission dissemination or other use of or >> taking of any action in reliance upon this information by persons or >> entities other than the intended recipient is prohibited. If you received >> this in error please contact the sender immediately by return electronic >> transmission and then immediately delete this transmission including all >> attachments without copying distributing or disclosing same. >> -- >> 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. >> > > Well, what structure would you use to store them? POST variables are > "obviously" a mapping of key to value, and the way one does that in Python > is generally a dict (which are presently backed by a hashtable on every > Python VM I know of). > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > 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. > -- 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: DoS using POST via hash algorithm collision
On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski < daniel.sokolow...@klinsight.com> wrote: > Would someone be so kind and explain why POST variables are stored in hash > tables? What is the reasoning behind it? Speed? Or is this simply done at > the Python level when using a dictionary type? Thank you > > > On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus wrote: > >> >> On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote: >> >> > So this would effect django because of the CSRF token check --- which >> requires the hash to be regenerated before comparing it yes? >> >> No, the problem is somewhat different. The attacker constructs a POST >> request in which the field names are constructed to be a degenerate case of >> a hash table. Since pretty much every web framework in existence >> (including Django) automatically takes the incoming POST fields and inserts >> them into a hash table (a Python dict being implemented as a hash table), >> the framework will grind through this degenerate case very, very slowly. >> >> If I'm reading the paper correctly, it only applies to 32-bit Python >> implementations, as the 64-bit ones are not practically vulnerable to this >> attack. >> >> It's an interesting result, but I'm not sure how much to be worried about >> it in the field. A SlowLoris or similar attack would seem to be far more >> effective and less implementation-dependent. >> -- >> -- Christophe Pettus >> x...@thebuild.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. >> >> > > > -- > Daniel Sokolowski > Web Engineer > KL Insight > http://klinsight.com/ > Tel: 613-344-2116 | Fax: 613.634.7029 > 993 Princess Street, Suite 212 > Kingston, ON K7L 1H3, Canada > > > Notice of Confidentiality: > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review re-transmission dissemination or other use of or > taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error please contact the sender immediately by return electronic > transmission and then immediately delete this transmission including all > attachments without copying distributing or disclosing same. > > -- > 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. > Well, what structure would you use to store them? POST variables are "obviously" a mapping of key to value, and the way one does that in Python is generally a dict (which are presently backed by a hashtable on every Python VM I know of). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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: DoS using POST via hash algorithm collision
Would someone be so kind and explain why POST variables are stored in hash tables? What is the reasoning behind it? Speed? Or is this simply done at the Python level when using a dictionary type? Thank you On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus wrote: > > On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote: > > > So this would effect django because of the CSRF token check --- which > requires the hash to be regenerated before comparing it yes? > > No, the problem is somewhat different. The attacker constructs a POST > request in which the field names are constructed to be a degenerate case of > a hash table. Since pretty much every web framework in existence > (including Django) automatically takes the incoming POST fields and inserts > them into a hash table (a Python dict being implemented as a hash table), > the framework will grind through this degenerate case very, very slowly. > > If I'm reading the paper correctly, it only applies to 32-bit Python > implementations, as the 64-bit ones are not practically vulnerable to this > attack. > > It's an interesting result, but I'm not sure how much to be worried about > it in the field. A SlowLoris or similar attack would seem to be far more > effective and less implementation-dependent. > -- > -- Christophe Pettus > x...@thebuild.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. > > -- Daniel Sokolowski Web Engineer KL Insight http://klinsight.com/ Tel: 613-344-2116 | Fax: 613.634.7029 993 Princess Street, Suite 212 Kingston, ON K7L 1H3, Canada Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review re-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying distributing or disclosing same. -- 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: DoS using POST via hash algorithm collision
On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote: > So this would effect django because of the CSRF token check --- which > requires the hash to be regenerated before comparing it yes? No, the problem is somewhat different. The attacker constructs a POST request in which the field names are constructed to be a degenerate case of a hash table. Since pretty much every web framework in existence (including Django) automatically takes the incoming POST fields and inserts them into a hash table (a Python dict being implemented as a hash table), the framework will grind through this degenerate case very, very slowly. If I'm reading the paper correctly, it only applies to 32-bit Python implementations, as the 64-bit ones are not practically vulnerable to this attack. It's an interesting result, but I'm not sure how much to be worried about it in the field. A SlowLoris or similar attack would seem to be far more effective and less implementation-dependent. -- -- Christophe Pettus x...@thebuild.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: DoS using POST via hash algorithm collision
So this would effect django because of the CSRF token check --- which requires the hash to be regenerated before comparing it yes? On Wed, Dec 28, 2011 at 9:26 PM, Luciano Pacheco wrote: > Hi all, > > Have you guys seen this? > http://www.ocert.org/advisories/ocert-2011-003.html > > PDF with some more explanation: > http://www.nruns.com/_downloads/advisory28122011.pdf > > Regards, > -- > Luciano Pacheco > blog.lucmult.com.br > -- > 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. > -- Daniel Sokolowski Web Engineer KL Insight http://klinsight.com/ Tel: 613-344-2116 | Fax: 613.634.7029 993 Princess Street, Suite 212 Kingston, ON K7L 1H3, Canada Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review re-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying distributing or disclosing same. -- 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: #16630: Support for HTML5 input types
+1 for Paul's concerns. I think this at least should be opt-in. It can be also more or less implemented without custom widgets but using Gregor Müllegger's form-rendering branch (which is not merged but available as https://github.com/SmileyChris/django-forms app if I understand it properly) - or with some other external app like http://pypi.python.org/pypi/django-widget-tweaks/ среда, 28 декабря 2011 г. 10:15:49 UTC+6 пользователь poswald написал: > > I have a concern regarding this.. A few times I have tried to > integrate django-floppyforms which takes a similar approach to what > the html5 widgets offer (input types are specified by default) and it > often causes pain. The reason is that while browsers say they support > html5 input types sometimes that support is lacking or very badly > implemented. As an example, if you say value="2011-12-28"> the only officially supported date format is an > RFC-3339 'full-date' format (-MM-DD) according to the spec: > > http://dev.w3.org/html5/markup/input.date.html#input.date.attrs.value > http://tools.ietf.org/html/rfc3339 > > This means that you cannot have any other format of date string in > that form field. > > Now, this ticket 16630 doesn't change the date field specifically but > it does change the number field. (Is there a similar ticket for > changing the date field?) I've run into a similar problem with the > type='number' that this ticket does change. The problem I ran into was > that forms cannot easily use the THOUSANDS_SEPARATOR because it is not > a valid number. It has to be a 'float' to be valid. This means > technically you need to use the text widget for that. > > http://dev.w3.org/html5/markup/datatypes.html#common.data.float > > So by my thinking this patch (and by extension the thinking of > browsers and the w3) is non-backwards compatible with the way that > django formats numbers when USE_THOUSANDS_SEPARATOR is True or when > localization is turned on. > > https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator > > Maybe there is something I'm missing here? I just want to flag this as > a concern and make sure that developers know what they are getting > into by enabling that. I would be for this being the default if it > could be disabled. That way, I can use modernizr.js and turn only > certain marked fields into type="number" or type="date". At the > minimum, we would need to document that the default behavior is > changing. > > -Paul > > > > On Dec 28, 1:35 am, Aymeric Augustin > wrote: > > On 27 déc. 2011, at 17:15, Jonas H. wrote: > > > > > This patch has been around for while now. I just updated the patch so > it applies cleanly against rev 17281. > > > > > So, can we get this patch into trunk or is something missing? > > > > Hi Jonas, > > > > The patch looks pretty good, but it needs documentation: > > - in the widgets reference; > > - in the release notes, under backwards-incompatible changes. > > > > Best regards, > > > > -- > > Aymeric Augustin. -- 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/-/AUiKFrO2-0cJ. 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.
What you can do to improve the upcoming 1.4 release
Hi folks, We released an alpha of Django 1.4 on December 22nd. We plan to release a beta on Feb 2nd and the final version an March 1st. By then, we'd like to fix as many bugs as possible, starting with those that matter most to you. You may be familiar with our contributing processes, but in case you aren't, on behalf of the core team, here's a summary of what you can do to help us. 1) Test the new features in 1.4 alpha and report bugs There isn't much to explain here :) Release notes: https://docs.djangoproject.com/en/dev/releases/1.4-alpha-1/ How to report bugs: https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/ 2) Run the test suite on your favorite platform (OS, Python, database) Django 1.4 supports all mainstream OSes, CPython 2.5 to 2.7, and 4 database engines (including their geospatial versions). If you see a failure that isn't reported in our bug tracker yet, please open a ticket! How to run the test suite: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/ 3) Review existing patches Once a contributor has uploaded a patch for a ticket, we ask that someone else reviews it, in order to guarantee its quality. If the patch matches all the criteria for inclusion in Django, the reviewer can move the ticket from "Accepted" to "Ready For Checkin" — and then a core developer will take ownership of the ticket and commit the patch. If it doesn't, the reviewer should explain how to improve the patch. In short, the quality criteria are: - all comments made on the ticket are taken into account (or rebutted), - code makes sense (comments count there) - code is clean (PEP 8, see the coding style guide in the documentation for more information), - relevant tests are included, - relevant docs are included, - there is one patch, relative to the `trunk` directory, that contains all the changes and applies cleanly on the latest SVN revision. We're currently stuck with around 200 patches waiting for review: https://code.djangoproject.com/query?status=!closed&needs_better_patch=0&needs_tests=0&needs_docs=0&has_patch=1&stage=Accepted&desc=1&order=changetime Add some search criteria, such as "Easy pickings = yes", or "Component = Documentation", to locate easy patches. 4) Triage unreviewed tickets Anyone can triage unreviewed tickets. That gives the core team more time to spend on other tasks, such as committing patches or making design decisions. Also, with the 5-for-1 deal, if you triage 5 unreviewed tickets, you may ask a core developer to review one ticket of your choice — just send to this list the ticket numbers and your question. You can track tickets counts here: http://dddash.ep.io/ The core team handles tickets whose triage stage is "Design Decision Needed" and "Ready For Checkin"; everything else is in your hands! If you're interested in contributing to Django, you'll find a wealth of information here: https://docs.djangoproject.com/en/dev/internals/contributing/ Finally, there are always a few core devs hanging out in #django-dev on FreeNode. If you have questions, just ask and we'll do our best to help you. Thanks in advance! -- Aymeric Augustin. -- 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.
