45

Assuming a site is using all HTTPS all the time (LB redirects port 80 to 443), is there any reason not to force every cookie set by the application to use BOTH secure AND httponly?

Currently, for example, a PCI scan will only flag the jsessionid as not using the secure attribute, but tomorrow it could be the other one, so I'm trying to get ahead of it.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
user2145893
  • 553
  • 1
  • 4
  • 4
  • 7
    A lot of the time you want JS to be able to read to cookie to pass info back and forth to the server without additional http connections like ajax. – dandavis May 24 '18 at 18:25
  • 1
    this can be achieved without using the document.cookie API too. HttpOnly provides protection against reading of cookies against XSS attacks. It should be used if possible. – entropy May 24 '18 at 18:51
  • 2
    The obvious reason is that it isn't httponly. Like when you have JavaScript that reads from cookies. – Anthony May 25 '18 at 06:15

5 Answers5

46

Yes, there are cases where you don't want HTTP ONLY or SECURE.

If you need javascript to see the cookie value, then you remove the HTTP-Only flag. A couple cases - some sites track the page state in a cookie using javascript to read and write the cookie value. CSRF mitigations often rely on the server sending a value in a cookie, and expect javascript to read that value.

The Secure flag is more important. If we expect all sites to run over https, and only https, then the only http part is a redirect to https. You never want your cookie sent in the clear. Well, almost never. Here are two cases where you might:

  1. development environments often don't have, or don't need to have TLS certs (though maybe they should).
  2. to track activity that originated on http. You might even use your load balancer to set an insecure cookie before it sends back the redirect. Then your application analytics can track which URLs came in as HTTP. Your load balancer can track which sessions came in as http.

In practice, if you're running an https site, always set the secure cookie, and always error on the safe side by setting HTTPONLY, unless you know your javascript requires cookie access.

UPDATE - TLS in Development

A lot of talk about whether you should or shouldn't use TLS in development. Posted the question here:

Should I develop with TLS on or off?

