Return to Answer

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that the setting the cookie is enough to log you in.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects the cookie but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but remains invisible via document.cookie. There are many more ways to exploit an XSS flaw than just stealing cookies.

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active at the time you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would complicate your attack.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change cookies so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that setting the cookie is enough to take over a session.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects cookies but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but it remains invisible via document.cookie. There are many more ways to exploit an XSS flaw than just stealing cookies which would work as a good proof of concept.

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that the setting the cookie is enough to log you in.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects the cookie but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but remains invisible via document.cookie. That said there are many more ways to exploit an XSS flaw than just stealing cookies.

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that the setting the cookie is enough to log you in.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects the cookie but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but remains invisible via document.cookie. There are many more ways to exploit an XSS flaw than just stealing cookies.

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that the setting the cookie is enough to log you in.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

Yes, that's precisely what the HttpOnly flag is for, it prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but remains invisible via document.cookie. That said there are many more ways to exploit an XSS flaw than just stealing cookies.

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

• The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
• The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
• You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that the setting the cookie is enough to log you in.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects the cookie but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but remains invisible via document.cookie. That said there are many more ways to exploit an XSS flaw than just stealing cookies.