I have confirmed the presence of reflected XSS vulnerability in my website and I see the csrftoken present in one of the cookies when injecting a document.cookie in javascript. We don't have the user-session cookies. Is that csrftoken sufficient enough for performing further attacks?
2 Answers
If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete their account (if that doesn't require re-authenticating). Change their email address (if it doesn't require re-authenticating). Upload your own content or access key. Fake-redirect them to the login page, present a clone of the login screen, and try to steal their credentials. Send the exploit payload to other users. Mine BitCoin with their browsers' JS engine (OK, that one is pretty pointless).
Stealing cookies is kiddie-mode XSS. It's easy to do, but also easy to defend against, rarely needed, and sometimes pointless. To technically answer your question, obviously if you have the CSRF token (which is going to be either in a script readable cookie or just in the page's DOM, which you can also read) then you can launch CSRF attacks on the user... but you don't need to because you can make the user's browser do anything that CSRF could do, and much, much more, from script running on the same site.
answered Jul 25, 2019 at 8:00
If you can execute an XSS on the application, you should be able to get the user session cookies if the user is logged in and has clicked the link with the payload. Use a GET request inside your XSS payload to your server to capture those cookies.
CSRF token is definetly not enough to conduct any further meaningful attacks.
Update: If the HttpOnly flag is set, you won't be able to extract that cookie out with Javascript
-
From the description of the original post it sounds like the session cookie has the HTTPOnly attribute set (and is therefore not included in the output of the JavaScript call to document.cookie). I do not think that the scenario you describe is applicable in the described context. Could you elaborate on that if you think I am missing something?– DenisCommented Jul 22, 2019 at 14:12
-
@Denis I agree, I was about to add this. If you can execute an XSS, then you can almost certainly get any cookies that are not being safely guarded. But it’s trivial to safely guard cookies from XSS. Commented Jul 22, 2019 at 19:37
-
This answer is badly misleading. The first part is usually false because the session cookie darn well ought to be
HttpOnly, and misleadingly implies that stealing the session cookie is the only useful thing for XSS to do. The second part is technically true even though stealing the CSRF token allows you to do CSRF attacks, because XSS strictly dominates CSRF in terms of what you can do with it, but makes it sound like having user's CSRF token is useless. Commented Jul 25, 2019 at 8:03