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

"meteor_login_token" not marked as HTTPOnly #838

Closed
infosec-au opened this issue Mar 21, 2015 · 7 comments
Closed

"meteor_login_token" not marked as HTTPOnly #838

infosec-au opened this issue Mar 21, 2015 · 7 comments

Comments

@infosec-au
Copy link

Hey there,

Currently, any cross-site scripting attack can lead to the stealing of sessions since most cookies, and more importantly the cookie holding the session token is not marked as HTTPOnly.

Whilst XSS can simply lead to the controlling of the victim's browser to perform actions on his/her behalf, making the session cookie HTTPOnly, can prevent further exploitation by the attacker.

Further reading: https://www.owasp.org/index.php/HttpOnly

@yourcelf
Copy link
Contributor

HTTPOnly won't fix the situation with a meteor app. In short: Meteor doesn't use this cookie for authentication; it uses tokens that are already script-accessible instead. If the cookie weren't available, the attacker could just use localStorage.getItem("Meteor.loginToken") to retrieve the token.

Full background: Meteor does not use cookies for authentication in general; it uses localStorage, and all data interchange happens by page-level javascript after the page has loaded. By design, local scripts have full access to their authentication token.

The fast-render package introduces a meteor_login_token cookie to speed up server-side dispatch of data; but this cookie is not set by the server, it's set by a local script that reads the value from local storage after first page load. Since it's locally set, it can't be httpOnly.

In general: given the everything-is-global and everything-is-client approach that meteor uses, a successful XSS attack means full control of the user for any meteor app; and short of a fundamental change in design model for meteor that's not going away. Unfortunately fixing this cookie changes none of that.

@infosec-au
Copy link
Author

Is there any way for TelescopeJS to prevent the potential stealing of sessions via XSS? I only ask as once the session is stolen, there is a post authentication security issue (reported to the official TelescopeJS email) which allows for the retrieval of the logged in users bcrypt hash.

This would mean that a successful XSS attack from an attacker could lead to the extraction of the password hash (which can be cracked) of the victim. Whilst it is possible to solve the issue where some private info is disclosed (i.e. BCrypt hash), I think that having the session token in a state where it could be stolen via XSS with ease, could lead to future security issues.

@yourcelf
Copy link
Contributor

I don't believe so... as long as it's a meteor-based app, the session token will be stored in script-accessible localStorage. It might be possible to prevent leaking of the bcrypt hash, but the session itself isn't really protectable within meteor.

@infosec-au
Copy link
Author

No problem. Thanks for letting me know how Meteor stores session tokens :)

Yeah, I've emailed Sacha about the BCrypt hash leakage. I think he'll be working on it soon, if not already working on it right now. I'll close this issue for now.

Thanks 😄

@SachaG
Copy link
Contributor

SachaG commented Mar 25, 2015

OK, so the bcrypt thing was my fault. I thought it was safe to simply send over the whole user object when it's your own account, but I guess not! I'll work on it.

@infosec-au
Copy link
Author

Hey @SachaG, have you been able to resolve the bcrypt info leak issue? Let me know so that I can formally request a CVE for it.
Thanks :)

@SachaG
Copy link
Contributor

SachaG commented Apr 22, 2015

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

3 participants