Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redis backend doesn't regenerate iron _session_id #12

Open
asakasa opened this issue Jul 22, 2017 · 5 comments
Open

Redis backend doesn't regenerate iron _session_id #12

asakasa opened this issue Jul 22, 2017 · 5 comments

Comments

@asakasa
Copy link

asakasa commented Jul 22, 2017

Even though a value of iron_session_id in cookie is empty, SessionStorage doesn't generate new session id.

Browser sends a cookie if value is not set. In this situation, SessionStorage generates a new session id and send a header Set-Cookie: .... But SessionStorage uses an empty session id as valid, and then store some values in associating with an empty key. It is buggy I think.

Additionally, if a value of iron_session_id isn't empty, Calling set method (ex. req.session.set(T)) in web application, store some values in associating with the value of iron_session_id. It may be correct. But there is a vulnerable to attack "session fixation" potentially, so it is fear to use this library for user authorization.
FYI, this is document about Session fixation: https://www.owasp.org/index.php/Session_fixation

A better solution I think is that SessionStorage also provides a method to use session id that be specified by Web application.

Thanks for the awesome library.

Version of iron-sessionstorage

iron-sessionstorage = {version="0.6.6", features=["redis-backend"]}

@untitaker
Copy link
Member

untitaker commented Jul 24, 2017 via email

@asakasa
Copy link
Author

asakasa commented Jul 31, 2017

Sorry for the late reply.

If there is only vulnerability to attack session fixation, it is not too dangerous. The vulnerability, however, is too dangerous when other vulnerabilities are combined with it.

The flow example of how the attacker exploits is as follows:

  1. Attacker fixes malicious session to the victim's browser using some other vulnerabilities, such as XSS or HTTP header injection, etc. For example, the attacker fixes "iron_session_id=malicious" to the victims's browser.
  2. The victim will log in to the service with the malicious session (iron_session_id=malicious).
  3. Web service using RedisBackend stores the malicious session in associating with the victim authentication.
  4. Attacker log in to the service using the victim's session.

Of course, the presence of other vulnerabilities are inherently a critical flaw.

In many web services, a session is regenerated when an user logged in. So, how about this library also providing such a method?


Otherwise, if it is empty it will not be regenerated, so I think it's better to fix it preferentially.
https://github.com/iron/iron-sessionstorage/blob/master/src/backends/redis.rs#L93-L97

Thanks.

@untitaker
Copy link
Member

untitaker commented Aug 5, 2017 via email

@asakasa
Copy link
Author

asakasa commented Aug 7, 2017

Ah, right. I didn't have that idea.

Surely it is sufficient for bug fix.
But the behavior is like to refresh a session rather than to clear a session, you know...

Even if you fix the bug using such a way, the vulnerability of Session Fixation is not gone.
I think that a best solution is to implement a method for specifiable a session id into RedisSession struct. But it is difficult to fix the vulnerability because some other implementations may be affected.

I think a countermeasure you suggested is good for temporary response.

Thanks.

@untitaker
Copy link
Member

I think it would make sense to automatically refresh the session if it is cleared, but yes, a new API for this would be good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants