security testing (auth.)

8/6/2019 Security Testing (Auth.)

1/16

AUTHENTICATION TESTING

AUTHENTICATION TESTING:

Authentication is the act of establishing or confirming something (or someone) asauthentic, that is that claims made by or about the thing are true. Authenticating anobject may mean confirming its provenance, whereas authenticating a person often

consists of verifying her identity. Authentication depends upon one or moreauthentication factors. Authentication is the process of attempting to verify thedigital identity of the sender of a communication. A common example of such aprocess is the logon process. Testing the authentication schema meansunderstanding how the authentication process works and using that information tocircumvent the authentication mechanism.

1. CREDENTIALS TRANSPORT OVER AN ENCRYPTED CHANNEL:

Summary:Testing for credentials transport means to verify that the user's authentication dataare transferred via an encrypted channel to avoid being intercepted by malicioususers.

The analysis focuses simply, if the data travels unencrypted from the web browser tothe server, or if the web application takes the appropriate security measures using aprotocol like HTTPS. The HTTPS protocol is built on TLS/SSL to encrypt the data that istransmitted and to ensure that user is being sent towards the desired site.we 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 protectthem from an attacker or not.

DescriptionWe should verify that user's credentials are transmitted via an encrypted channel. Inorder to log into a web site, usually, the user has to fill a simple form that transmitsthe inserted data with the POST method. What is less obvious is that this data can bepassed 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 thesite has the login page accessible via HTTP (making us believe that the transmissionis insecure), but then it actually sends data via HTTPS. This test is done to be surethat an attacker cannot retrieve sensitive.

Black Box Testing:In the following examples we will use Paros in order to capture packet headers and toinspect them.

1.1. Sending data with POST method through HTTP:

In this example we assume that the login page presents a form with fields User, Pass,and the Submit button to authenticate and give access to the application. If we lookat the header of our request with Paros.

Security Testing of Web Application


2/16


In this example the we can see that the POST sends the data to the pagehttp://192.168.2.9:7110/ventura/af/home.do simply using HTTP. So, in this case, dataare transmitted without encryption and a malicious user could read our usernameand password by simply sniffing the net with a tool like Wireshark

1.2. Sending data with POST method through HTTPS:In this example we assume that our web application uses the HTTPS protocol toencrypt data we are sending In this case, we are trying to access the login page andto authenticate, the header of our POST request.

Hyper Text Transfer Protocol secure (HTTPS) is a secure version of the Hyper TextTransfer Protocol (http). HTTPS allows ecommerce transaction, such as onlinebanking.

We have not implemented HTTPS in the Bangalore centre, so proxy tool (Paros) cannot

Intercept the request.

1.3. Sending data with POST method via HTTPS on a page reachable via HTTP:

In this example we have a web page reachable via HTTP and that then only datasent from the authentication form are shipped via HTTPS. This means that our data istransmitted in a secure way through encryption. This situation occurs, for example,when we are on a portal of a big company that offers various information and



3/16


services publicly available, without identification, but which has also a private sectionaccessible from the home page through a login.

(Screen shorts not available because https is not implemented.)

1.4. Sending data with GET method through HTTPS:

In this last example, we test that the application transfers data using the GETmethod. This method should never be used in a form that transmits sensitive datasuch as username and password, because they are displayed in clear in the URL andthis entails a whole set of security issues.

(Screen shorts not available because https is not implemented.)

Remark:Talk with the developers and try to understand if they are aware of differencesbetween HTTP and HTTPS protocols and why they should use the HTTPS for sensitiveinformation transmissions.Check with them if HTTPS is used in every sensitive transmission, like those in loginpages, to prevent unauthorized users to read the data.

2. TESTING FOR USER ENUMERATION:

Summary:In this scenario we test 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 beuseful for the brute force testing, in which we verify if, given a valid username, it ispossible to find the corresponding password. Often, web applications reveal when ausername exists on system, either as a consequence of a misconfiguration or as adesign decision. For example, sometimes, when we submit wrong credentials, wereceive a message that states that either the username is present on the system orthe provided password is wrong. The information obtained can be used by anattacker to gain a list of users on system.

Description:We be should interact with the authentication mechanism of the application tounderstand if sending particular requests causes the application to answer indifferent manners. This issue exists because the information released from webapplication or web server, when we provide a valid username is different than whenwe use an invalid one. In other cases, we receive a message that reveals if theprovided credentials are wrong because an invalid username or anInvalid password was used. Sometimes, we can enumerate the existing users bysending a username and an empty password.

Black Box Testing:

In a black box testing, we know nothing about the specific application, username,application logic and error messages on login page, or password recovery facilities. Ifthe application is vulnerable, we receive a response message that reveals, directly orindirectly, some information useful for enumerating users.

