Although many Web-based application security vulnerabilities are product specific, many more are flaws in the design and use of an application -- not necessarily in the underlying product itself. For example, any code in a Flash SWF file is easily accessible and readable so if you include access information to another application in your script you have created a hole in your own security. One area where Web developers are often guilty of poor design is user authentication and the assumptions they make about authenticated users.
Most sites that require users to authenticate themselves rely on a username and password entered via a form. This is then checked against a database or list of users in order to either deny or allow access to the site's services, such as online banking, shopping, medical services, etc. I will come back to the problems of this approach to user authentication. But first, I want to look at how an authenticated user is handled. Many sites assume that a user can be trusted just because he or she has entered a username and password. Unfortunately, there is nothing to stop an "authenticated" user from trying to attack your Web application. Many developers seem to think that by using SSL or IPSec, their applications are protected from attacks like SQL injection or cross-site scripting. These protocols certainly play a role in data confidentiality but not in user access control. They only protect data in transit -- even if it is malicious.
There are two specific safeguards against authenticated users who have access to your Web applications: sanitizing any data used by the application and securing the application itself.
Your application should assume that all data has come from an untrusted source even if the user has been authenticated. You need therefore to add validation logic that constrains input to your scripts and data access routines. You should validate all input for type, length, format and range. You also need to clean it of any characters or strings that could possibly be used maliciously. The best way to filter data is with a default deny regular expression. Stripping quotes or putting backslashes in front of them is insufficient. The filter must be narrow and specific, allowing only the type of characters that you require. All data validation must be done on a trusted server or under control of your application. Your application should never rely on client-side data validation as it can be easily bypassed. Use it only to reduce round trips to the server and to improve the user experience.
The application itself needs to run under the least privileges necessary from an operating system perspective for it to function correctly with limited ability to access system resources. Users' privileges are often based on the privileges granted to your application's own login so ensure that any connection to a database or other resource is made by using a least-privileged account. By restricting all functionality that is not absolutely necessary to the application and restricting the user's privileges to only executing specific stored procedures you will help safeguard your application's interaction with other applications such as a database. If your application accesses a database, you should avoid the use of dynamically generated SQL in your code. By using parameterized queries and stored procedures you will avoid many types of SQL injection attacks. Finally, if there is system or database access failure, make sure you don't dump out the entire error message as this can provide useful information to an attacker.
Returning to the issue of client authentication, username and password as a means of authentication is becoming less reliable due to spyware. I recommend that your applications only request certain random characters from the user's password so that a keylogger cannot capture the entire password. If you are running applications with access to really sensitive data then you should use certificate-based client-side authentication. This means that your server can request that clients present their own digital certificates before an SSL session is established. With high-risk systems such as Internet banking it may be necessary to create your own in-house Public Key Infrastructure. With the sophistication of malware growing, hackers are trying to steal passwords and even certificates and private keys. To try and protect against this, users could be issued with smart cards or some other form of token on which to store their credentials. This has the added benefit of providing two-factor authentication, a far better option than a username and password.
About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.
