1

I run a website in a quite cheap shared hosting environment (LAMP): technically speaking, in this context the only thing I can do is edit one or more htaccess files.

Maybe for load balancing purposes, the host serves two unsecure cookies.

Is there any way to set the Secure flag on both cookies from an htaccess file, overwriting their original values?

  • 1
    Aside: Any reason these particular cookies need to be secure? – MrWhite Sep 17 '18 at 7:36
  • Good question: this website is https. Sometimes, I submit the website to Mozilla Observatory or other similar websites (securityheaders.io, others related to SSL, etc.). They always report the same defect: an https website is serving unsecure cookies. They see it as a vulnerability, even if probably there's no vulnerability at all in this case. So, this is an "issue" I generally forget, but anytime I find again it I try to solve it, maybe just for curiosity. :-) – user93110 Sep 17 '18 at 7:42
  • 1
    "They see it as a vulnerability" - That's just a (wild) generalisation. This is a notice/warning at best. Not all cookies should necessarily be "secure" on an HTTPS site (unless perhaps it is HTTPS-only and does not even respond on HTTP). TBH, if this cookie is used for "load balancing" then it probably should not be served with the "secure" flag, otherwise it's not going to be able to "load balance" the HTTP requests - which could be detrimental to server performance. Just as an example, StackOverflow is HTTPS-only and sends 16 cookies, yet only 1 of those cookies has the "secure" flag set. – MrWhite Sep 17 '18 at 9:01
  • There's an online scanner that considers the issue as a "medium" level one. In their own words: "The remote web application sets various cookies throughout a user's unauthenticated and authenticated session. However, there are instances where the application is running over unencrypted HTTP or the cookies are not marked 'secure', meaning the browser could send them back over an unencrypted link under certain circumstances. As a result, it may be possible for a remote attacker to intercept these cookies", "add the secure attribute to all session cookies or any cookies containing sensitive data" – user93110 Sep 17 '18 at 9:27
  • 1
    "the browser could send them back over an unencrypted link under certain circumstances" - Although if you are implementing HSTS then you are certainly minimising that possibility. – MrWhite Sep 17 '18 at 12:08
0

tl;dr You probably can't do anything to influence the cookie the host is setting "for load balancing purposes".


Cookie set by application server

If the cookie is being set on your application server, then you can possibly intercept the response and override the Set-Cookie HTTP response header.

For example, based on an answer on StackOverflow, the following would unconditionally append the Secure flag when setting the cookie "MYCOOKIE" using Apache's mod_headers:

Header always edit Set-Cookie ^(MYCOOKIE=.+) "$1; Secure"

Or, based on another answer on ServerFault, the following uses a negative lookahead to first check that the Secure is not already set on the cookie:

Header always edit Set-Cookie "(?i)^(MYCOOKIE=(?:(?!;\s?secure).)+)$" "$1; Secure"

Cookie set by proxy/load balancer

HOWEVER, if the cookie is being set by a load balancer/proxy that is out of your control then the above method probably won't work. And any attempt to override the cookie may itself get overridden again by the proxy server, depending on when the proxy sets the cookie.

You could try something like the following using mod_rewrite, but bear in mind that you will also need to manually set the domain and path (and lifetime) parts of the cookie exactly the same as they are set by the host (eg. by checking the initial Set-Cookie HTTP response header you see in the browser), otherwise it won't override the same cookie. For example:

RewriteEngine On

RewriteCond %{HTTP_COOKIE} (MYCOOKIE)=([^;]+)
RewriteRule ^ - [CO=%1:%2:.example.com:1440:/:secure]

%1 is a backreference to the cookie name (eg. MYCOOKIE) in the preceding RewriteCond directive. And %2 is the corresponding value. .example.com, 1440 and / are the domain, lifetime (in minutes) and URL-path respectively of the cookie that you are trying to set and will need to be set manually.

However, as mentioned above, this may not do anything, as the proxy may simply overwrite this.

Reference:

  • I forgot to mention that I tried the first of the two ideas with no luck. I try the second but I'm pessimistic :-) – user93110 Sep 17 '18 at 6:17
  • Basically I get an error 500 after trying the second one :-) – user93110 Sep 17 '18 at 6:40
  • Ah sorry, should be a = (not :) immediately after the CO flag. I've updated my answer. – MrWhite Sep 17 '18 at 7:32
  • Ok, here's no error, but no effect to :-) Thanks, anyway! – user93110 Sep 17 '18 at 7:36

Your Answer

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