Security Testing for Web Applications - Secure Java: For Web Application Development - page 246

develop security-testing procedures for various use cases present in the application to design an
efective and comprehensive security test. For instance, let us explore a typical use case of a login
into a Web application and then explore the abuse case for the same.

11.2.2.1 Basic Use Case

he basic use case scenario is as follows:

◾

he user accesses the Web application, which presents him with a screen to log in. here are

ields of username and password.
he user enters username and password into the ields.

◾

◾ into the system. he system validates the user based on the username and password entered and logs the user

11.2.2.2 Alternative Flows

he alternatives to this use case scenario are as follows:

◾

If the user enters an invalid username, then the application displays an error and the user is

presented with the login page again.
If the user enters the right username but the wrong password, then the application displays

◾

an error and the user is presented with the login page again.
If the user enters the right username but the wrong password three times continuously, then

◾

the application displays an error that the user account is locked and that the user should reset
the password on his/her account by answering the password questions.

11.2.2.3 Threat Models

he basic threat scenario here is that the attacker wants to circumvent the access control mecha-
nism of the application to gain access to the resources available to a legitimate, logged-on user of
the application. Let us explore the various detailed threat scenarios (threat models) that may be
used to achieve this purpose, based on this particular use case.

◾ tion to gain access to the database of users and then log in as the user. he attacker might use
SQL injection vectors like 'value' OR '1'='1' to circumvent the access control system.
he attacker may use forced browsing to access the application's restricted pages by access-

he attacker may try to perform an SQL injection attack using the login ields of the applica-

◾

ing them directly (i.e., without having to authenticate to the application). For instance, the
attacker might try to directly access the page admin.jsp by forcefully browsing to the page.
he attacker may tamper with the authentication parameters submitted to the Web server, ◾

thereby allowing access to the application's resources. In several cases, applications verify
successful logins based on parameters sent to the server with a parameter like “authenti-
cated” and a value of 'Yes' or 'No'. hese parameters may be modiied by the attacker to a
'Yes' to login to the Web application.
he attacker may be able to tamper with the session identiiers to gain access to legitimate

◾

user sessions. Attackers may be able to guess nonsecure session identiiers like 0001 and
increment it to gain access to user sessions.