EXPERT RESPONSE
Web sites use cookies to store information on a browser. Cookies hold data, such as user preferences and session tracking credentials, which the browser then presents to a Web site when the user accesses it again. If the Web site doesn't define and manage the cookies appropriately, however, this can lead to some significant security holes.
One possible threat is the disclosure of sensitive user information. Some cookies hold names and mailing address info; others have account numbers. Some cookies even contain passwords, a dangerous but not uncommon practice. When a user provides an ID and password at the beginning of a session, that application can set a session credential cookie back on the browser, which will present that cookie to the server at each browsing session's subsequent interaction. That way, the user doesn't have to authenticate again and again during the session. If a bad guy steals a cookie used for that purpose, however, the attacker can perform a "session-cloning attack," inserting that cookie into a browser and accessing the application as that victim user. Clearly, we need to make sure that our applications protect all sensitive cookies carefully.
To do so, Web application developers should minimize the information in cookies, making sure that they contain only data that the application absolutely must store on the browser.
Next, a Web application developer should make sure that cookies are marked as "secure," meaning that the browser will only pass that cookie over an SSL-encrypted connection using HTTPS. Then, even if the Web site operator inadvertently makes part of the application available via HTTP instead of HTTPS, that part of the application won't be able to accept cookies. Of course, such restrictions might break the application, depending on the functionality that relies on the cookies. Still, having the application break is often better than having cookies containing sensitive information sent across the Internet in clear text.
Next, application developers should mark the domain for which a cookie is valid, and they should mark it as narrowly as possible. Browsers will only pass cookies back to servers in the domain for which they are defined. Consider the example of a developer in an educational institution called MySchool, with a domain name of myschool.edu. The cookies for a school's Web application should not be defined as passable to every Web site on .edu. That would be a big risk, as every other school with an .edu domain would have a shot at collecting these cookies. Instead, the cookie should be limited to myschool.edu, at least. Or, the developer might want to further limit where they will be sent, writing the application so that it sets cookies just for server1.myschool.edu.
Further, the Web application should encrypt the cookie information before sending it to the browser. It should then decrypt the data at the server when it comes back. Don't just rely on SSL to encrypt the cookie. SSL protects the information while it is in transit, but not while it is sitting in the browser. Add another layer of encryption by having the server encrypt the cookie before sending it back to the browser. In the vast majority of applications, users don't need to see the contents of cookies. They are stored on the browser merely for future reference, and code running on the server can decrypt them.
Finally, Web developers should enable their code to expire cookies within a reasonable timeframe. For session-credential cookies, the timeframe maybe small, possibly only 10 minutes or so. After a few minutes of non-use of the application, the user will have to log in again. While re-prompting the user is a small nuisance, it significantly increases the security of the application.
More information:
See which hacker tools work in tandem over Wi-Fi to sniff out URLS and cookies.
Expert Joel Dubin explains why compromised Java scripts mean bad news for your cookie data.
|
