You come across testing of different web and mobile applications. It can either be a feature, automation testing or a blend of both. In the present scenario, where all business transactions and data transfer is done through internet, the data confidentiality, integrity and availability is of utmost importance. Hence, the application also, needs to be tested for security threats. Security testing is a branch of software testing that ensures proper and flawless working of an application. It focuses on various elements of security such as confidentiality, authenticity, integrity, vulnerability and continuity. The main areas that need to be focused upon in order to be considered for security testing are network security, system software security, client-side application security and server-side application security. In case of a scenario where a user logs out of the application, clicking on the back button and verifying whether the user is able to log in again, is a basic security test. During the development of Oracle business mobile and web application, we came across a couple of security issues which we have highlighted in this document. The threats include the data extraction during user log in and unauthorized data manipulation of the request and responses from the application. Manipulation of unauthorized access permissions in Android also, lead to attacks such as BEAST and SWEET32. Each topic mentioned in this document describes the problem in detail and also, mentions the corrective steps to reproduce the issue and the solution that needs to be applied in order to avoid the vulnerability. This document speaks about Burp Suite, APK tool, Wireshark and Postman. These are some of the tools which are used for security testing scenarios and one must possess strong knowledge about it.
Adversary converts the failure response into success response and tries to log into the application.
Log in with an invalid password into the application and track response using Burp Suite tool.
Intercept using Burp Suite. User is able to see the failure error in the response (viewable once you click on the Forward button).
Edit the failure response with success response.
Intercept using Burp Suite. User is able to see the failure error in the response (viewable once you click on the Forward button).
Session invalidated as token expires and user gets logged out of the application.
This security breach is possible as the application does not implement proper mapping of the user to the corresponding accessibility privilege. The application should: 1. Implement server-side mapping of the user to the respective accessibility. 2. Implement strong session management. 3. Log the user out if parameters are tampered at any time.
For an unsecure application, attackers can easily access/change the parameter exchange between client and server. By changing one of the parameters, for example, ‘username’ adversary will be able to access the application as a different user.
Log into the application using the credential ’anooprv’.
Turn on the intercept and catch the request using a tool (Burp Suite).
Copy the details, send it to repeater and change the user name parameter to ‘sushil jain’.
Tap on the ’Go’ button and check whether the response is returned.
User is getting the response even after changing one of the parameters like ‘username’ for the same session and the application gets logged in.
1. Implement proper mapping of user to their respective roles. 2. Hide all the sensitive information. 3. Session management should be implemented.
This vulnerability is categorized under privilege escalation. There are two types of privilege escalation: vertical and horizontal. This type of security exploit is possible when the proper mapping of users to their accessibility privilege is not done.
• Vertical privilege escalation occurs when an attacker tries to gain higher privileges with regard to the resources that are protected at any specific level, for example, a user with normal privileges with an application trying to gain the admin access.
• Horizontal privilege escalation occurs when an attacker tries to gain same privileges which he already possesses, but takes the identity of another user with the same set of privileges. For example, someone gaining access to another person’s online bank account.
Install the Burp Suite tool in your machine and configure proxy for the browser in which you are opening the application.
Turn the intercept on Burp Suite and log into the application through browser using any valid user. The URL will be intercepted at Burp Suite.
Modify the parameter username from the ‘logged in’ user to any other valid user for application and then switch the intercept off as given below. If modified to any user at the same privilege level, it will be a horizontal privilege escalation. Below example depicts the same.
You are navigated to the modified user in browser as shown below.
1. Implement server side mapping and the resources applicable to different privilege levels should be restricted to that level only.
2. Implement strong session management so that the user is forced to logout if any parameter manipulation or tampering occurs.
Authentication is a process that ensures and confirms identity of a user. In some applications, authentication is not enabled and it is easy for the attacker to get the sensitive information. An adversary can directly type the URL in the address bar of the browser and sensitive information can be accessed without any authentication. A valid user login into the application is not necessary to get the sensitive information.
Log into the application with Username: ‘ANOOPRV’ and Password: ’1234’.
Copy the login request URL and log out from the application.
Launch Postman tool and enter the copied request URL in Postman tool.
Enter the request parameters and send the request in Postman without authentication.
Verify the response of the corresponding URL.
URL should never contain sensitive or important information. Sensitive content should not be provided to the user without authentication and the following solutions can be implemented in the application. 1. Session management - The application should check for a valid user login and verify whether the user is authorized to access the document being requested.
2. File path protection - This method allows the documents to be located in a non-publicly accessible folder and the document path is not displayed to the end user.
This is a Brute force attack which is tried against user accounts. In Brute force attack, the attacker systematically, checks all the combination of username and passwords with the intention of eventually, logging into the application. There are many tools available for Brute force password cracking attacks such as Aircrack-ng, John the Ripper, Rainbow Crack etc.
Open the application.
Enter valid username and invalid password in the respective fields.
Select the Login button. The application displays an error message, “The username or password you have entered is not correct.”
Repeat step 2 and 3 for five times.
Enter valid username and password in the respective fields.
Select the Login button. The verified user is able to log in.
The user should not be allowed to log into the application after a particular number of invalid login attempts.
1. Lock the user account on a temporary basis for some time after approximately 5 invalid login attempts.
2. Implement CAPTCHA mechanism on the login screen. A CAPTCHA (an acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart”) is a type of challenge-response test used in computing to determine whether the user is human or not.
At present strong passwords are not mandatory for various applications. This allows hackers to easily access the application by guessing or by other methods. In order to provide an additional layer of security, it is essential to use OTP or other login security mechanism.
Deploy multi-factor authentication mechanism like fingerprint scan, OTP generation, physical token etc.
If the application does not have a session expiration time or if the session timeout period is too long then the attacker can access the sessions and get the information.
Launch the application with a valid user name and password.
Do not perform any changes on the application (after 30 minutes have passed).
It was observed that if the session is not getting terminated, the attacker can easily get access to the application.
Add session expiration time for the inactive period. Normally 30 minutes is the session expiration period.
Step 1 – Launch the app and log in with valid username and password.
Step 2 – Do not perform any changes on the application (after 30 minutes have passed).
Step 3 – User will get logged out.
The Inter Application Communication model (IAC) in Android is an inter-process communication or message passing system through which an app can utilize the functionalities of another app. For example, an app can send a message to a navigation app to display location. The below snippet from Android manifest shows that a broadcast receiver is exported explicitly leaving it accessible for any other applications.
Decompile the Android manifest file using ‘apktool’ and then open in notepad++ editor. A broadcast receiver is found in the xml file as highlighted below.
Do not use IPC as it can be accessed by all third-party applications on the device. Set the attribute to [exported= “false”]. This implies that the receiver is intended only for application’s internal use or it defines signature protection level permission in Android manifest file as given below.
A session token is assigned to the ‘logged in’ user, while logging into the application. Using this, session token user’s session is identified until logout. This session token should be properly invalidated when the user logs out from the application or else any adversary can hijack the user’s session using this session token.
Launch and log into the application using valid credentials.
Access any page and capture the request using “Burp” tool.
Send the request to repeater.
Log out from the application.
Go to repeater and select “Go “button and verify server response with the requested page.
The session should be invalidated once the user logs out of the application. Also, the session should be invalidated after a certain period of time.
The session id is a way to track whether the authenticated user identities are specific to any applications and are maintained at server side. Sometimes, the session remains active if the application is closed without logging out or when a mobile application goes on in the background. Therefore, if any adversary gets unauthorized access to the phone, it can perform malicious operations.
Log into application and navigate to any page.
Close the application without logging out.
Try to open the same URL again in the browser (if it is a mobile application, after the application is put into background, bring it back to foreground).
The session remains active and user can see the information in page.
1. Ensure that the session is invalidated or made inactive as soon as the user logs out of the application at server side.
2. Explicitly inactivate the session and do not wait for garbage collector or cookie expiration.
3. If it is a mobile app, do not allow it to run in the background. Forcefully, log out of the application when moved to background.
Below is an Android code snippet example.
For iOS, this is done by including app delegate ‘applicationdidenterbackground ‘to forcefully, terminate the user session at server.
An application with weak password policy is susceptible to attack. The major form of attack that can occur is password guessing. Users will give their own name, username, address, phone number, hobbies, pet’s name etc. as their password so that can be easily remembered. If the intruder has access to the server and executes the Finger utility command then he/she would be able to retrieve all the information of the users in the server. This command can be executed from Command prompt. The below screenshot shows how the password is viewable in the request and you can arrive at the conclusion that the password is same as the username and is a weak one.
Only the admin must have access to execute the Finger command in the server and by default avoid executing the command. Implement a strong password which takes into account the below mentioned criteria.
1. Password must have a minimum of 8 characters.
2. Password must not contain any personal information.
3. Must be different from the last passwords provided in the system. Enforce password history logic.
4. Words must not be spelled completely.
5. Password must contain characters from the four primary categories, including, uppercase and lowercase letters, numbers, and special characters.
Some Application allows the concurrent user logins for same account. The user can have the multiple session active at the same time from different browsers or machines. If the user needs to open the account in different browsers or different machines, you need to implement the concurrency in authentication. The concurrency in authentication has to be application specific. The issue with the concurrent authentication is that the logged in user is not aware of his /her account being accessed by others.
Consider online SBI application, log in with proper username and password.
Again, log into the account from a different browser or machine.
Concurrent logins should not be allowed.
The application layer is always the hardest to defend against security threat. The vulnerabilities which are present here usually depend on the input that is being given by the user. This layer is also the most accessible one and the most exposed to the outside world. Hence we would always need to give utmost importance to the authentication part of an application and prevent malicious attacks. The case study covers only a part of the attacks that can happen to the applications authentication.