I've been asked to analyse an old web app which stores sensitive information in cookies rather than sessions/similar. (To be precise, it's classic ASP and uses cookie families). The only clients are IE 6/7/8
After the process in question has been completed on the web app, the cookies are cleared down.
The question I need to answer is: once this has happened, how hard would it be for someone to recover the information in the (deleted) cookies?
My understanding is as follows but I would appreciate some confirmation / any additional issues anyone can think of.
The cookies shouldn't be intercepted across the network as they're passed via SSL. They could be viewable in server memory/log files (the app has v. comprehensive logging)/memory dumps (?)
On the client, the cookies are stored in a text file. When the cookie is cleared down, the text file is deleted.
Although the file could be recovered by undeleting it, I believe this is encrypted by ie when it's first written? (I can't test this on ie6 but it seems to on ie7 for http and https)
Assuming it IS encrypted, can anyone confirm how secure this is?
I'm also looking into how the cookies are stored in memory and how easy it would be to retrieve them - Any advice on this would also be appreciated.
The cookies are used to access a database but again, all connections use SSL so this shouldn't be an issue. The database is locked down.
I can't see any other ways of an unauthorised user accessing the cookie contents. What - if anything - am I missing?
We're likely to change the mechanism used anyway but I do need to provide a clear list of vulnerabilities for the current system before we can proceed (to make sure they're all addressed).
Many thanks for any help you can provide.
Storing sensitive information is the vunerability, this means that one way or the other your system can be attacked by stealing information in these files.
The attack is most likely to come from the client side (if your server can be attacked that's already a problem). The only question is how the cookie can be retrieved from the client machine. Since you're using https this only leaves for someone accessing the cookie on the client machine. The vulnerability lies here. All browsers store cookies on the disk and I would doubt they encode them (why would they?). I would look into how IE7, Firefox, Google Chrome and Safari store these cookies but probably not in a really secure way. The biggest vunerability is probably here: if someone writes a program to collect this data and is able to deploy it.
If I were you I would change the application to use sessions instead cookies ASAP. The longer you wait, the bigger the risk that someone can access these credentials.
Related
I did a small sample test and found that almost all web sites I tested suffer from the vulnerability where I can access restricted pages (ie pages that require logging in) even after I have logged out from the browser if I save the cookies while I am still logged on.
The test was fairly simple. I just replayed a web request in Fiddler after I had logged out from the browser. For example, with outlook.com, after logging out, I could replay the page that shows the address book and still get my contacts' email addresses.
May I know what the industry standard is regarding this as I have one customer who insists on fixing this vulnerability but not wanting to increase the hardware specs.
I'm not sure if there's an industry standard, but there are best practices. And the best practice is to clean the cookies, and cookie management.
You shouldn't have to worry about hardware on this either. It's a simple lookup to see if a value is valid. If it isn't, then the session state shouldn't get resurrected.
Again, I would use HttpOnly and a secure flag on the cookie. That way, it will limit replay attacks more. And when it comes to resurrecting sessions, make sure that session files are destroyed on the server, not just abandoned.
Abandoned sessions mean they can potentially be resurrected.
Hardware will generally not be an issue with this problem. If it is, then look at your solution, as there might be a better way.
From what I understand and have read about sessions, a website, like Facebook, will store a code on your computer that your computer sends back to Facebook every time you visit their site. This saves you the trouble of logging in every time you want to see your news feed.
My question is, how is this in any way secure? Can't anyone write a simple program to find this code on your computer - just like Facebook does? Or if you let your geeky friend use your computer, how do you know he doesn't copy your session codes and just use your account from somewhere else?
I read that sessions are more secure than cookies because cookies actually carry information like your username, password and other vital info. But if a session code can provide access to your whole account anyway, isn't a session just as insecure?
Are there any other factors at play that I don't know about or are sessions really this insecure?
My question is, how is this in any way secure? Can't anyone write a simple program to find this code on your computer - just like Facebook does?
Yes. Someone can do that. And they can steal your session credentials. If your computer is compromised, you can't build any form of security on top of that. If you can't trust the computer, you can't trust the browser. And if you can't trust the browser, there's no way you can possibly trust the website.
So we need to start with a fundamental assumption. To secure the website, we must assume the browser (and hence the computer) is secure.
If you can get code onto the computer to search for the session identifiers, it's game over already, since you can typically do much worse while you're there.
Or if you let your geeky friend use your computer, how do you know he doesn't copy your session codes and just use your account from somewhere else?
You don't. This is why you shouldn't let friends use your computer (among other reasons).
There are some techniques that can be done to verify the session came from the specific computer. But they tend to be either insecure (like verifying user agents) or fragile (like verifying IP addresses).
I read that sessions are more secure than cookies because cookies actually carry information like your username, password and other vital info. But if a session code can provide access to your whole account anyway, isn't a session just as insecure?
Sessions are no more secure than cookies, because the session uses a cookie for identification. Sure, the specific data doesn't leave the server (so it doesn't leak), but the attacker can resume the session.
Are there any other factors at play that I don't know about or are sessions really this insecure?
The key here is who are you trying to protect against. Specifically, what threat model:
A friend, who you give admin access to your computer (let them borrow with a privileged account)
You can't reliably protect against that. If your users let others borrow their computer, you, as a website operator, can't help that unless you don't use a session at all and require users to authenticate every action.
Simply don't do it, or give them a clean guest account. Or better yet, use a chromebook, and let them sign in with their own account.
An attacker getting code onto the computer
You can't help that.
Someone snooping the network traffic (read-only) like a network packet sniffer.
Use TLS (HTTPS)
Someone man-in-the-middle attacking the network traffic (read/write)
Use TLS (HTTPS)
Someone attacking the server
Secure your server!!!
In general, to figure out how to secure something, you need to consider the vector the attack is going to come from. Some attacks you simply can't defend against. And some, you just need to educate the user about.
Session IDs are stored in cookies, so their security is the same as that of cookies.
Cookies are handled by your browser, which takes care of protecting them to the extent that it's possible.
No website can "ask your browser for a cookie" (and that is not what Facebook does). Instead, when accessing facebook.com, your browser sends along your facebook.com cookies, but not your google.com cookies.
Of course, "writing a simple program to find this code" would be easy, but distributing it wouldn't be that easy (i.e. you're talking about distributing malware), and it's definitely not what Facebook does to get access to the relevant session cookies.
There are several additional ways to protect cookies from unauthorized access (to a certain extent). One of them is to make them "HTTP-only", so that they aren't accessible in Javascript (they'll still be sent to Facebook's servers, but the browser won't expose them to anything else).
Note that cookies are indeed as secure as the browser itself. If your browser is "compromised" (by your geeky friend), then so are your cookies, and so is your session.
My program sends a request to a web page over SSL and in the header (https://example.com/index.php?clientid=xxxx?spcode=xxxx) is a manager password used to determine if they are a valid client of my system before I send them a bunch of data.
If a rogue employee were to obtain this password by snooping on the local SSL data, he could potentially toy with client orders being sent and received if he were to guess order numbers (not hard).
I'm aware of how to use bcrypt to protect someone's password on my system. But how do I protect someone's password when someone else is using they're system?
I know you shouldn't send a pre-hashed password at risk of revealing your salt. Should I use some soft of temporary transmission hash (one that differs from what I store it in the DB with). I'm thinking this isn't the best way, so I'm asking you all for help. I've found some great tips here at Stack Exchange.
Thank you in advance for your time, everyone. I look forward to your thoughts.
Snooping on SSL can only be done by man-in-the-middling, and that's detected.
Consider how if you do so in fiddler, the browser reacts by complaining about the certificate. Of course, since you trust you not to spy on you, you okay it!
Comparably, you're going to see that you aren't dealing with a server with the correct certificate. If your app refuses to deal with other certificates, then it won't allow the SSL connection to be estabilshed, and there's no snooping.
I'd still recommend sending the password in authentication headers though, as per RFC 2617, NTLM, or so on. Especially if you move to also doing server-to-browser on top of the same system later, and wouldn't want them to be snoopable from the address bar.
Edit: Depending on what you write the app in, it can be temporarily allowing snooping for debugging purposes that proves trickier!
I have a question concerning cookie storage design. I am developing a web application which should cache it's server-fetched data to a local storage. No user credentials will be stored.
What is in the cookie:
list of data and it's properties
proof for up-to-dateness
Proof for up-to-dateness will not be a hash, but most likely a timestamp of the last write to the server which is checked against the DB. This is to ensure the user gets valid info if he has used the website on another browser/computer/device and is out of sync.
The cookie should be able to handle more than one user in it and most probably some sort of encryption so other people can't see plain-text data. Military-grade security isn't needed here as the information here is not so important. But everything hacked in less than 30-60 minutes should be considered unsafe.
Questions:
How to encrypt my data
How to enable the cookie for multiple users
How to prevent the cookie from being stolen
What would be a good and simple way to present the option to disable cookie caching and explain to my users the risks of using caching on public computers
Is the whole idea any good at all
What are some potential issues I haven't accounted for
I'll answer #5 (which renders the rest of the questions moot).
Cookies aren't designed for that sort of thing. They are make a round trip with every HTTP requests - including on same domain CSS, images, JS, etc.
I suggest you look at HTML 5 local storage or just sending the data down to the browser every time with a minimal key cookie.
For #3 - there isn't a way to fool proof way prevent someone from stealing a cookie or forging a duplicate.
What methodologies do people recommend for mitigating the 'Firesheep' method for website applications?
We have thought about this and from a usability perspective, other than encrypting all traffic to a site, mitigating the attack can be somewhat of a problem for web developers.
One suggestion we came up with was to use path based cookies, and encrypt traffic for a specific path where account operations or personalised interaction happens. This however complicates usability however, in as much as the rest of the site (the un-encrypted - un-authenticated) bit does not know who the user would be.
Does anyone have any other suggestions for mitigating this vector of attack, while maintaining a usable level of usability?
Firesheep is nothing new. Session hijacking has been going on for more than two decades. You don't need "encrypt" your cookie, thats handled by your transport layer. Cookies must always be a cryptographic nonce.
Usually hackers just set their own cookie by typing this into the address bar javascript:document.cookie='SOME_COOKIE', FireSheep is for script kiddies that fear 1 line of JavaScript. But it really doesn't make this attack any easier to perform.
Cookies can be hijacked if you don't use HTTPS for the entire life of the session and this is apart of OWASP A9 - Insufficient Transport Layer Protection. But you can also hijack a session with XSS.
1)Use httponly cookies. (Makes it so JavaScript cannot access document.cookie, but you can still do session riding with xss)
2)Use "secure cookies" (Horrible name, but its a flag that forces the browser to make the cookie HTTPS only.)
3)Scan your web application for xss using Sitewatch(free) or wapiti (open source)
Also don't forget about CSRF! (Which firesheep doesn't address)
Well I found an interesting article on GitHub that describes a method of mitigating the firesheep attack.
https://github.com/blog/737-sidejack-prevention
Anybody tried taking advantage of the "Web Storage" in HTML 5 to store a shared key (passed during SSL-encrypted responses during authentication) that is used by javascript to alter the session cookie over time?
That way, the stolen (unencrypted) session cookies would only be valid for a short amount of time.
My guess is that Web Storage is segmented by port (in addition to host), so it wouldn't be possible. Just throwing that idea out there in case anybody wants to run with it.
When user logs-in, store the IP-address in the session.
On each subsequent request from this session, check that the IP-address matches the one stored in the session.