Menu
What are the security risks associated with turning off "session.cookie_secure" in PHP under secure connections? I'm itching to turn this off since I'm unable to access session data from https pages to http pages.
214
session. cookie_secure specifies whether cookies should only be sent over secure connections (HTTPS). If you're using HTTP, you won't get any cookies from the server. That's why you don't have a session.
session.cookie_httponly=On. Refuses access to the session cookie from JavaScript. This setting prevents cookies snatched by a JavaScript injection. It is possible to use a session ID as a CSRF token, but this is not recommended. For example, HTML sources may be saved and sent to other users.
A cookie is often used to identify a user. A cookie is a small file that the server embeds on the user's computer. Each time the same computer requests a page with a browser, it will send the cookie too. With PHP, you can both create and retrieve cookie values.
PHPSESSID – The PHPSESSID cookie is native to PHP and enables websites to store serialised state data. It is used to establish a user session and to pass state data via a temporary cookie, which is commonly referred to as a session cookie. (
The risk is that the cookie data is transfered over plain HTTP. Anyone sniffing packets on the network would be able to view the data in the cookie. Then, they can pretend to be you (Session Fixation).
Now, some would argue that if someone can sniff packets on the network, that they are in a position to execute a MITM attack so it's not a huge deal. However this is not 100% correct. Look at what happened with Google. They were able to sniff raw WIFI traffic without actually compromising the network (which would be required for a MITM attack). Sending cookies over HTTP can open up session hijacking attacks where if you kept them to HTTPS only they would not be.
If you need access to be secure, keep secure_only set. If you don't care about the data (or use multiple-factors, or want to risk it), then open it up...
One potential workaround is to use a custom error handler, and set 2 session identifiers (one is secure_only). Then you can "log in" via both, yet require the secure one for anything important (Such as accessing important data. This would require some work to do correctly, but could be a decent solution to the problem...
181
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