HTTP Response message:

In this example we can verify that the application answers in the same manner forevery client request that produces a failed authentication.



4/16


Testing for Valid user/right password:

Record the server answer when you submit a valid userID and valid password

Result Expected:Using Paros, notice the information retrieved from this successful authentication(HTTP 200 Response, length of the response).

Testing for valid user/wrong password:

We are tried to insert a valid userID and a wrong password and record the errormessage generated by the application.



5/16


6/16


Result Expected:

The application should respond with the same error message and length to thedifferent wrong requests.

Remark: If we notice that the responses are not the same, we should investigateand find out the key that creates a difference between the 2 responses.For example:

Client request: Valid user/wrong password --> Server answer: The passwordis not correct'

Client request: Wrong user/wrong password --> Server answer: User notrecognized'

The above responses let the user understand that for the first request we have avalid user name. So we can interact with the application requesting a set of possible

userIDs and observing the answer. Looking at the second server response, weunderstand in the same way that we don't hold a valid username. So we can interactin the same manner and create a list of valid userID looking at the server answers.

3. DEFAULT OR GUESSABLE:

Summary:In this scenario we are test default username and password combinations, and weak

password policy enforcements seen in many applications allow users to sign up using



7/16


easy to guess usernames and passwords, and may also not allow password changesto be undertaken.

Description:The root cause of this problem can be identified as:

Inexperienced IT personnel, who are unaware of the importance of changing defaultpasswords on installed infrastructure components.

o Programmers who leave backdoors to easily access and test their

application and later forget to remove them.

o Application administrators and users that choose an easy username and

password for themselves.

o Applications with built-in, non-removable default accounts with a pre-set

username and password.

o Applications which leak information as to the validity of usernames during

authentication attempts, password resets, or account signup.

o Use of blank passwords, which are simply the result of a lack of security

awareness

Black box Testing:

Here we tried the following usernames - "admin", "administrator", "root", "system","guest", "operator", or "super". These are common among system administrators andare often used. Additionally you could try "qa", "test", "test1","testing", and similarnames. Attempt any combination of the above in both the username and thepassword fields. If the application is vulnerable to username enumeration and yousuccessfully manage to identify any of the above usernames, attempt passwords ina similar manner. In addition try an empty password or one of the following"password", "pass123", "password123", "admin", or "guest" with the above accountsor any other enumerated accounts. Further permutations of the above can also beattempted. If these passwords fail, it may be worth using a common username andpassword list and attempting multiple requests against the application.

o Application administrative users are often named after the application or

organization. This means if you are testing an application named "Obscurity",we can try using obscurity/obscurity or any other similar combination as theusername and password.

o When we are performing a test for a customer, attempt using names of

contacts we have received as usernames with any common passwords.

o Viewing the User Registration page may help determine the expected format

and length of the application usernames and passwords. If a user registrationpage does not exist, determine if the organization uses a standard namingconvention for user names such as their email address or the name before the"@" in the email.

o We can attempt using all the above usernames with blank passwords.

o Review the page source and javascript either through a proxy or by viewing

the source. Look for any references to users and passwords in the source. For



8/16


example "If username='admin' then starturl=/admin.home.do else/index.home.do" (for a successful login vs. a failed login). Also, if you have avalid account, then login and view every request and response for a validlogin vs. an invalid login, such as additional hidden parameters, interestingGET request (login=yes), etc.

o

Look for account names and passwords written in comments in the sourcecode. Also look in backup directories, etc for source code that may containcomments of interest.

o Here we try to extrapolate from the application how usernames are

generated. For example, can a user create their own username or does thesystem create an account for the user based on some personal information ora predictable sequence? If the application does create its own accounts in apredictable sequence, such as user7811, try all possible accounts recursively.If we can identify a different response from the application when using a validusername and a wrong password, then we can try a brute force attack on thevalid username (or quickly try any of the identified common passwords aboveor in the reference section).

o If the application creates its own passwords for new users, whether or not the

username is created by the application or by the user, then try to determine ifthe password is predictable. Try to create many new accounts in quicksuccession to compare and determine if the passwords are predictable. Ifpredictable, then try to correlate these with the usernames, or anyenumerated accounts, and use them as a basis for a brute force attack.

Result Expected:

Successful authentication to the application or system being tested.

4. TESTING FOR BRUTE FORCE:

Summary:Brute-forcing consists of systematically enumerating all possible candidates for thesolution and checking whether each candidate satisfies the problem's statement. Inweb application testing, the problem we are going to face with the most is very oftenconnected with the need of having a valid user account to access the inner part ofthe application. Therefore we are going to check different types of authenticationschema and the effectiveness of different brute-force attacks.

Description:

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 weusually find a combination of user ID and password. Therefore it's possible to carryout an attack to retrieve a valid user account and password, by trying to enumeratemany (ex. dictionary attack) or the whole space of possible candidates.



9/16


After a successful bruteforce attack, a malicious user could have access to:

o Confidential information / data

Private sections of a web application, could disclose confidentialdocuments, user's profile data, financial status, bank details, user'srelationships, etc..

Administration panels

These sections are used by webmasters to manage (modify, delete, add) webapplication content, manage user provisioning, assign different privileges tothe users, etc..

Availability of further attack vectors

Private sections of a web application could hide dangerous vulnerabilities andcontain advanced functionalities not available to public users.

Black Box Testing:

Partial knowledge of password and account details:

In this example we get some information about length or password (account)structure, it's possible to perform a bruteforce attack with a higher probability ofsuccess. In fact, by limiting the number of characters and defining the passwordlength, the total number of password values significantly decreases.



10/16


5. TESTING FOR BYPASSING AUTHENTICATION SCHEMA:

Summary:Negligence, ignorance or simple understatement of security threats often result inauthentication schemes that can be bypassed by simply skipping the login page anddirectly calling an internal page that is supposed to be accessed only afterauthentication has been performed. It is often possible to bypass authenticationmeasures by tampering with requests and tricking theapplication into thinking that we're already authenticated. This can be accomplishedeither by modifying the given URL parameter or by manipulating the form or bycounterfeiting sessions.

Description:As we know Authentication Schema could be found at different stages of softwaredevelopment life cycle (SDLC), like design, development and deployment phase.Examples of design errors include a wrong definition of application parts to beprotected, the choice of not applying strong encryption protocols for securingauthentication 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 thespecific language. And, there are issues during application setup (installation andconfiguration activities) due to a lack in required technical skills, or due to poordocumentation available.

Black box Testing:



11/16


Here we have following methods to bypass the authentication schema in use by aweb application.

o Direct page request

o Parameter Modification

o Session ID Prediction

Direct page request:In this Example If a web application implements access control only on the login

page, the authentication schema could be bypassed. For example, if a user directlyrequests a different page via forced browsing, that page may not check thecredentials of the user before granting access. Attempt to directly access a protectedpage through the address bar in your browser to test using this method.

Parameter ModificationAnother problem related to authentication design is when the application verifies a

successful login based on fixed value parameters. A user could modify theseparameters to gain access to the protected areas without providing valid credentials.

Session ID PredictionMany web applications manage authentication using session identification values(SESSION ID). Therefore, if Session ID generation is predictable, a malicious usercould be able to find a valid session ID and gain unauthorized access to theapplication, impersonating a previously authenticated user.



12/16


6. TESTING FOR VULNERABLE REMEMBERS PASSWORD AND PWD RESET:

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 properlyimplemented 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 thebrowser ("remember password" function).

Description:The application could ask the user to answer one or more "secret questions", whichare usually chosen by the user among a set of possible ones. The security of thisscheme lies in the ability to provide a way for someone to identify themselves to thesystem with answers to questions that are not easily answerable via personalinformation lookups. As an example, a very insecure question would be yourmothers maiden name since that is a piece of information that an attacker couldfind out without much effort.

Black Box Testing:In this example we test the Password Reset and Password Remember functionality

of an application.

Password Reset:

The first step is to check whether secret questions are used. Sending the password(or a password reset link) to the user email address without first asking for a secretquestion means relying 100% on the security of that email address, which is notsuitable if the application needs a high level of security.If secret question are used, the next step is to assess their strength.As a first point, how many questions need to be answered before the password canbe reset? The majority of applications only need the user to answer to one question,but some critical applications require the user to answer correctly to two or evenmore questions.

Are there multiple questions offered?o If so, try to pick a question which would have a public answer; for example,something Google would find with a simple queryo Always pick questions which have a factual answer such as a first school or otherfacts which can be looked upo Look for questions which have few possible options such as what make was yourfirst car; this question would present the attacker with a short-list of answers toguess at and based on statistics the attacker could rank answers from most to leastlikely

Determine how many guesses you have (if possible)o Does the password reset allow unlimited attempts?o Is there a lockout period after X incorrect answers? Keep in mind that a lockoutsystem can be a security problem in itself, as it can be exploited by an attacker tolaunch a Denial of Service against users.

Pick the appropriate question based on analysis from above point, and do research todetermine the most likely answers



13/16


o How does the password-reset tool (once a successful answer to a question is

found) behave?

