How can a hacker steal my session where my form does not have CSRF tokens but my session cookies are HTTPonly? how would he get my session cookie in this case? is this possible?

for example, to be clearer, I have my session authenticated in the cookie (remembering the form does not contain CSRF token) but it "cannot" be accessed by JS, in this case how can a hacker take advantage of this?


2 Answers 2


There are several ways, but these ones are especially relevant to your question:

  1. XSS (Cross-Site Scripting) for remote control. The HttpOnly flag only prevents script from reading the cookie; it does not prevent script from sending the cookie along with requests (if it did, many modern websites simply wouldn't work, since they use legitimate script-initiated requests). XSS injected payloads can do very nearly anything that the user themselves could do, including make arbitrary requests and access most of the request and response headers and bodies. As such, XSS can invisibly "remote control" a victim's session for as long as the XSS payload remains running (often until the user closes the tab or similar). Such "remote control" can be automated to carry out a bunch of operations very quickly, and/or "phone home" for additional instructions. There exist tools to make this kind of attack easier, such as BeEF.
  2. CSRF (Cross-Site Request Forgery) for write-only control. Since you say you are using cookies for sessions, aren't using anti-CSRF tokens, and don't mention any other CSRF mitigations, your site may be vulnerable to CSRF. In a typical CSRF attack, the attacker can't see the responses from the server (which makes CSRF much less useful than XSS), but they can still take most actions that a user could. The archetypal example is stuff like "transfer money to account X" but it can also be things like "create a new admin-level user with this attacker-controlled throw-away address" or "turn off all the security features" or "post career-threateningly bad tweet" even just "delete all user data". This happens if your session token gets attached to requests even when they originate from outside your site. That used to always happen, though on modern browsers cookies now use the "lax" mode of the SameSite flag by default, which prevents many (but not all) such cases. If you still don't understand CSRF (which has nothing at all to do with HttpOnly), there are many resources both on and off this site to explain how it works and what it does (and the many ways to prevent it; anti-CSRF tokens in cookies is one way but hardly the only way).
  3. Cross-site search to reveal the victim's information. This is technically a subclass of CSRF, but it requires a local network position (e.g. MitM) and is focused on retrieving data rather than taking actions. It also works on many sites that are otherwise protected against CSRF, because CSRF protection often only applies to state-changing actions, and cross-site search isn't state-changing. The idea is, if your site has a search feature, the attacker can cause the victim's browser to submit search queries, and then the attacker looks at the size of the responses (which is visible "on the wire" even if it's encrypted). By varying the search, the attacker can potentially determine a lot. For example, one could potentially tell how often a victim sends emails or IMs to another user by using carefully crafted search queries that filter by sender, recipient, and date.

Some (not all!) other possible vectors for session hijacking:

  • Failure to use HTTPS and the Secure flag. If your session cookies can be sent over a plain-text HTTP request, an attacker can potentially steal them "off the wire". Use HSTS (HTTP Strict Transport Security) for extra protection here.
  • Low-entropy session tokens. If your session tokens are guessable or predictable (too short, generated by an insecure PRNG, or otherwise possible for an attacker to find a live one in a reasonable amount of time), an attacker can simply deduce the session token of another user and set that token in their own cookie.
  • Session fixation. If a user's token doesn't change when the user logs out, then on a shared PC (e.g. in a library, Internet cafe, or school computer lab) an attacker can log in, record the token they get, log out, and wait for a victim to log in. When the victim does, the attacker-recorded token now points to the victim's live session, and can be put in the attacker's own cookie on another machine to hijack the session.
  • Clickjacking (also known as "UI redressing"). This attack relies on the ability to embed your site in an iframe or other sub-document, which the attacker positions carefully on their own website, along with CSS to obscure (or mostly obscure) the embedded content of your site. Then, the attacker tricks the user into clicking on locations that the user expects to interact with the attacker's site, but which actually pass those clicks through to the embedded sub-document pointing at your site. While complicated attacks are hard with clickjacking, you could potentially entice a user to do something like click a button that turns off a security feature, installs a malicious add-in, or deletes some content.
  • SQL injection (or other server attack) to steal sessions tokens. There are many things that SQLi and other server-side attacks can be used for. In fact, usually these are much more powerful than just hijacking another user's session. But if you particularly want to, you could potentially dump the table of active sessions from the DB (or wherever else it's stored) and then set any of those tokens in your own cookie to take over that session. This can be mitigated by hashing the token before storing or looking it up in the DB (which also prevents linear-time brute-force guessing of the token via timing attacks) but, like HttpOnly, mitigating that specific threat isn't enough, you really need to prevent SQLi (and XSS) in full generality.
  • Thank you I started to study about a short time ago your answer was very complete and will help me a lot!!
    – H01F
    Commented Jan 7 at 14:48

CSRF attacks don't require JavaScript access to the session ID. In fact, they are typically performed from other sites (hence the name Cross-Site Request Forgery) which are already blocked from reading the session cookie due to the same-origin policy. The problem is that if an attacker-controlled site tricks your users into making a request to your site (either automatically through JavaScript or by getting them to click a button), then this request will, by default, include the session cookie automatically and look authentic. To prevent CSRF, you need an additional token which is included in the form data. Since this anti-CSRF token is not sent automatically as a cookie, the attacker would have to actually read the token value from your site -- which they cannot due to the same-origin policy.

However, there is a different cookie parameter which does provide some protection against CSRF attacks: Through the SameSite attribute, it is possible to prevent the session cookie from being sent in cross-site requests and stop CSRF attacks from other sites. This protection is weaker than anti-CSRF tokens, though, because it does not prevent attacks from subdomains and is not supported by legacy browsers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .