A security vulnerability in the web framework Django could make it easier for an attacker to steal a user’s cookie and log into their website even after they’ve logged out.
The session invalidation vulnerability was discovered by G.S. McNamara, the same researcher who dug up a similar vulnerability in the Ruby on Rails web app framework in September.
Like Rails, Django lets users decide where they want to store user session data. While not the default, one of the options is cookie-based storage which McNamara notes, stores all session data in the cookie and signs it.
“The default name for a session cookie is “sessionid” regardless of whether the cookie stores only a session identifier or the complete session data hash,” McNamara explained in a blog on his MaverickBlogging.com website Monday.
McNamara notes that compared to Rails, it’s a little trickier determining which storage session users have implemented, but if a user was using cookie-based sessions and an attacker had access to that machine, even if the user was logged out, they could find, steal or intercept that cookie, and easily gain access to that user’s website.
Django, an open source web application framework that helps users build web apps, runs on Python and was last updated just two weeks ago.
McNamara, who resides in D.C., alerted the Django developers about the vulnerability but it doesn’t sound like a fix is on the horizon.
Instead the group in charge of the framework, the Django Software Foundation, is electing to warn users about the security implications associated with cookie-based sessions.
“Unlike other session backends which keep a server-side record of each session and invalidate it when a user logs out, cookie-based sessions are not invalidated when a user logs out. Thus if an attacker steals a user’s cookie, he or she can use that cookie to login as that user even if the user logs out,” reads a new note on how to use sessions on the Django site.
When reached Wednesday, Carl Meyer, a Django contributor and a member of its core team, acknowledged the group doesn’t plan to make any further changes to the way it handles cookie session storage, adding that “mitigation would require validating the session against server-stored information on every request,” and that at that point the user might as well just use a server-side session instead of a cookie-based session.
According to Django, it’s up to the developer to evaluate the additional risk of cookie session storage “and weigh the pros and cons for their application.”
McNamara still hopes to work with Django when it comes to enhancing the security of their web framework going forward. In an email to Threatpost on Wednesday, he asserted there are still lingering issues with respect to [Django’s] cookie-based session storage.
“I believe this is a risk that was written off without adequate documentation or warning,” McNamara said.