o Does it allow immediate change of the password?o Does it display the old password?

o Does it email the password to some pre-defined email address?o The most insecure scenario here is if the password reset tool shows you thepassword; this gives the attacker the ability to log into the account, and unless theapplication provides information about the last login the victim would not know thathis/her account has been compromised.o A less insecure scenario is if the password reset tool forces the user to immediately

change his/her password. While not as stealthy as the first case, it allows the attackerto gain access and locks the real user out.

The best security is achieved if the password reset is done via an email to theaddress the user initially registered with, or some other email address; this forces theattacker to not only guess at which email account the password reset was sent to(unless the application tells that) but also to compromise that account in order totake control of the victims access to the application.

Password Remember:

The "remember my password" mechanism can be implemented with one of thefollowing methods:

o Allowing the "cache password" feature in web browsers. Although not directly

an application mechanism, this can and should be disabled.o Storing the password in a permanent cookie. The password must be

hashed/encrypted and not sent in cleartext

The password autocomplete should always be disabled, especially insensitive applications, since an attacker; if able to access the browser

cache, could easily obtain the password in cleartext.

To check the second implementation type, examine the cookie storedby the application. Verify the credentials are not stored in cleartext,but are hashed. Examine the hashing mechanism: if it appears acommon well-known one, check for its strength; in homegrown hashfunctions, attempt several usernames to check whether the hashfunction is easily guessable.

Verify that the credentials are only sent during the login phase, andnot sent together with every request to the application.

7. TESTING FOR LOGOUT AND BROWSER CACHE MANAGEMENT:

Summary:We Test that the logout function is properly implemented, and that it is not possible

to reuse a session after logout. We also test that the application automatically logsout a user when that user has been idle for a certain amount of time, and that nosensitive data remains stored in the browser cache.

Description:



14/16


The end of a web session is usually triggered by one of the following two events:

o The user logs out.

o The user remains idle for a certain amount of time and the application

automatically logs him/her out.

Black Box Testing:

In this example we need to test following point.

Logout Function:The first step is to test the presence of the logout function. To test that theapplication should have a logout button and that this button is present and wellvisible on all pages that require authentication. A logout button that is not clearlyvisible, or that is present only on certain pages, poses a security risk, as the usermight forget to use it at the end of his/her session.

The second step consists in checking what happens to the session tokens when thelogout function is invoked.

Implementation:

The first (and simplest) test at this point consists of logging out and then hitting the'back' button of the browser, to check whether we are still authenticated. If we are, itmeans that the logout function has been implemented insecurely, and that the logoutfunction does not destroy the session IDs.

Other applications might try to close the browser using JavaScript, but that again is asolution that relies on the client behavior, which is intrinsically less secure, since theclient browser could be configured to limit the execution of scripts (and in this case aconfiguration that had the goal of increasing security would end up decreasing it).

Cached pages:Logging out from an application obviously does not clear the browser cache of anysensitive information that might have been stored. We test that is to be performed is

to check that our application does not leak any critical data into the browser cache.In order to do that, we can use Paros and search through the server responses thatbelong to our session, checking that for every page that contains sensitiveinformation the server instructed the browser not to cacheany data.



15/16


8. TESTING FOR CAPTCHA:

Summary:CAPTCHA ("Completely Automated Public Turing test to tell Computers and HumansApart") is a type of challenge-response test used by many web applications to ensurethat the response is not generated by a computer.

Description:Although CAPTCHA is not an authentication control, its use can be very efficient

against:

o Enumeration attacks (login, registration or password reset forms are oftenvulnerable to enumeration attacks -without CAPTCHA the attacker can gainvalid usernames, phone numbers or any other sensitive information in a shorttime)

o automated sending of many GET/POST requests in a short time where it is

undesirable (e.g., SMS/MMS/email flooding), CAPTCHA provides a rate limitingfunction

o automated creation/using of the account that should be used only by humans

(e.g., creating web mail accounts, stop spamming)



16/16


o automated posting to blogs, forums and wikis, whether as a result of

commercial promotion, or harassment and vandalism

o any automated attacks that massively gain or misuse sensitive information

from the application.

Black Box Testing:

Use an intercepting fault injection proxy (Paros).o identify all parameters that are sent in addition to the decoded CAPTCHA

value from the client to the server (these parameters can contain encryptedor hashed values of decoded CAPTCHA and CAPTCHA ID number).

o try to send an old decoded CAPTCHA value with an old CAPTCHA ID (if the

application accepts them, it is vulnerable to replay attacks).

o try to send an old decoded CAPTCHA value with an old session ID (if the

application accepts them, it is vulnerable to replay attacks).


security testing (auth.)

Documents