OWASP Testing 101 (Part 2)

In my previous post, I wrote about Broken Authentication, Session Management and Cross Site Scripting.  Today, I will continue talking about some more checkpoints to be kept in mind while performing OWASP testing.

Insecure Direct Object References
This involves modifying the URL parameter values and using them directly to retrieve a database record belonging to other users. If an ID or parameter in the URL is modified and refreshed, the application should not fetch a new record belonging to another user.This is the script we followed to test the vulnerability:

  1. Log into an application
  2. Navigate to the page where the value of a parameter is used directly to retrieve a database record, e.g. an invoice page with URL http://foo.bar/somepage?invoice=12345
  3. Modify the URL with a different invoice no. belonging to another user http://foo.bar/somepage?invoice=7985 and hit enter

Security Misconfiguration
Security Misconfiguration occurs due to poor configuration of an application (server or application level) which makes it vulnerable to malicious attacks. The application might be vulnerable to changes in website settings, unauthorized access or any other unintended actions on the application that divulge informative data or user details.This is how we tested the application for security misconfiguration:

Verify 404 Error message:

  1. Launch an application
  2. Manipulate the URL by deleting the directory structure and directly entering the page name
  3. Verify that “Server Error in ‘/’ Application” message displayed.The application should not return extra information related to the page or directory listings.

Intentionally crash the application using any of the following options where applicable and verify HTTP 404 Error:

  1. Change the DB configuration by providing invalid credentials OR
  2. Type only the domain name in the URL and hit enter
  3. Verify that error message is displayed

Sensitive Data Exposure
Even if an application is password protected, sensitive data such as credit card details, TAX ids and financial details etc should be encrypted or hashed in the database and masked while displaying at the front end. TLS/SSL should be used for transactions involving this type of data.This is how we tested the application for sensitive data exposure:

  1. Log into the application
  2. Navigate to My Profile / Password Reset page / My Account page
  3. Check the password field, Credit Card Number, SSN Number
  4. Launch the application with HTTP in the URL
  5. Check if the application is redirected to HTTPS
  6. The web application should be SSL Enabled and the URL should redirect to HTTPS

Make the following checks for sensitive data:

  • It should be masked in the application
  • It should not be cached
  • Auto complete should be disabled for forms containing sensitive data
  • CC/Account Number, Expiry/CVV Number etc., shouldn’t be exposed as clear text. Only the last four digits should be visible E.g. – **********1234
  • Account information (Account No., Routing No.) should be masked and stored in the database.  Account details should be masked on the receipt screen. E.g. – **********1234

Missing Function Level and Access Control
This is to verify user level access control of an application. Non-admin users should not be able to access screens that can only be accessed by admin users.

  1. Create two users, one with an admin role and another with a non-admin role
  2. Login as admin and verify that the application provides  functional and access privilege to  the admin user
  3. Login as a  non-admin user and verify if the restricted module is accessible

This project helped me experience a different flavor of testing and made me aware of the fact that applications are very vulnerable to malicious attacks and fraudulent users. If applications are not tested for security, then important user data and information is in danger of being compromised. Earlier, I used to test applications believing that functionality was the most important aspect, but now I have realized that for a robust and secure application, both functional as well as OWASP (security) testing are important.

Vasim Khan | Zen Test Labs

 

OWASP Testing 101 (Part 1)

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:

  • Confidentiality
  • Integrity
  • Authentication
  • Availability
  • Authorization
  • Non-repudiation

In our project, we used the following checkpoints while performing OWASP testing:

Broken Authentication
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 Management
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
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:

  1. Log into the application
  2. Navigate to a page with an input field that accepts a large number of characters e.g. Fields accepting custom messages
  3. 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>
    </body>
    </html>
  4. 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