Small Change – Big Website Security Hole

I’ve taken over the management and custom programming of a fully custom, built-from-scratch online store created using C# and .NET, and I’ve been building modules for this store and updating it for about 2 years.

After the store was operating for a long time, the owner realized that the shopping cart contents would disappear if someone left the site for a while and then came back to it.  He rightly assumed this was not good for users.  By this time, he had moved on from the company that originally built the site and was using a new programmer he had found to make the changes he needed (and this was before I came along of course).  He asked the programmer to make it so that the cart wouldn’t go away and in fact would be around “forever” or until checkout.

The programmer looked and found that the cart information was accessed using an identification number and the cart was going away because this number was stored in a session variable.  The programmer changed the site so that it stored the identification number in a cookie instead.  Simple enough, right?

Normally, stores are designed so that all the user information is accessed using that user’s identification number.  Therefore, someone has to identify themselves by logging in before any such information is available.  This store however, for reasons that make sense if you understand how this store works, had to access information based on the cart identification number.  And since the cart identification number was stored in a session variable, the original team of programmers considered this to be safe.

Programmer number two had no idea.  In making the site accept the cart identification variable as a cookie, he had opened up a way for a hacker to mine the entire customer database – easily.  I think he knew that someone could edit their cookie and access another cart, but he certainly didn’t know the store used the cart to pull in customer information!

Secure web application programmers know to treat all input as suspicious and this includes get and post variables, querystring variables, AND COOKIES!  If you are taking over a programming project, then changing a session variable to a cookie, querystring or post variable, you better understand the added security implications of that change.

You should understand this when you give your estimate so that you leave yourself room to explore the ramifications of a change like this.  Be sure to explain to your client that changing something in an insecure way could leave them open to hackers.  Unfortunately, programming takes time and people are often interested only in seeing that the site performs as they wanted – they have no way to know whether it is secure or not.  It’s important that you communicate that issue to them so that they understand the risks.

I’m a freelance web designer and programmer in the Boulder, Colorado area.  Please contact me with website security questions or if you are interested in working together to make something great!

Leave a Reply