Message259824
| Author |
martin.panter |
| Recipients |
Pathangi Jatinshravan, Tim.Graham, harris, martin.panter, pitrou, r.david.murray |
| Date |
2016年02月08日.07:20:29 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1454916030.39.0.56750502566.issue25228@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Looking at this a second time, I think I have figured out what the security report was about. Before the fix (before revision 270f61ec1157), an attacker could trick the parser into accepting a separate key=value cookie "morsel", when it was supposed to be part of some other cookie value. Suppose the "c=d" text was meant to be associated with the "message" key. Before the security fix, "c=d" is separated:
>>> SimpleCookie('a=b; messages=[""]c=d;')
<SimpleCookie: a='b' c='d'>
With the fix applied, we now silently abort the parsing, and there is no spurious "c" key:
>>> SimpleCookie('a=b; messages=[""]c=d;')
<SimpleCookie: a='b'>
This also seems to be described by Sergey Bobrov in Russian at <https://habrahabr.ru/post/272187/>.
Looking at the proposed patch again, I think the fix might be okay. Some specifications for cookies allow semicolons to be quoted or escaped, and I was a bit worried that this might be a problem. But all the scenarios I can imagine would be no worse with the patch compared to without it. |
|