-
Notifications
You must be signed in to change notification settings - Fork 93
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
Comments
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? |
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. |
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. |
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. |
Thanks @atifmansoor! |
Great stuff! |
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 :-)
The text was updated successfully, but these errors were encountered: