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

Cookie stealing via XSS #8

Open
Skyr opened this issue Jun 26, 2015 · 6 comments
Open

Cookie stealing via XSS #8

Skyr opened this issue Jun 26, 2015 · 6 comments

Comments

@Skyr
Copy link

Skyr commented Jun 26, 2015

As far as I can see, your approach relies solely on the session ID stored in the cookie. Since your single-page app has to access this cookie, in contrast to the classic session cookie it cannot be made http-only. Your approach closes the (often underestimated) XSRF problem, but makes your app potentially vulnerable to cookie stealing via XSS.
This should be adressed either by setting restrictive Content-Security-Policy headers, or by using a mixed approach: An API call is considered valid if it has both a valid session cookie and the additional header. The latter offers imho best of both worlds :-)

@jamesward
Copy link
Owner

Thanks for the feedback. We discussed this a bit in the comments on my blog post but I never updated the article with more details. :( The cookie is only used so that the user doesn't have to re-login if they reload the page. I'm not sure how a Content-Security-Policy or an additional header would be used to prevent an XSS attack from grabbing the auth token. Can you explain more?

@Skyr
Copy link
Author

Skyr commented Jun 29, 2015

I have to admit - on a second thought, the Content-Security-Policy header wouldn't mitigate XSS completely. My idea was to restrict the source of Javascript to trusted sources (e.g. the primary site, plus any foreign APIs). An attacker would be unable to include a JS file from his own server. If the attacker manages to store the attack script on the application's server and the application includes this data (typical example: guest book) in an unsafe way, he still would be able to extract the cookie value used for API access.

@jamesward
Copy link
Owner

Yeah, that wouldn't protect against a script that gets injected into a page. But if an attacker can inject a script into a page, there doesn't seem to be much that they couldn't do.

@atifmansoor
Copy link

An additional layer of protection would be to use both types of cookies (httponly and Js-readable) and compare them server-side. This way, if someone is able to steal the the csrf-token in the JS-readable cookie, they will need the http-only cookie as well to try to impersonate them. This is the double-cookie defense.

@jamesward
Copy link
Owner

Thanks @atifmansoor!

@dnjora
Copy link

dnjora commented Apr 14, 2019

Great stuff!

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

4 participants