In the dark ages before the rise of the Internet, application security had once been a comparatively minor concern in software development lifecycle. Most programs were completely internal to a company, and unavailable to public access through telephone or modem. A large portion of applications had no network connectivity whatsoever, and resided solely inside a user’s PC. In this environment, junior developers could rarely cause serious damage to the IT infrastructure. While a foolish mistake could delete an important table or database, these errors were relatively easy to fix through a restore operation, and security permissions helped make this a rare occurrence.
As software development has taken flight to the Internet, once-innocent mistakes have become deadly. Even small, difficult to detect programming errors can open vulnerabilities that enable full system compromise. Compounding the problem, even after a system is compromised, the detection of the intrusion and full scope of exposure is often not identified or analyzed until weeks or months after the initial event. Even preventative measures such as rigorous code review can result in errors, as evidenced by the recent Heartbleed vulnerability that made newspaper headlines. If high-security, peer-reviewed, open-source software can have vulnerabilities, how much more so for web-based systems developed fully or in-part by unseasoned programmers.
Out of the common website security vulnerabilities, improper cookie use ranks the most blatant. Cookies are a tool used by browsers to store information. One key consideration often disregarded by inexperienced developers is that these cookies are stored locally by the client, on the client’s hard disk. This means that end-users have the capability to actually change the content of those cookies. For instance, if shopping cart totals would be stored in cookies, customers would be able to modify the total amount of the order and give themselves a discount.
In addition to data mangling, cookie privacy is a serious concern. Cookies should never be used for storage of any sensitive or personally identifiable information such as social security numbers, passwords, or even names and dates of birth. Any content stored in a cookie can be read directly by other programs, or even malware and viruses.
The easiest solution to improper cookie use is conversion from cookies to session variables. Server-side sessions offer key-based data stores, isolated to the current client session. As soon as the client closes their browser, the session is reset. While the session object is an effective alternative to cookie use in existing systems, new systems will benefit more from a fully RESTtul interface, removing the entire concept of a session from the system and reducing application overhead.
Still, there are times when cookies can be used correctly. Cookies work well as cached authentication tokens, enabling a user’s login to be remembered for several days. If a system supports this functionality, it is vital that the actual password is never stored locally; instead, a time-limited authentication hash should be saved to disk. This hash should also be validated against an IP address or other locally identifiable information to prevent tampering or duplication.
Although cookies do have acceptable use cases, incorrect cookie-use could pose serious security risks for an application. A good policy is to entirely avoid cookie development by junior developers, and ensure careful, redundant review of work done by senior developers. Considering the potential damage and liability exposure a poorly implemented cookie might bring, cookie development is one system element that simply must be done right.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
who are “unseasoned programmers” – not enough spices?
Exactly, junior programmers often lack a certain je ne sais quoi – be it nutmeg, vanilla extract, or occasionally even a dash of ginger.