Tip

How to avoid authentication bypass attacks

Passwords and other authentication methods may not be protecting your data. A good security system evaluates every access request and, based on the user ID and access policy, either grants or denies access. An attack known as authentication bypass allows hackers to avoid such authenticity checks or, in some cases, the entire security subsystem. Most attacks occur on Web sites and can happen due to errors in the design or implementation of a system. There are many forms of authentication bypass attacks but almost all are avoidable.

The 'root' cause
Systems vulnerable to authentication bypass usually exhibit one of two problems: a failure to enumerate and enforce the access policy or a weak authentication system that allows a valid identity to be forged. In the former, either the Web access control system does not have the full set of URIs that enumerate the application or Web site under attack, or the access control system does not extend to the section of the site that needs protection.

For example, in the root folder of a new protected Web application, there are shared files that both protected and unprotected applications are using. The root folder also contains database connection scripts or other files that have sensitive information. An authentication bypass attack targets files that are in use by the protected application. The attacker looks to the unprotected files for information about the system and formulates a strategy to bypass the authentication

Requires Free Membership to View

system. Many default application and Web server software comes with these unprotected default folders or applications.

Furthermore, administrators often fail to include shared resource directories or files as part of the security policy. As Web servers grow with new content, applications and folders, so does the risk of leaking information that is useful for attacks.

The protected site's folders may also lack protection throughout their structure. For example, the application's main folder is protected, but subsequent folders are unprotected.

Authentication issues
Learning Guide: Authentication & authorization

Attacks illustrate need for stronger authentication 

Banking on multifactor authentication

These attacks can be averted by creating a simple spreadsheet information management model (IMM). In one column, list all folders and objects. List the permissions, security policy and permissible users with permission to access it in another. Then test each object from a new Web session to ensure access without proper session tokens is denied. Most engineers do not perform such analysis and testing of their systems prior to release and therefore accidentally leave data or applications open to attack.

Direct attacks
Another flavor of authentication bypass involves direct attacks on the authentication and authorization systems. Many Web sites use scripts and back-end databases to make authentication and authorization decisions. Unfortunately, the design and implementation of these systems is faulty. Some Web form-based systems do the credential checking in the client side Web browser scripts or through parameters posted through the Web browser. An attack against these systems usually involves manipulation of values contained in the Web forms or in the parameters posted to the server. Some attacks are as simple as posting basic true or false values to the Web server.

For example, /webapps/login?validUser=yes&isAutheticated=yes can be manually entered into the browser in an attempt to bypass the application server's authentication mechanism.

Avoid this type of weakness by not exposing the authentication state in URLs or in client-side scripts.

Feeding forays
More sophisticated attacks involve the direct feeding of SQL and other commands to the Web server software or database. Thus, an attacker tries to access a valid user session. After successfully authenticating a user, many Web-based applications give the user a cookie or token to present to the application for every access attempt. The token is often associated with a server side session ID or, in some cases, the cookie is the session ID. The applications do simple logic operations to determine if the session ID or token is valid, or in the list of known sessions.

This can be prevented with strongly encrypted cookies or random session IDs, which make forging much more difficult. Also, validating all user input on the server side can prevent hostile attempts at accessing a session from succeeding.

Impersonation infiltration
More advanced attacks aim to bypass authentication systems by stealing either valid session IDs or cookies. An attacker tries to replay these cookies or session IDs to impersonate a valid user. Many mistakenly consider these attacks man-in-the-middle or session hijacking attacks. However, replaying a cookie or session ID is an authentication bypass attack because it bypasses the subsystems that mediate access to the application, making direct application access possible. To avert this attack, send all session and cookie data over an encrypted channel.

About the author:
George Wrenn, CISSP, ISSEP, is a technical editor for our sister publication Information Security magazine and a security director at a financial services firm. He's also a graduate fellow at the Massachusetts Institute of Technology.

This tip originally appeared on SearchSecurity.com

This was first published in December 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.