A Quick List on Application Security
I once saw a sign on the wall of a car repair shop: "Wisdom comes from experience. Experience comes from making mistakes." It struck me just how true that statement was-- one does loearn an aweful lot from one's mistakes. Here are some of the practices I've learned over the years.
- Ensure that all text and all files sent by the user—all—are safe for your system
- SQL-safe data: If user-defined text, such as that in URL variables, FORM variables, and even cookies, is used in SQL statements, make absolutely sure that it is either numeric or that it is wrapped in quotes so that it is treated as a string. Otherwise, users can effectively send SQL commands straight to your database.
- Uploading executables: If you let users upload files to a directory inside of the webroot, make sure that they can’t upload executables which might run on the server. You can enforce this by either refusing to upload executables, or by changing the web server settings so that it won’t run them. Better yet, keep user uploads outside of the webroot and retrieve them with a "proxy" page.
- If for any reason you are allowing the user to submit directory paths or filenames in a URL or FORM, make sure that the information they submit doesn’t give them access to any part of your filesystem outside of the web root. For instance, you need to remove all instances of ‘../’ from such user data. I've seen other sites do this when they want to distribute whitepapers, for instance-- they specify the full path of the whitepaper as a hidden field in the form you're submitting. If you modify the field, you could perhaps download any file you liked from their server.
- Ensure that all personalized SQL queries depend on variables the user can’t manipulate.
If you are querying the database to send personalized data back to a user, you might not think that the user can or will take advantage of the query. Yet if you are passing a user-defined variable (e.g. a URL or FORM variable) into the query, the user could very easily change that variable in an attempt to query the database for someone else’s information. Make sure that ID numbers in queries are passed from the application server so that they can’t be manipulated by users—or that the query depends on at least one user-uncontrolled variable. - Ensure that application error messages don’t give information about the filesystem or web server configuration
Many application servers give information about the server software and filesystem when an error is produced. This is meant for debugging during development, and it should not be displayed to users when the site is live. - Try to hide administrative backends with unusual URLs, and make sure passwords are very difficult to guess
Often times web sites are built with administrative backends, where the site managers can control the site’s content or business logic. These backends are a great convenience, but they need to be protected. First of all, make the URL to the backend hard to guess. Second, make absolutely sure that a username and difficult-to-guess password is required to access it. Third, encrypt the access to the backend with SSL.
