CODEWITHSUNDEEP
node.jssecurityauthenticationcookiesjwt
Tidris
Tidris

Reputation: 373

I can still edit cookie even with httpOnly using cookie editor

I've been told that putting httpOnly:true on the cookie prevents the browser from editing cookies, but I can still edit it on my local server.

Here is what I currently have every time I make a cookie

res.cookie("jwt", token, {
  expires: new Date(
    Date.now() + process.env.JWT_COOKIE_EXPIRES_IN * 24 * 60 * 60 * 1000
  ),
  httpOnly: true, // cannot be modified by the browser
});

Upvotes: 0

Views: 3091

Answers (2)

Tanveer Yousuf
Tanveer Yousuf

Reputation: 406

It is just a flag to make the cookie inaccessible to client-side scripts (e.g. JavaScript code). Using Developer Tools to access resources like cookies is not the same thing.

Upvotes: 0

Gabor Lengyel
Gabor Lengyel

Reputation: 15589

According to the specification (rfc6265), the user agent (ie. the browser) must not allow scripts in a page to access cookies marked as httpOnly. This does not mean that the browser itsef may not have access - that in fact would be impossible, because the browser has to send the cookies with requests. If you control the browser (which you do in case of your own browser), then you as the user have full control over any data stored in that browser, including any cookie with any attributes.

This is the whole point in many security vulnerabilities. As a malicious user, you can try editing values stored in your browser to get around poor access control in web applications, like changing ids and similar to get access to data the developers did not mean accessible by you. As this is easily possible (data received from the client can be tampered with by the client itself), all authorization (access control) decisions must be made on the server.

So what is the point in httpOnly then? In a class of attacks, the goal of the attacker is to somehow inject javascript into an application page (see cross-site scripting, XSS). The reason is that even if an attacker somehow gets a user to visit their malicious website, the javascript running on the attacker's site will not have access to the information (eg. cookies) stored by another application (origin). So to gain access to such info, the attackers javascript would have to run on the application page, and that is actually possible if the application is vulnerable to XSS.

So in case of XSS, the attacker writes javascript, injects it into an application page, and when a legitimate user visits the page, the victim will run the attacker's javascript, in the application context. This allows an attacker to access any application information the user has access to, proibably most importantly the authentication cookie. If the attacker gets hold of the auth token (traditionally from a cookie), they can probably just impersonate the victim to the application.

And this is prevented by httpOnly. If a cookie is marked as httpOnly, javascript (including both the legit javascript of the website, and the attacker's malicious javascript) will not have access. This prevents an attacker being able to compromise data stored in httpOnly cookies, via XSS.

Note that XSS is still an issue, the attacker can still extract information, this does not prevent XSS at all. It just means that any data stored in such cookies will not be compromised, but there is likely a lot more data that would be.

Also note that as you correctly observed, this does not prevent you from editing your own cookies - again, the purpose is not message authentication. If the application wanted, it could authenticate and/or encrypt its own cookies for different reasons, some frameworks actually do that to statelessly but still securely store session information. But that is independent of what httpOnly does.

Upvotes: 3

Related Questions