On the face of it, authentication is conceptually among the simplest of all the security mechanisms employed within web applications. In the typical case, a user supplies her username and password, and the application must verify that these items are correct. If so, it lets the user in. If not, it does not.
Authentication also lies at the heart of an application’s protection against malicious attack. It is the front line of defense against unauthorized access, and if an attacker can defeat those defenses, they will often gain full control of the application’s functionality, and unrestricted access to the data held within it. Without robust authentication to rely upon, none of the other core security mechanisms can be effective.
In fact, despite its apparent simplicity, devising a secure authentication function is an extremely subtle business, and in real-world web applications authentication is very often the weakest link, which enables an attacker to gain unauthorized access. The authors have lost count of the number of applications that we have fundamentally compromised as a result of various defects in authentication logic.
This article will look in detail at the wide variety of design and implementation flaws that commonly afflict web applications. These typically arise because the application designers and developers fail to ask a simple question: What could an attacker achieve if he were to target our authentication mechanism? In the majority of cases, as soon as this question is asked in earnest of a particular application, a number of potential vulnerabilities materialize, any one of which may be sufficient to break the application.
Many of the most common authentication vulnerabilities are literally no-brainers. Anyone can type dictionary words into a login form in an attempt to guess valid passwords. In other cases, subtle defects may lurk deep within the application’s processing, which can only be uncovered and exploited after painstaking analysis of a complex multistage login mechanism.
Authentication Technologies
There is a wide range of different technologies available to web application developers when implementing authentication mechanisms:
■ HTML forms-based authentication.
■ Multi-factor mechanisms, such as those combining passwords and physical tokens.
■ Client SSL certificates and/or smartcards.
■ HTTP basic and digest authentication.
■ Windows-integrated authentication using NTLM or Kerberos.
■ Authentication services.
By far the most common authentication mechanism employed by web applications uses HTML forms to capture a username and password and submit these to the application. This mechanism accounts for well over 90% of applications you are likely to encounter on the Internet.
In more security-critical Internet applications, such as online banking, this basic mechanism is often expanded into multiple stages, requiring the user to submit additional credentials, such as PIN numbers or selected characters from a secret word. HTML forms are still typically used to capture relevant data.
In the most security-critical applications, such as private banking for high-worth individuals, it is common to encounter multi-factor mechanisms using physical tokens. These tokens typically produce a stream of one-time pass-
codes, or perform a challenge-response function based on input specified by the application. As the cost of this technology falls over time, it is likely that more applications will employ this kind of mechanism. However, many of these solutions do not actually address the threats for which they were devised — primarily phishing attacks and those employing client-side Trojans.
Some web applications employ client-side SSL certificates or cryptographic mechanisms implemented within smartcards. Because of the overhead of administering and distributing these items, they are typically used only in security-critical contexts where an application’s user base is small.
The HTTP-based authentication mechanisms (basic, digest, and Windows-integrated) are rarely used on the Internet, and are much more commonly encountered in intranet environments where an organization’s internal users gain access to corporate applications by supplying their normal network or domain credentials, which are processed by the application via one of these technologies.
Third-party authentication services such as Microsoft Passport are occasionally encountered, but at the present time have not been adopted on any significant scale.
Most of the vulnerabilities and attacks that arise in relation to authentication can be applied to any of the technologies mentioned. Because of its over-whelming dominance, we will describe each specific vulnerability and attack in the context of HTML forms-based authentication, and where relevant will point towards any specific differences and attack methodologies that are relevant to the other available technologies.
Design Flaws in Authentication Mechanisms
Authentication functionality is subject to more design weaknesses than any other security mechanism commonly employed in web applications. Even in the apparently simple, standard model where an application authenticates users based on their username and password, shortcomings in the design of this model can leave the application highly vulnerable to unauthorized access.
Bad Passwords
Many web applications employ no or minimal controls over the quality of users’ passwords. It is common to encounter applications that allow passwords that are:
■ Very short or blank
■ Common dictionary words or names
■ Set to the same as the username
■ Still set to a default value
Figure -1 shows an example of weak password quality rules. End users typically display little awareness of security issues. Hence, it is highly likely that an application that does not enforce strong password standards will contain a large number of user accounts with weak passwords set. These passwords can be easily guessed by an attacker, granting them unauthorized access to the application.
Figure -1: An application that enforces weak password quality rules
Brute-Forcible Login
Login functionality presents an open invitation for an attacker to try and guess usernames and passwords, and so gain unauthorized access to the application. If the application allows an attacker to make repeated login attempts with different passwords until the correct one is guessed, then it is highly vulnerable even to an amateur attacker who manually enters some common usernames and passwords into their browser. Values frequently encountered even in production systems include:
■ test
■ testuser
■ admin
■ administrator
■ demo
■ demouser
■ password
■ password1
■ password123
■ qwerty
■ test123
■ letmein
■ [organization’s name]
In this situation, any serious attacker will use automated techniques to attempt to guess passwords, based on lengthy lists of common values. Given today’s bandwidth and processing capabilities, it is possible to make thousands of login attempts per minute from a standard PC and DSL connection. Even the most robust passwords will be eventually broken in this scenario.
Verbose Failure Messages
A typical login form requires the user to enter two pieces of information (user-name and password), and some applications require several more (for example, date of birth, a memorable place, or a PIN number).
When a login attempt fails, you can of course infer that at least one piece of information was incorrect. However, if the application informs you as to which piece of information was invalid, you can exploit this behavior to considerably diminish the effectiveness of the login mechanism.
In the simplest case, where a login requires a username and password, an application might respond to a failed login attempt by indicating whether the reason for the failure was an unrecognized username or the wrong password, as illustrated in Figure-2.
Figure 6-3: Verbose login failure messages indicating when a valid username has been guessed.
In this instance, you can use an automated attack to iterate through a large list of common usernames to enumerate which of these are valid. Of course, usernames are not normally considered a secret (they are not masked during login, for instance). However, providing an easy means for an attacker to identify valid usernames increases the likelihood that they will compromise the application with a given level of time, skill, and effort. A list of enumerated usernames can be used as the basis for various subsequent attacks, including password guessing, attacks on user data or sessions, or social engineering.
In more complex login mechanisms, where an application requires the user to submit several pieces of information, or proceed through several stages, verbose failure messages or other discriminators can enable an attacker to target each stage of the login process in turn, increasing the likelihood that they will gain unauthorized access.
NEXT is..Vulnerable Transmission of Credentials………..,,,.,.,.,.,..