Tip

Securing Web apps against authenticated users

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

    Requires Free Membership to View

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.

MORE INFORMATION

Learn how to lock down Web applications in Lesson 3 of Web Security School

Avoid authentication bypass attacks

Defense tactics for SQL injection attacks

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.


This was first published in October 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.