Tom Mollerus' Weblog

I've just come back from an CommonSpot Advanced Developer's Training class, where some people expressed the thought that server-side validation wasn't required as long as you have sufficient client-side validation through JavaScript. Then this morning I read Mark Kruger's excellent (if rather unfortunate) example of why you should always implement server-side data validation in your applications. Always remember that users, whether friendly or malicious, can submit anything they please via form submissions, URL query strings, or even cookies.

Yesterday an issue came up at the office that I wanted to ask the rest of the community about: we had a person call in, identifying themselves as being from a large law firm, asking for the names of those people from her firm who were signed up for our services. My company offers web-based financial services by subscription, so it's not at all uncommon for us to have customers from financial and legal firms, and to get calls from them asking about their accounts. Sometimes we even have a relationship with one person at a company who doles out bulk-rate subscriptions for our services to their colleagues.

What was notable about this caller, however, was that we didn't have a prior relationship established with this person or company, and we really had no way of verifying that they were who they said they were. My colleague who was taking the call put this person on hold and asked me whether he should grant this person's request; my answer was to have him say that while he could tell the caller how many people from her company were signed up with us, we were not allowed to give her their names. We did offer to contact them on her behalf to ask them to get in touch with her.

These kinds of calls, while not frequent, are somewhat common. For instance, we get secretaries calling on behalf of busy lawyers, or the folks from the finance department who've noticed our company's name as a charge on the company credit card and want to know who placed it. I'm sure this happens to other web-based businesses as well. So my question to the rest of you is this: how do you handle requests for customer account information? Do you take any measures to verify that the caller's stated identity is authentic? If a third party calls and asks for information about other people, how do you handle it?

1. Ensure that all text and all files sent by the user—all—are safe for your system
   1. 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.
   2. 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.
   3. 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.
2. 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.
3. 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.
4. 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.

1. Ensure that databases and sensitive assets are stored outside of the web root
   Any file, including your database, which sits inside the web root can be downloaded by a user if they figure out the correct URL. Keep your database outside of the web root, and keep sensitive files outside as well. Most application servers provide methods for sensitive files outside of the web root to be served to authenticated users when appropriate.
2. Ensure that directory browsing is turned off and that default index pages are specified
   If directory browsing is turned on and the web server doesn’t recognize any of the files in a given directory as a default index page, the server will show a list of all of the files to any user. The server may even let the user navigate between directories.
3. Ensure that all of the latest patches have been applied to all software
   Make sure to constantly check for and apply patches and upgrades for the operating system, web server, database, and application server software. Some programs can do this automatically, such as Windows Update or the Red Hat Network for Linux; if that isn't available, set up a schedule with reminders as a part of your business processes.