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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s