On 22/09/16 18:52, Rigel wrote:
The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra().
Firstly, extra() is on is way out... being replaced by expressions,
transforms, and so on...
That said, yes, extra() does potentially open you to SQL attacks, but
only if you use it incorrectly. If used as documented -- same goes for
raw() -- you should remain immune to SQL injection.
The only time you're likely to become vulnerable to SQLi is when you do
something as stupid as putting values into SQL commands yourself.
This vulnerability could be
mitigated if the session-ids were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.
They're just a random string, I don't see how turning them into another
random string will help? Or do you mean to set the original string in
the cookie only, and hash them for the key, and hash them _every_ _time_
you look up the session?
This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
You are right there, security is more important.
However, it's a small overhead for everyone... for a small win for
Until you can demonstrate how there's any SQLi vulnerability, I'm -1 on
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.