Should the server send 'secure' cookies on unsecured http response?



  • I noticed that the module cookie-parser in NodeJs sends back cookies that have the "secure" attribute set, even in an unsecured http response. They have specified this behavior in their readme, or at least in the readme of a dependency, but is this really the way it should work?

    I have read the following sentence on Wikipedia but I'm having problems understanding it:

    Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity

    I guess an active network attacker can overwrite secure cookies by setting it with another value and secure=false, but this is not the issue I'm adressing here. Protecting the confitentiality should be exactly what I'm looking for, but the cookie would need to be sent only over https if I understand it correctly.

    I have created a small project to illustrate the question in NodeJs, "secureTest" is accessible from the browser:

    const express = require('express');
    const cookieParser = require('cookie-parser');
    
    // Setting up express & must use middleware
    let app = express();  
    app.use(cookieParser());
    app.use(function(req, res, next) {
        console.log("cookies: ", req.cookies);
        res.cookie('secureTest', 'test', {
            secure:true,
        })
        next();
    })
    // routing
    app.get('/', function(req, res) {
        return res.status(200).send();
    });
    
    // Setting up node js server 
    let port = 8080;
    app.listen(port, () => console.log(`Server running on port ${port}...`));
    

    Note: I think this is still on topic as the question is whether this behavior is desired, not how to solve the issue in NodeJs itself.



  • Yes, the behaviour is correct. It is the browser that must not send back the cookie unless on a secure connection.

    This is because you might connect to a server today, on a secure connection, and connect back tomorrow, same host, same address, insecurely. The second connection should not leak the cookie, but request another (which will be sent again with the Secure attribute set, to prevent this unsecure cookie to be re-used in a secure connection).

    This is in a "intermediate security" scenario in which the server accepts to connect insecurely, and merely endeavours to keep the secure session and the insecure session separate.

    I think that the browser should treat the two cookies as completely separated, as if they came from different web sites. But this is at the browser's discretion. It might replace the cookie, in which case the previous session is lost (and its content remains secure).


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2