I previously chronicled my adventures with a hotel’s wifi system and how their less than secure data management allowed for those with the right tools and technique to affect the cost of their service. Between writing up that story and subsequent conversations, I felt that I would cover some good programming practices in relation to programming.
The first step is to keep secure data secure. In the example of the a purchase, it’s important to manage sensitive data on the server side. Things like prices of objects should be displayed for the user, but it needs to be kept away from where they can alter it. It shouldn’t be in a form field, including hidden ones, but on the server, regardless of whether the price is hard coded or stored in a database, depending on the project and items for sale. If you want users to affect pricing, do it through a coupon code or some other controlled means.
Once your data is in the right places, be sure to check the data that you receive from the user. Text fields need to be monitored for proper data. Usernames should be limited to specific characters, email addresses should be checked for format and characters, numeric fields should be checked for anything that isn’t a number, and other fields should be checked appropriately. The fields should also be checked that they do have data if the fields are mandatory. With a little searching, you can find the regular expressions that others have written to do it and see how it can be written easily.
When checking your data, be sure to do it on both the front and back ends. By checking on the browser with javascript, it will save processing on the server and be less burden on your system. In case the user turns off javascript, the same processing should be done on the server to check the fields. The redundancy may take longer in the development phase, but the long term benefits when the site is live make the initial costs worth it.
When receiving password fields from a user, never store them in plaintext. Passwords should be impossible to read and even harder to figure out. When receiving password fields, I don’t check for any characters, instead I allow anything and everything but encrypt it. When encrypting a password, it’s also important to “salt” the password. When Gawker was recently hacked, the passwords were then pushed against a library of other passwords to guess them. By putting a set of characters before, after or both before encrypting, it makes it harder to crack. By adding characters then using encryption like md5, it’s much harder to crack passwords.
When storing the data received from the form, be sure to encode it before putting it in a database. One of the most common attacks on a website is called an injection attack. Without going too in depth here, it allows a user to put bad data in a database query by using quotes to alter the sql query. I avoid this by url encoding any data received. Url encoding changes quotes and other characters to number combinations that can be displayed in a webpage but won’t affect your database, since things like names can have single quotes.
There are always more things you can do to secure your website, but this is a basic overview of things to do when creating and handling a web form. If there are things I should have included but didn’t, or you have more techniques you use, please let me know below.
