If I have discovered an XSS vulnerability, is there another way of gaining access to an account without session hijacking? Mainly because on most of the sites I test, the HttpOnly and Secure flags are set on the session ID, so I can't access it through javascript (document.cookie). I know I could do some fake form asking for the username and password, but is there another way?
-
1I have highlighted the XSS part of the question, to make it less broad. If you dissaprove, you can off course rollback.– AndersJun 25, 2019 at 10:19
Add a comment
|
2 Answers
If you have XSS, you can perform any action on the website the user can. This can include changing the email address, adding a new user, or granting access to some resource. Whether any of these actions compromise the account depends on the web application.
For example, consider an XSS payload that changes the email adres of the current user to [email protected]. This may compromise the account if the web application has password reset functionality through email.
-
Due to the first sentence of your answer, you might not even need to take over an account. Just do what you want to do through the XSS vulnerability.– AndersJun 25, 2019 at 10:20
-
Typically, changing any user credentials (including email address or password) will and should require the user's current password, so you couldn't do it without already having the password. However, this is otherwise entirely correct; when you have XSS, you can do anything (via script-driven
fetch/HMLHttpRequestrequests to the server, if needed) that the user can do as long as it doesn't require re-authenticating. Jun 25, 2019 at 23:28
There are definitely more ways of hijacking a session of a victim. Think about
- Session Fixation
- Session Poisoning
- Cross-Site-Request-Forgery
- Cookie replay attacks
- Man in the Middle
Session Fixation
At Session Fixation you are able to fix a session cookie before a user logs into a webpage. If the website isn't that secure it is possible that the server will accept your choosen cookie and don't generate a new one. If that occurs you know the cookie of the victim and are able to hijack his session. this can be achieved by a link or other techniques like XSS.
http://www.example.com/login.asp?session=sfecx
Session Poisoning
At Session poisoning some servers are misconfigured and write user data directly into the session key. So the victim can send a link or use other methods to hijack the session.
Cross site request forgery
As stated on wikipedia:
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.
TLDR; You can basically make a bad website which has some images embedded with links to the attacked site which are executing commands link altering the password or the username. More information can be found on the web.
Cookie replay attacks
This can happen when a user steals a valid cookie from a victim and uses it as their ones. This is basically the attack you described.
Man in the middle
If the site isn't using transport security you can intercept the traffic and steal all information from them. After that you can deliver the right credentials.
