I recently performed OWASP testing on an application and wanted to share my experience. The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.
Before I talk about my project, here’s a brief description of security testing: It is a process intended to reveal flaws in the security mechanisms of an application that protect data and maintain functionality as intended. It is a type of non-functional testing.The main requirements for security testing are:
In our project, we used the following checkpoints while performing OWASP testing:
User Authentication confirms the identity of the user. But the authentication mechanism may be vulnerable due to flawed credential management functions such as password change, forgot password etc. We used the following checkpoints to safeguard against this:
- Password Strength: Passwords should have restrictions including minimum size and use of minimum combinations of letters, numbers, alpha numeric characters etc. E.g. Abcd@#12
- Password Use: No. of login attempts and no. of failed login attempts should be logged. E.g. Users can enter invalid credentials for a maximum of 5 times before the account is locked
- Password Storage: Passwords should be hashed while entering and stored in an encrypted format. E.g. Passwords should be displayed as ‘*********’ , ‘#########’ , ‘adas^*da432%324fsdf#’
Session IDs should not be exposed in the URL. They should be long, complicated and not easily guessable. The application URL may contain session IDs when a user is logged into the application. Other users should not be able to use these session IDs to log into the application. Also, other users should not able to copy and paste the URL in another browser and access the application without logging in.
A new session ID should always be created for every authentication. Logging out or clicking on the back button should not navigate the user to the application’s internal page which requires user authentication. The application can also be tested using session timeouts and session expiry details after closing the browser.
Cross-Site scripting includes malicious scripts which are included in code or trusted websites. Once the end user executes the script by accessing the application, the malicious code can access user’s sensitive data, cookies or session ids.
Cross-Site Scripting (XSS) has three types:
- Reflected Cross-Site Scripting: The user is tricked into clicking a malicious link, submitting a crafted form or browsing to a malicious site. This is by far the most common type of vulnerability.
- Stored Cross-Site Scripting: This is a permanent type of attack since the malicious script is stored in the database. The script is retrieved when the user fetches the record from the database.
- DOM based Cross-Site Scripting: In this attack, malicious code is based in the DOM environment. When the script executes, the client side code runs in an unexpected manner.
Here’s how we tested XSS for our project:
- Log into the application
- Navigate to a page with an input field that accepts a large number of characters e.g. Fields accepting custom messages
- Enter the following script and click on the save/submit button
Ex.1 : <script>alert (“hacked”) </script>
Ex.2 :< html> <body text=”green”>
<script>alert (‘You just found an XSS vulnerability’) </script>
- The application should not display a pop up message. It should display a valid error message like “Enter valid string” etc.
I have more to say about the basic concepts of security testing. I will talk about Insecure Direct Object References , Security Misconfiguration, Sensitive Data Exposure, Missing Function Level and Access Control in my next blog.
Vasim Khan | Zen Test labs