Tag Archives: django security

You Can’t Log Out of Pinterest or Instagram – Django Web Framework Security Weakness

Posted on by

The Django Web application framework made to help you build websites fast offers a session storage mechanism that does not allow a visitor to fully terminate their session when they log out. Though not the default storage mechanism — as is the case with Ruby on Rails — it is an option. I found that at least Pinterest and Instagram use this vulnerable option to handle sessions on their websites and I demonstrate what the issue looks like to a normal Web user in my video:

Pinterest.com and Instagram.com both suffer from WASC-47, OWASP Top Ten A2, and CWE-613. The situation is especially bad given the lack of SSL protecting the transport of the permanent session cookie/token between their servers and your browser.

To identify additional high-profile Django-based websites that might use the vulnerable cookie-based session storage mechanism, here is a starting point: http://stackoverflow.com/questions/1906795/what-are-some-famous-websites-built-in-django

 Happy hacking! Contact me with questions.

Share

List of websites using Ruby on Rails’ CookieStore for session management

Posted on by

When bringing attention to the session termination security issue present with Ruby on Rails’ CookieStore and Django’s cookie-based session storage mechanism, one of the common questions I get is “Who is using it?”

Well, I did some digging and have the following list of 1,897 websites for your review. These are Rails sites only (before version 4.0, and not including Rails sites that encrypt their cookie values). This is not an exhaustive list, and there is future work to be done in detecting remotely the use of Rails’ CookieStore with encrypted values as well as the presence of Django’s cookie-based storage mechanism.

This Insufficient Session Expiration weakness (WASC-47) is pretty common I found, and it is especially bad when the site does not use SSL. Many of the websites and tools we use store the session hash on the client side, including the applications Redmine, Zendesk, and Spiceworks.

If you don’t have access to the app’s source code, you may be able to figure out if the site you are visiting is using Rails’ CookieStore (before version 4.0 due to its encrypted cookie values) by checking for the string “BAh7″ at the beginning of the value of any of the cookies. A SHODAN search will reveal tens of thousands of these apps: www.shodanhq.com/search?q=BAh7*

Contact me if you are on the development team of any of the following websites and need help switching.

Continue reading →

Share

Security Vulnerability with Django Cookie-Based Sessions

Posted on by

UPDATE: Django updated their documentation to include a warning about this risk: “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 can use that cookie to login as that user even if the user logs out.”

OSVDB catalogued the vulnerability and Threatpost covered it in an article.

 

Django has a session invalidation security vulnerability like the Ruby on Rails vulnerability I wrote about here.

Django is a free and open source Web application framework that is written in Python. Django version 1.4 introduced cookie-based session storage and Django version 1.7 is currently under development.

Background

Django provides options for how and where user session data is stored. One of those options is cookie-based storage, which stores all session data in the cookie and signs it.

Without access to the app’s code, detecting which session storage mechanism is in use is slightly harder than with the similar Rails vulnerability. With Django, 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. So, you’ll need to examine the value of the cookie to determine which session storage mechanism may be in use for a given application.

The Impact

When using Django cookie-based session storage in your Web app, if someone were to find, steal, or intercept a user’s cookie they could log into your website as that user even if that user had logged out.

The main difference from the Rails session security vulnerability is that Django does not use cookie-based sessions by default.

I found most developers are completely shocked to learn about this kind of behavior. I believe this is a risk that was written off without adequate documentation or warning.

Happy hacking! Email me with questions: Main@GSMcNamara.com

Share