I’m trying to educate myself on potential web attacks. I just found a site (which will rename anonymous) where it shows me what looks to be like the php session id inside the cookies section of the request header.
My immediate reaction was “wow, that’s bad”… but then i couldn’t really come up with a scenario as to how someone could use this to mess up the site.
But maybe its because I’m a newbie to this stuff.
But assuming that I got someone else’s session id… I’d have to hack the site with their session id before it expires right?
So my question is, how real is this threat?
And is this common, where web developers store session ids in cookies, thereby making it visible in F12?
Sorry for the remedial questions.
I read the article:
Why do popular websites store very complicated session-related data in cookies — and what does it all mean?
And i get that sometimes, you want to use cookies to move data off server to client… but I think I need more clarification on how serious a security breach this is.
1
This SO question indicates it’s not really an issue so long as you are using random numbers for your session ids and take a few other precautions like encrypting the communication channel.
Let’s say Alice is using Bob’s web application (running on Bob’s server). HTTP does not have a concept of a session, so each page that Alice loads exists in isolation. The session cookie is something Bob sends back to Alice’s browser when she logs on so that he can keep track of all the requests coming from Alice.
Therefore, the session cookie announced to Bob “this request comes from Alice”. Bob implicitly trusts this. When he sees the cookie, he knows he is talking with Alice.
Where does this go wrong? When someone else than Alice can see the cookie.
Suppose Alice is sitting on an unencrypted wifi network. Mallory is sitting on the same network and sees the traffic between Alice and Bob. Suppose the traffic is unencrypted (HTTP instead of HTTPS). Now Mallory sees the HTTP cookie that Alice sends to Bob. Mallory can use their technical knowhow to send a request to Bob with Alice’s cookie embedded in it, and Bob will respond to Mallory thinking that he is responding to Alice. This is what tools like Firesheep automate, but really anyone can do this sort of attack on any site accessed over HTTP on an open network.
Now, circling back to your question, this explains the common practices with session cookies:
- Never put the session id in the URL. Otherwise Alice might send a link to Mallory via IM or some other channel that includes her session id. Mallory has her session id, so he can pretend to be her.
- Always use HTTPS to prevent eavesdropping over Wifi. If the network traffic can be intercepted, and the cookie can be heard, Mallory can use it to pretend to be Alice.
If an application is used over HTTP, then the session can be intercepted by someone listening in on the network traffic, and the application is open for attack. How likely this is depends on whether someone decides to target the app and can find unsecured networks where the app is being used. Therefore, for unpopular web apps the risk is low, but for popular web apps the risk is very high. This is why facebook moved to HTTPS by default, and why Yahoo Mail now has the option to enable it.
There is no risk in F12, because there is no harm to Alice knowing her own cookie. There is only a risk if Mallory can see her screen and copy the cookie for his private uses.