Authentication (Greek: αυθεντικός = real or genuine, from 'authentes' = author ) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying her identity. Authentication depends upon one or more authentication factors. In computer security, authentication is the process of attempting to verify the digital identity of the sender of a communication. A common example of such a process is the logon process.
Testing the authentication schema means understanding how the authentication process works and us- ing that information to circumvent the authentication mechanism.
Credentials transport over an encrypted channel (EFF-AT-001)
Here, the tester will just try to understand if the data that users put into the web form, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not.
Testing for user enumeration (EFF-AT-002)
The scope of this test is to verify if it is possible to collect a set of valid users by interacting with the au- thentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.
Testing for Guessable (Dictionary) User Account (EFF-AT-003)
Here we test if there are default user accounts or guessable username/password combinations (diction- ary testing)
EFF Application Penetration Testing Page 57 of 133
When a dictionary type attack fails, a tester can attempt to use brute force methods to gain authentica- tion. Brute force testing is not easy to accomplish for testers because of the time required and the possi- ble lockout of the tester.
Testing for bypassing authentication schema (EFF-AT-005)
Other passive testing methods attempt to bypass the authentication schema by recognizing that not all of the application's resources are adequately protected. The tester can access these resources without authentication.
Testing for vulnerable remember password and pwd reset (EFF-AT-006)
Here we test how the application manages the process of "password forgotten". We also check whether the application allows the user to store the password in the browser ("remember password" function).
Testing for Logout and Browser Cache Management (EFF-AT-007)
Here we check that the logout and caching functions are properly implemented.
Testing for CAPTCHA (EFF-AT-008)
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the gen- erated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.
Testing Multiple Factors Authentication (EFF-AT-009)
Multiple Factors Authentication means to test the following scenarios: One-time password (OTP) genera- tor tokens, Crypto devices like USB tokens or smart cards, equipped with X.509 certificates, Random OTP sent via SMS, Personal information that only the legitimate user is supposed to know [OUTOFWALLET].
Testing for Race Conditions (EFF-AT-010)
A race condition is a flaw that produces an unexpected result when timing of actions impact other ac- tions. An example may be seen on a multithreaded application where actions are being performed on the same data. Race conditions, by their very nature, are difficult to test for.
EFF Application Penetration Testing Page 58 of 133
2.3.1
Credentials transport over an encrypted channel (EFF-SEC -
AT-001)
SUMMARY
Testing for credentials transport means to verify that the user's authentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web applica- tion takes the appropriate security measures using a protocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that is transmitted and to ensure that user is being sent towards the desired site. Clearly, the fact that traffic is encrypted does not necessarily mean that it's completely safe. The security also depends on the encryption algorithm used and the robustness of the keys that the applica- tion is using, but this particular topic will not be addressed in this section. For a more detailed discussion on testing the safety of TLS/SSL channels you can refer to the chapter Testing for SSL-TLS. Here, the test- er will just try to understand if the data that users put into web forms, for example, in order to log into a web site, are transmitted using secure protocols that protect them from an attacker or not. To do this we will consider various examples.
DESCRIPTION OF THE ISSUE
Nowadays, the most common example of this issue is the login page of a web application. The tester should verify that user's credentials are transmitted via an encrypted channel. In order to log into a web site, usually, the user has to fill a simple form that transmits the inserted data with the POST method. What is less obvious is that this data can be passed using the HTTP protocol, that means in a non-secure way, or using HTTPS, which encrypts the data. To further complicate things, there is the possibility that the site has the login page accessible via HTTP (making us believe that the transmission is insecure), but then it actually sends data via HTTPS. This test is done to be sure that an attacker cannot retrieve sensi- tive information by simply sniffing the net with a sniffer tool.
2.3.2
Testing for user enumeration (EFF-SEC -AT-002)
SUMMARY
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password. Often, web appli- cations reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The infor- mation obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
DESCRIPTION OF THE ISSUE
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the
EFF Application Penetration Testing Page 59 of 133
information released from web application or web server, when we provide a valid username is different than when we use an invalid one.
In some cases, we receive a message that reveals if the provided credentials are wrong because an inva- lid username or an invalid password was used. Sometimes, we can enumerate the existing users by send- ing a username and an empty password.
2.3.3
Testing for Guessable (Dictionary) User Account (EFF-SEC -AT-
003)
SUMMARY
Today's web applications typically run on popular open source or commercial software that is installed on servers and requires configuration or customization by the server administrator. In addition, most of today's hardware appliances, i.e., network routers and database servers, offer web-based configuration or administrative interfaces.
Often these applications are not properly configured and the default credentials provided for initial au- thentication and configuration are never updated. In addition, it is typical to find generic accounts, left over from testing or administration, that use common usernames and passwords and are left enabled in the application and its infrastructure.
These default username and password combinations are widely known by penetration testers and mali- cious attackers, who can use them to gain access to various types of custom, open source, or commercial applications.
In addition, weak password policy enforcements seen in many applications allow users to sign up using easy to guess usernames and passwords, and may also not allow password changes to be undertaken. DESCRIPTION OF THE ISSUE
The root cause of this problem can be identified as:
• Inexperienced IT personnel, who are unaware of the importance of changing default passwords on installed infrastructure components.
• Programmers who leave backdoors to easily access and test their application and later forget to remove them.
• Application administrators and users that choose an easy username and password for themselves • Applications with built-in, non-removable default accounts with a pre-set username and pass-
word.
• Applications which leak information as to the validity of usernames during either authentication attempts, password resets, or account signup.
An additional problem stems from the use of blank passwords, which are simply the result of a lack of security awareness or a desire to simplify administration.
EFF Application Penetration Testing Page 60 of 133 • Burp Intruder: http://portswigger.net
• THC Hydra: http://www.thc.org/thc-hydra/
• Brutus http://www.hoobie.net/brutus/
2.3.4
Brute Force Testing (EFF-SEC -AT-004)
SUMMARY
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application. Therefore we are going to check different types of authentica- tion schema and the effectiveness of different brute-force attacks.
DESCRIPTION OF THE ISSUE
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the appli- cation behave differently upon the logon of different users. Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.
After a successful bruteforce attack, a malicious user could have access to:
• Confidential information / data;
o Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..
• Administration panels;
o These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..
• Availability of further attack vectors;
o Private sections of a web application could hide dangerous vulnerabilities and contain ad- vanced functionalities not available to public users.
RECOMMENDED TOOLS
• THC Hydra: http://www.thc.org/thc-hydra/ • John the Ripper: http://www.openwall.com/john/ • Brutus http://www.hoobie.net/brutus/
EFF Application Penetration Testing Page 61 of 133
2.3.5
Testing for bypassing authentication schema (EFF-SEC -AT-
005)
SUMMARY
While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security.
Negligence, ignorance or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions.
DESCRIPTION OF THE ISSUE
Problems related to Authentication Schema could be found at different stages of software development life cycle (SDLC), like design, development and deployment phase.
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more. Problems in the development phase are, for example, the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.
n addition, there are issues during application setup (installation and configuration activities) due to a lack in required technical skills, or due to poor documentation available.
RECOMMENDED TOOLS
• WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project • WebGoat: http://www.owasp.org/index.php/OWASP_WebGoat_Project
2.3.6
Testing for vulnerable remember password and pwd reset
(EFF-SEC -AT-006)
SUMMARY
Most web applications allow users to reset their password if they have forgotten it, usually by sending them a password reset email and/or by asking them to answer one or more "security questions". In this test we check that this function is properly implemented and that it does not introduce any flaw in the authentication scheme. We also check whether the application allows the user to store the password in the browser ("remember password" function).
EFF Application Penetration Testing Page 62 of 133
A great majority of web applications provide a way for users to recover (or reset) their password in case they have forgotten it. The exact procedure varies heavily among different applications, also depending on the required level of security, but the approach is always to use an alternate way of verifying the iden- tity of the user. One of the simplest (and most common) approaches is to ask the user for his/her e-mail address, and send the old password (or a new one) to that address. This scheme is based on the assump- tion that the user's email has not been compromised and that is secure enough for this goal.
Alternatively (or in addition to that), the application could ask the user to answer one or more "secret questions", which are usually chosen by the user among a set of possible ones. The security of this scheme lies in the ability to provide a way for someone to identify themselves to the system with an- swers to questions that are not easily answerable via personal information lookups. As an example, a very insecure question would be “your mother’s maiden name” since that is a piece of information that an attacker could find out without much effort. An example of a better question would be “favorite grade-school teacher” since this would be a much more difficult topic to research about a person whose identity may otherwise already be stolen.
Another common feature that applications use to provide users a convenience, is to cache the password locally in the browser (on the client machine) and having it 'pre-typed' in all subsequent accesses. While this feature can be perceived as extremely friendly for the average user, at the same time it introduces a flaw, as the user account becomes easily accessible to anyone that uses the same machine account.
2.3.7
Testing for Logout and Browser Cache Management (EFF-SEC -
AT-007)
SUMMARY
In this phase, we check that the logout function is properly implemented, and that it is not possible to “reuse” a session after logout. We also check that the application automatically logs out a user when that user has been idle for a certain amount of time, and that no sensitive data remains stored in the browser cache.
DESCRIPTION OF THE ISSUE
The end of a web session is usually triggered by one of the following two events:
• The user logs out
• The user remains idle for a certain amount of time and the application automatically logs him/her out
Both cases must be implemented carefully, in order to avoid introducing weaknesses that could be ex- ploited by an attacker to gain unauthorized access. More specifically, the logout function must ensure that all session tokens (e.g.: cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to forbid them to be used again.
EFF Application Penetration Testing Page 63 of 133
Note: the most important thing is for the application to invalidate the session on the server side. Gener- ally this means that the code must invoke the appropriate method, e.g. HttpSession.invalidate() in Java, Session.abandon() in .NET. Clearing the cookies from the browser is a nice touch, but is not strictly neces- sary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and virtually impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (that are stored on the victim’s PC), but in a variety of cases it might not be too difficult. The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g.: webmail, online bank account, ...): when the user has finished using the application and logs out, if the logout process is not properly enforced the following user could access the same ac- count, for instance by simply pressing the “back” button of the browser. Another scenario can result from a Cross Site Scripting vulnerability or a connection that is not 100% protected by SSL: a flawed log- out function would make stolen cookies useful for a much longer time, making life for the attacker much easier. The third test of this chapter is aimed to check that the application forbids the browser to cache sensitive data, which again would pose a danger to a user accessing the application from a public com- puter.
RECOMMENDED TOOLS
• Add N Edit Cookies (Firefox extension): https://addons.mozilla.org/firefox/573/
2.3.8
Testing for CAPTCHA (EFF-SEC -AT-008)
SUMMARY
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the gen- erated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.
DESCRIPTION OF THE ISSUE
Although CAPTCHA is not an authentication control, its use can be very efficient against:
• enumeration attacks (login, registration or password reset forms are often vulnerable to enumer- ation attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)
• automated sending of many GET/POST requests in a short time where it is undesirable (e.g.,