The use of 128-bit SSL encryption can thwart these attacks and is strongly recommended for all web sites that use Basic and Digest authentication.
To protect against replay attacks, the Digest nonce could be built from information that is difficult to spoof, such as a digest of the client IP address and a timestamp.
Forms-based Authentication Attacks
In contrast to the mechanisms we’ve discussed to this point, Forms-based authentication does not rely on features supported by the basic web protocols like HTTP (such as Basic or Digest authentication). It is a highly customizable authentication mechanism that uses a form, usually composed of HTML with FORM and INPUT tags delineating input fields, for users to enter their username and password. After the user credentials are sent via HTTP or HTTPS, they are then evaluated by some server-side logic and, if valid, some sort of unique token of sufficient length, complexity, and randomness is returned to the client for use in subsequent requests. Because of its highly customizable and flexible nature, Forms-based authentication is probably the most popular authentication technique deployed on the Internet. However, since it doesn’t depend on a standardized HTTP authentication specification, there is no standardized way to perform Forms-based authentication.
A simple example of Forms-based authentication will now be presented to illustrate the basic principles on which it is based. While this example will be based on Microsoft ASP.NET Forms authentication because of its simplicity, we’ll note the key points that
are generic to all types of Forms authentication. Here’s the scenario: you have a single directory on a web server with a file, default.aspx, that requires Forms authentication before it can be accessed. In order to implement ASP.NET Forms authentication, two other files are needed: a web.config file in this directory (or at the application root) and a login form to take username/password input (call it login.aspx). The web.config file specifies which resources will be protected by Forms authentication, and it contains a list of usernames and passwords that can be queried to validate credentials entered by users in login.aspx. Of course, any source of username/password information could be used— for example, a SQL database. It is recommended that a salted hash of the password is stored instead of the original password to mitigate the risk of exposing the passwords and make dictionary-based attacks more difficult. Here’s what happens when someone requests default.aspx:
GET /default.aspx HTTP/1.0
Since the web.config file specifies that all resources in this directory require Forms authentication, the server responds with an HTTP 302 redirect to the login page, login .aspx:
HTTP/1.1 302 Found
Location: /login.aspx?ReturnUrl=%2fdefault.aspx
The client is now presented with the login.aspx form, shown in Figure 4-5.
This form contains a hidden field called “state,” and two visible fields called “txtUser” that takes the username input and “txtPassword” that takes the password input. These are all implemented using HTML INPUT tags. The user diligently enters his or her
username and password and clicks the Login button, which POSTs the form data (including hidden fields) back to the server:
POST /login.aspx?ReturnUrl=%2fDefault.aspx HTTP/1.0 STATE=gibberish&txtUser=test&txtPassword=test
ThePOST method should always be used instead of the GET verb for sending the username and password, although both verbs accomplish the same thing. The reason for preferring POST to GET is to prevent the insecure storage of authentication credentials at the client (in the browser history), at caching intermediary devices such as proxies, and at the remote application server since these systems will often cache or log HTTP GET
data for statistical or performance reasons. These commonplace mechanisms can lead to the inadvertent exposure of user authentication credentials stored in GET requests to unauthorized users.
Note that unless SSL is implemented, the credentials traverse the wire in cleartext, as shown here. The server receives the credential data and validates them against the username/password list in web.config (again, this could be any custom datastore). If the credentials match, then the server will return a “HTTP 302 Found with a Location” header redirecting the client back to the originally requested resource (default.aspx) with aSet-Cookie header containing the authentication token:
HTTP/1.1 302 Found Location: /Default.aspx
Set-Cookie: AuthCookie=45F68E1F33159A9158etc.; path=/ htmlheadtitleObject moved/title/headbody
Note that the cookie here is encrypted using 3DES, which is optionally specified in ASP.NET’s web.config file. Now the client re-requests the original resource, default.aspx, with the newly set authentication token (the cookie) automatically appended to the HTTP header:
GET /Default.aspx HTTP/1.0
Cookie: AuthCookie=45F68E1F33159A9158etc.
The server verifies the cookie is valid and then serves up the resource with an HTTP 200 OK message. All of the 301 and 302 redirects occur transparently in the background without notifying the end-user of the activity. End result: user requests resource, is challenged for username/password, and receives resource if he or she enters the correct credentials (or a custom error page if he or she doesn’t). The application may optionally provide a “Sign Out” button that deletes the cookie when the user clicks it. Or the cookie can be set to expire in a certain timeframe when it will no longer be considered valid by the server (such as inactivity or maximum session length timeouts).
Again, this example uses a specific end-to-end technology, ASP.NET FormsAuthentication, to demonstrate the basics of Forms authentication. Any other similar technology or combination of technologies could be employed to achieve the same result.
Like the other authentication technologies discussed thus far, Forms-based authentication is also subject to password-guessing attacks. We like to use Brutus (introduced earlier in this chapter) for attacking Forms-based authentication, primarily because of its Modify Sequence | Learn Form Settings feature. This feature allows the user to simply specify a URL to a login form, and Brutus automatically parses out the fields for username, password, and any other fields supported by the form (including hidden). Figure 4-6 shows the HTML form interpreter.
Brutus also allows you to specify what responses you expect from the login form upon successful authentication. This ability is important because of the highly customizable nature of Forms authentication, as it is common for sites to implement unique response pages for successful and unsuccessful logins. With the Brutus tool, you can customize password guessing to whatever responses the particular target site uses.
Forms-based authentication is also clearly vulnerable to eavesdropping and replay attacks if the authentication channel is not encrypted with HTTPS or other encryption protocols.
Figure 4-6
Brutus’ HTML form interpreter parses a login form, highlighting fi elds for subsequent attack.Forms-based authentication almost always uses session cookies to store an authentication token temporarily so a user accessing a web site does not have to repeatedly supply his or her authentication credentials with each request. A session cookie is stored only in memory, as opposed to a persistent cookie that is stored on the disk and persists across sessions. Cookies can sometimes be manipulated or stolen outright, and may disclose inappropriate information if they are not encrypted (note that ASP.NET was configured to 3DES-encrypt the cookie in our example). See Chapter 5 for more on attacking cookies.
There are two cookie attribute flags, secure and HTTPOnly, that are important when issuing session or persistent cookies containing sensitive information (ideally, sensitive information should never be persisted in a cookie, and if it needs to be, that information should always be encrypted). When a cookie is issued with the secure flag, client browsers that honor the secure attribute will never send that cookie over a non- HTTPS secured channel. The HTTPOnly flag was originally created by Microsoft, and it is a modest attempt to protect users from session hijacking and data exfiltration attacks targeting sensitive data in application cookies. Client browsers that support HTTPOnly
will not allow JavaScript to access data in the corresponding cookie even if that access would normally be permitted based on the same origin policy. HTTPOnly is meant as a failsafe to protect the session ID and other sensitive values from being easily exfiltrated as a result of a malicious script injection attack (e.g., XSS). However, once attackers have the ability to execute malicious script in a target application, they will have free reign to perform any action in that application in the security context of the victim user, regardless of whether the attacker can directly access the session cookie or not. Normally, this would be accomplished by creating a series of background asynchronous requests (XmlHttpRequest) to execute sensitive functionality. Although there is some debate in the security community as to the overall usefulness of this protective mechanism, developers are encouraged to use this feature, when possible, as an additional layer of defense in their applications. With that said, the priority of application developers should always be to first rid their applications of the input validation vulnerabilities that lead to malicious script injection attacks. More information regarding the secure and HTTPOnly
cookie attribute flags can be found in the “References & Further Reading” section at the end of this chapter.
Some application developers make the mistaken assumption that data hidden from users in the form of “hidden” HTML input fields are not visible to end-users. They may then shuffle sensitive authentication credentials or other data into these fields rather than relying on cookie-based session IDs to authenticate users for certain transactions. While not a very common occurrence, application security assessors should train themselves to pay close attention to the types of data being stored in hidden fields.
Bypassing SQL-backed Login Forms On web sites that perform Forms-based authentication with a SQL backend, SQL injection can be used to bypass authentication (see Chapter 6 for more specific details on the technique of SQL injection). Many web sites use databases to store passwords and use SQL to query the database to validate authentication
credentials. A typical SQL statement will look something like the following (this example has been wrapped across two lines due to page-width constraints):
SELECT * from AUTHENTICATIONTABLE WHERE Username = 'username input' AND Password = 'password input'
If input validation is not performed properly, injecting
Username' --
in the username field would change the SQL statement to this:
SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username' --AND Password = 'password input'
The dashes at the end of the SQL statement specify that the remainder of the SQL statement is a comment and should be ignored. The statement is equivalent to this:
SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username'
And voilà! The check for passwords is magically removed!
This is a generic attack that does not require much customization based on the web site, as do many of the other attacks for Forms-based authentication. We’ve seen tools in the underground hacker community that automate this attack.
To take the attack one level higher, SQL injection can be performed on the password field as well. Assuming the same SQL statement is used, using a password of
DUMMYPASSWORD' OR 1 = 1 –-
would have a SQL statement of the following (this example has been wrapped across two lines due to page-width constraints):
SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username' AND Password = 'DUMMYPASSWORD' OR 1 = 1 –- '
The addition of OR 1 = 1 at the end of the SQL statement would always evaluate as true, and authentication can once again be bypassed.
Many web authentication packages were found to be vulnerable to similar issues in mid-2001. The Apache mod_auth_mysql, oracle, pgsql, and pgsql_sys built SQL queries and did not check for single quotes (these vulnerabilities were described in a CERT advisory from the University of Stuttgart, Germany; see the “References & Further Reading” section at the end of this chapter for a link).
Bypassing LDAP-backed Login Forms Not all applications integrate the authentication component with a backend SQL database server. Many web applications, especially on corporate intranets, use servers based on the Lightweight Directory Access Protocol
(LDAP) to provide similar authentication capabilities. If insecurely coded, these applications may expose LDAP injection vulnerabilities that could be exploited to bypass authentication controls. While the exact syntax used to exploit these vulnerabilities is different from that of SQL injection, the underlying concept is identical. More information on LDAP injection attacks is available in Chapter 6 of this book and interested readers are encouraged to refer to that chapter for further information.
Bypassing XML-backed Login Forms Although far less common than SQL-backed and LDAP-backed authentication components, some applications rely on static XML files to store application user data and login credentials. Just as in the SQL and LDAP case, applications that fail to properly validate user-supplied credentials may expose a vulnerability that allows attackers to bypass normal authentication controls. The classic case of this is an application that uses the username supplied during authentication to construct an XPath query to query the appropriate record from the backend XML document. If the username is not properly validated for characters that have special meaning in XPath queries, then an attacker may be able to modify the query to return arbitrary records, regardless of whether a correct password is supplied. More concrete examples of XML and XPath injection can be found in Chapter 7.