3 ms·

A big one I've seen is more related to the TLS cheat sheet [1] they link to on that page. Many sites will send session tokens over http because they don't set

by AUmrysh 12y ago

A big one I've seen is more related to the TLS cheat sheet [1] they link to on that page. Many sites will send session tokens over http because they don't set the "secure" cookie flag. It's a simple thing to do, and prevents a malicious ARP poison or DNS attack from potentially hijacking an account. You'd be surprised how many sites are vulnerable to such attacks. Reddit, parts of Ebay, several university websites, and many other sites still are vulnerable to session hijacking. I think people writing web libraries need to start building "sane defaults" concerning security. All cookies should be secure by default, and only those who know what they are doing should turn them off. It's not that much extra overhead, and the potential benefits outweigh the increased processing and bandwidth. 1: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Use_.22Secure.22_Cookie_Flag https://www.owasp.org/index.php/Transport_Layer_Protection_C...

Someone1234 12y ago
Great point. Setting "SECURE" and the poorly named "HTTP" are key to cookie security. One issue we ran into was: So our site runs behind a load balancer. We receive HTTPS connections into the load balancer but the internal connection between the load balancer and the actual websites was HTTP only, so when we tried to set SECURE on the cookies, the application framework we were using trying to be "helpful" unset the SECURE flag because it detected that the connect from its perspective was not secure (even though from the browser's perspective it was). Keep in mind that the connection between load balancer and web-servers was never on the internet, in fact it never left a virtual machine farm (a single room essentially). So it is justifiable doing HTTP internally and HTTPS externally (and also makes certificate management easier). We finally had to hack away a bit on the framework to get it to set secure regardless of the connection type.
noinsight 12y ago
> Many sites will send session tokens over http because they don't set the "secure" cookie flag. It's a simple thing to do, and prevents a malicious ARP poison or DNS attack from potentially hijacking an account. Or you can of course enforce HSTS so that HTTP never gets used.

by AUmrysh 12y ago

Someone1234 12y ago

Great point. Setting "SECURE" and the poorly named "HTTP" are key to cookie security. One issue we ran into was: So our site runs behind a load balancer. We receive HTTPS connections into the load balancer but the internal connection between the load balancer and the actual websites was HTTP only, so when we tried to set SECURE on the cookies, the application framework we were using trying to be "helpful" unset the SECURE flag because it detected that the connect from its perspective was not secure (even though from the browser's perspective it was). Keep in mind that the connection between load balancer and web-servers was never on the internet, in fact it never left a virtual machine farm (a single room essentially). So it is justifiable doing HTTP internally and HTTPS externally (and also makes certificate management easier). We finally had to hack away a bit on the framework to get it to set secure regardless of the connection type.

noinsight 12y ago

> Many sites will send session tokens over http because they don't set the "secure" cookie flag. It's a simple thing to do, and prevents a malicious ARP poison or DNS attack from potentially hijacking an account. Or you can of course enforce HSTS so that HTTP never gets used.