On second thought, if SQLFORM(..., detect_record_change=True), the _formkey
token is a hash of the record fields rather than a random UUID, so it would
remain the same from request to request, thus enabling the exploit. Perhaps
we should add a random string to the record hash in that case.
On T
> I know that there are security experts/security "fans" watching over
> web2py's code, so I'll leave this topic to them for further analysis, but
> as Anthony suggested it seems that web2py is fine. Django and Rails use a
> somewhat "static" token, while web2py generates a new one for every f
well, from what I read it seems that they somehow manage to inspect the
content-length of the compressed output given that:
- somehow are able to inject a simil-token
- the compression algo is know in advance
hence the estimation of the content-length would give them the right token,
because if t
One recommendation is to randomize the "secret" per request (the attack
works by guessing the secret one character at a time). web2py already
randomizes its CSRF tokens on every request (which I take it Django does
not do), so not sure web2py has the same vulnerability with regard to the
CSRF t
As I understand this has nothing to do with Django. They discovered a ssh
vulnerability that can used to decrypt part of traffic. It will affect all
of us if un patched.
On Tuesday, 6 August 2013 10:55:06 UTC-5, Chun-Hung Chen wrote:
>
> Hi,
>
> FYI
> https://www.djangoproject.com/weblog/2013/au
5 matches
Mail list logo