Jonathan
  • 2,288
  • 13
  • 16
  • 14
    `development environments often don't have or need to have TLS certs` <-- but should. They can use a self-signed certificate or even one made with Lets Encrypt. – Ismael Miguel May 25 '18 at 08:13
  • 1
    Oh, another point to use https: how can you know your website is working properly with https if you dont test it with https before deplying? – Ismael Miguel May 25 '18 at 11:40
  • 22
    @IsmaelMiguel: There is literally no need to bother with that in a local development environment and it prohibits examining data on the wire. "It should" is false. However yes you should do a test before deploying. – Lightness Races in Orbit May 25 '18 at 11:50
  • 15
    @IsmaelMiguel You can't Let's Encrypt a local, non-Internet-addressable developer site, and self-signed certs are usually problematic, especially in organizations that also have security restrictions to prevent accessing sites with certificate issues (since self-signed certs can't be verified, the site itself would be inaccessible for anyone to test). – phyrfox May 25 '18 at 12:01
  • @phyrfox That's a specific instance of a development environment – Ismael Miguel May 25 '18 at 12:18
  • 9
    @IsmaelMiguel Yes, but that's my point. If I don't want to expose my site to the Internet, and I'm in some sort of enterprise, restricted network, then your advice is at best useless and possibly even harmful (e.g. you enable TLS and lose access to your management console). Of course you should prefer security over not, but a blanket statement like "but should" could cause someone somewhere grief. At minimum, it should be a qualified/conditional statement. – phyrfox May 25 '18 at 12:26
  • 2
    @phyrfox Exactly! I said *should*, not *must*! One is a suggestion, the other is a demand. Basically, you should use a certificate and enable TLS, but you aren't obligated to. It isnt mandatory. You still should find a way, if viable. – Ismael Miguel May 25 '18 at 13:58
  • 2
    and this is the reason data breaches, defacings and all kinds of mischief are made possible and happen all the time. Your development environment should be as close as possible to your deployment environment, otherwise you will invariably start amassing technical debt or end up developing in a way that will be difficult or impossible to secure, or worse. – hlecuanda May 26 '18 at 00:44
  • 3
    Note also that the layer that does SSL termination does not need to be the layer that actually serves the request. Decoupling those layers can greatly ease development pains. Ideally, of course, TLS termination is done on the same machine as the application logic, or at least within the same trusted network segment. Otherwise you need a new TLS session, and now you have two problems. – Kevin May 26 '18 at 03:55
  • 1
    @LightnessRacesinOrbit But this question shows the dire need of developing in TLS! OP exactly followed your path: system is developed as open, nobody has experience how `secure` works, and after devs finish, TLS is slapped on top of it like a magic talisman. The exact opposite is true: "There is literally no need to bother with open connection in a local development environment except cases of examining wire". This gives everyone understanding of how TLS works and how it's different from open connection. BTW, you can examine wire with MitM, that also teaches certpinning. Security first. – Agent_L May 27 '18 at 06:34
  • 1
    New question posted: Should I develop with TLS on or off? https://security.stackexchange.com/questions/186796/should-i-develop-with-tls-on-or-off – Jonathan May 30 '18 at 20:33
  • 1
    Just a nitpick: having SSL on your dev/internal environment *IS* a good practice, and does *NOT* prevent you from viewing the traffic on the wire; that's what a simple SSL proxy is for. – Angelo Schilling May 30 '18 at 23:49
  • @AngeloSchilling even chrome dev tools will show you a lot of what you need in the network tab. – Jonathan May 30 '18 at 23:56
22

Regarding httponly you are essentially asking if they are use cases where a cookie needs to be read or set by Javascript. Typically some settings of the user interface (choice of language ...) are preserved this way which would break if the cookie is httponly.

As for secure: since according to your description the site is using https all the time it does not harm to have all cookies secure.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
10

Secure Flag

Considering that the application is running over HTTPS i.e. LB redirects all port 80 traffic to 443, it is still required to enable the secure flag in light of the following scenario.

  1. Assume that there is a developmental glitch as a result of which a hyperlink contains the HTTP (eg. http://example.com/some_page.php) link instead of the HTTPS (eg. https://example.com/some_page.php) link.
  2. The browser requests the web resource over HTTP and sends the cookie along with it due to the absence of the secure flag.
  3. The request reaches the LB which redirects the traffic to port 443 i.e. over HTTPS.
  4. The browser re-initiates the request but this time over HTTPS with the cookie value.

Hence, although the LB is configured to redirect port 80 insecure traffic to port 443 secure traffic, a successful MiTM attack could take place at step 2 resulting in the impersonation of a user by stealing the sensitive cookies. Moreover, verifying that the hyperlinks and redirects are properly coded is a comparatively more strenuous activity than enabling the secure flag on sensitive cookies. To conclude, although a redirect is set-up at the LB Level there could be possible scenarios where a fruitful MiTM could be executed due to the absence of the secure flag.

httponly Flag

This is a flag whose significance stays independent of the Transport Layer Security (SSL/TLS). The httponly flag is used to prevent javascript from accessing sensitive cookies like the session cookies in the event of a successful Cross-Site Scripting (XSS) Attack. When the httponly flag is not set on the cookie value, the malicious javascript injected into the application due to an application level flaw could end up sabotaging the confidentiality, integrity and availability of user accounts by reading session cookies and sending them to remote servers for instance, thereby successfully impersonating a legitimate user. Hence the httponly flag should always be set on all cookies or at least the sensitive ones.

Tony Thomas
  • 341
  • 1
  • 8
  • If the site in question is a SPA, then you typically do not want httponly, but you'll also need to use CSP and other security measures to prevent rogue scripts from stealing session data. – phyrfox May 25 '18 at 12:07
  • I totally agree @phyrfox there is always the possibility of using CSP to prevent rogue scripts from stealing session data. But lets also consider the fact that httponly has a greater browser support compared to CSPs. Source: http://www.browserscope.org/?category=security – Tony Thomas May 25 '18 at 12:53
6

I'll give you a practical example of a non httponly cookie.

When a visitor comes to my site there are two cookies shoved down his/her throat.

phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax

The cookie_law contains a base64 encoded json encoded cookie object that stores the cookie settings.

My javascript reads those cookies to determine to load analytics, adwords dependent on permission or status.
My javascript also uses that cookie to make the cookie settings editor work.

If I set the httponly flag on the cookies the javascript can't read it. And I can't use php to determine load status when rendering the scripts because of multiple layers of caching. Thats why I chose to leave the httponly from that cookie.

The javascript needs access to be able to read it.

Tschallacka
  • 293
  • 1
  • 9
4

http-only: Sometimes user preferences (font-size, theme, language, ...) are set and acted upon client-side. This is the most common case for needing them not set http-only.

secure: As the site/app insists on HTTPS there is no reason not to use the secure flag. If the site/app needs to offer access via HTTP and you need details to pass between encrypted/no contexts (perhaps the user's display preferences again) then you need to leave this off.

While it may seem to not matter as you currently force HTTPS access, you should allow for failures in that: your app may be redeployed with incorrect settings, or your users may find themselves subject to a MItM (either something malicious or a badly configured proxy) that has a similar effect and with this flag set things fail safe (from a security point of view) by stopping working rather than working insecurely.

General: As they are security measures, however minor they may seem, always set both unless you have specific reason not to, rather than ever defaulting to leaving them off unless you think they are needed.

David Spillett
  • 141
  • 4