Can a cookie be edited from the browser?

[Unity+]

After working on my website and adding in PHP security while using cookies to determine if someone is logged in as a certain user, I thought of something that may be bad if it can occur.

 

Can a cookie be edited from the browser? If this is the case, then a person can simply edit the cookie to make themselves be disguised as another user which means I will have to modify the way users can sign in and such. I assumed that there is security behind the cookie so people can't do this, but wanted to make sure it was accurate.

[Sato]

Yes, a cookie can be edited through a browser via javascript. This is only a concern if the attacker can get access to their target's cookie, which should be securely stored in your database and on user's browser. Make sure to sanitize all your input so that nobody can execute database commands, which I think can be done using the mysql_real_escape_string() function in PHP (if you're using a MySQL db). Also, namely because if someone has access to your database they probably won't be bothered to forge their target's cookie, your primary concern for this matter would probably be an XSS attack. This is when you allow a user to provide some information or data and it is displayed back on some part of the website; if you don't sanitize the output (with htmlentities() I believe), the user will be able to input HTML and javascripts that when displayed on the site, such as in the username, will be interpreted as HTML/JS and ran by viewers' browsers. So, in the context of session forgery, one could deliver a script which accesses a user's cookie and sends a request to their own server adding it to a log file or something of the sort. The attacker can then go onto your website and replace their session cookie with what was sent to their log, and access the site as someone else. Also remember to sanitize the user's cookie before you check it against what's in the database, as someone could edit their cookie and replace it with a MySQL command.

[Unity+]

Yes, a cookie can be edited through a browser via javascript. This is only a concern if the attacker can get access to their target's cookie, which should be securely stored in your database and on user's browser. Make sure to sanitize all your input so that nobody can execute database commands, which I think can be done using the mysql_real_escape_string() function in PHP (if you're using a MySQL db). Also, namely because if someone has access to your database they probably won't be bothered to forge their target's cookie, your primary concern for this matter would probably be an XSS attack. This is when you allow a user to provide some information or data and it is displayed back on some part of the website; if you don't sanitize the output (with htmlentities() I believe), the user will be able to input HTML and javascripts that when displayed on the site, such as in the username, will be interpreted as HTML/JS and ran by viewers' browsers. So, in the context of session forgery, one could deliver a script which accesses a user's cookie and sends a request to their own server adding it to a log file or something of the sort. The attacker can then go onto your website and replace their session cookie with what was sent to their log, and access the site as someone else. Also remember to sanitize the user's cookie before you check it against what's in the database, as someone could edit their cookie and replace it with a MySQL command.

Thank you for the response. I will make sure that everything is secure.

[Sensei]

Session id stored in cookie should be id to database entry in currently open session table.

Database record should store IP address of owner of session,

and code should check whether db IP matches with what is clients IP.

 

This will make sure that even if somebody intercept cookie value, he/she won't be able to use it, because their IP will be different than original client that opened session.

As long as they didn't intercept whole client network and are able to show up as the same IP..

[Sato]

Session id stored in cookie should be id to database entry in currently open session table.

Database record should store IP address of owner of session,

and code should check whether db IP matches with what is clients IP.

 

This will make sure that even if somebody intercept cookie value, he/she won't be able to use it, because their IP will be different than original client that opened session.

As long as they didn't intercept whole client network and are able to show up as the same IP..

 

This causes unneeded trouble for anyone on a network with a dynamic IP address and anyone who accesses the service on a phone, laptop, or tablet which moves around and connects to different networks, all of which will constantly log the user out. It's safest and best-practice to actually secure and sanitize all I/O than to use a back-of-the-hammer work around like that; besides the point mentioned in my first remark, even if one can't access the session, they would still be able to execute malicious scripts and ergo interact with the website on the target's browser, and, most importantly, an IP address can be spoofed by directly modifying the request packets, rendering that validation useless.

[Sensei]

even if one can't access the session, they would still be able to execute malicious scripts and ergo interact with the website on the target's browser,

 

You're talking about obvious, must have, things that should be done with the all data coming from $_GET/$_POST/$_COOKIE etc. (not just session id).

 

Checking IP is not replacement for basic checks, but yet another level of security.

 

All mine Internet bank accounts, and stock market brokers that I am using, are utilizing this technique.

You cannot be logged to the same account from two different computers at the same time.

Good secured services refuse it immediately.

They ask you "you're logged from IP x.x.x.x, do you want to terminate session and open new one?"..

 

Even better is making history of logging with IP recorded.

And showing this info to user when he/she is starting session.

User will be immediately warned about logging somebody with "wrong" IP, at wrong date and time.

Edited May 25, 2014 by Sensei

[AtomicMaster]

Session id stored in cookie should be id to database entry in currently open session table.

Database record should store IP address of owner of session,

and code should check whether db IP matches with what is clients IP.

 

This will make sure that even if somebody intercept cookie value, he/she won't be able to use it, because their IP will be different than original client that opened session.

As long as they didn't intercept whole client network and are able to show up as the same IP..

Don't be silly, that is not a security solution, give you an example: i steal your cookie while you are browsing the site at starbucks... we have the same IP... or do you trust the IP address i sent you?

 

There is no way to prevent session hijacking, short of really good crypto (dnssec + strong ssl) and even then it is possible locally. The only thing you can do is to detect it. The way you detect it is you have a 2 token system, one is your login token, another token rotates every request. as soon as a login token matches but the rotating token does not match, you know that someone hijacked the session and can therefore alert the user. You can not prevent it and you can not detect it while it is happening if the user goes offline...