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?

| improve this question | | | | |
  • 1
    I have highlighted the XSS part of the question, to make it less broad. If you dissaprove, you can off course rollback. – Anders Jun 25 '19 at 10:19

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 kevin.lance@attacker.com. This may compromise the account if the web application has password reset functionality through email.

| improve this answer | | | | |
  • 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. – Anders Jun 25 '19 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/HMLHttpRequest requests to the server, if needed) that the user can do as long as it doesn't require re-authenticating. – CBHacking Jun 25 '19 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.


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.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.