Open Mobile Menu


Why Is Manual Penetration Testing Important?

Views: 2705

Written By: Cindee Tran August 18, 2016

Application penetration testing can involve many different aspects of security testing, depending on the scope of the project and whether or not the application handles sensitive information. If the company stores and processes credit card information, then they would also have to adhere to the Payment Card Industry Standards. If the application is not sensitive, but shares the same database with another internal application that happens to store sensitive information, then it's still equally important to secure the non-sensitive application in the same way.

One common way of performing penetration testing on an application is to run an application scanner against all of the pages and parameters within the application. This is a wonderful way to quickly identify and gather all of the low hanging fruit issues, especially for identifying common injection vulnerabilities, such as SQL Injection and XML External Entity Injection. This step is very important in fully utilizing the time that is given for the specific engagement - application scanning will not only allow the pentester quickly identify the harmful vulnerabilities, but it will also allow the pentester to gauge and understand what security state the application is in and where the pentester should focus and spend their remaining time throughout the penetration test.

When application scanning is complete and those identified findings are verified, the next step is to perform manual testing to identify findings that the application scanner cannot pick up. Although this step is equally as important as application scanning, it is often overlooked. For this blog post, I'd like to focus on the methodology of an application-level pentest and talk about how specifically important manual testing is.

It is rare that an application scanner can successfully identify Privilege Escalation. Privilege Escalation is an exploit that allows a low-level user with limited access to gain elevated access to an application. There are several ways to identify this vulnerability and one common way that the application scanner does it is by using the lower level user's session to forcefully browse to pages that only the Admin or user with higher-level of access can reach. This can be successful, but time-consuming because the pentester would need to guide the application scanner through each page for both user levels. A more efficient way to test Privilege Escalation via forceful browsing without the application scanner is to open up two browsers and copying the important URLs from the user with higher level of access over to the browser for the lower-level access user and see how the application responds. If one page is vulnerable, then it is common for it to be a systemic issue - meaning that it is likely that many pages will be vulnerable.

Another way to identify Privilege Escalation is via parameter tampering. Often times, an application will pass in a parameter, such as a User ID, to view or modify a page, such as a profile page. An application scanner has no way to identify that a parameter such as User ID should be tampered with and how to increment the ID to verify whether or it can be successfully exploited. A pentester would need to identify this manually and verify it by learning how the developer may be generating the ID. It can involve simply incrementing the ID value, or by comparing the ID value of an Admin user to a low-level user and see what the differences are. When this vulnerability is confirmed manually, often times, it can exploited by an automated tool in order to quickly obtain more data and prove the exploit.

Persistent Cross-Site Scripting is a vulnerability that many application scanners try to identify, but often times fail. This vulnerability is the same as Reflected Cross-Site Scripting, except that the payload can be stored in the database and any time a victim accesses a page where the payload is stored, the payload is executed. As an experienced pentester, I know that the pages that are often overlooked for this type of vulnerability are pages that pentesters know not to scan, because these are the pages that create a lot of data. For example, submitting a questionnaire that will create records in the database. If a pentester scanned this page with an application scanner, then they are likely going to create thousands of records in the database and customers do not particularly like that - especially if the form triggers an automated email for each submission. However, because pentesters know not to scan that type page, sometimes that page is often forgotten or ignored. These pages are great candidates to exploit this type of vulnerability manually. Many large applications will run the payload on several different pages, so it is important for the pentester to manually inject the payload early in the pentesting engagement, which will give the pentester time to verify whether or not the payload is executed on any other pages. It is not always obvious where the payload will be returned in the response.

Application scanners ineffectively identify Cross-Site Request Forgery as well – often times producing false positives. One technique that the application scanners use to identify the lack of Cross-Site Request Forgery protection is by verifying that the Referer header exists and matches the site's origin. However, since we recommend that all applications that perform sensitive transactions require a GUID that is added as a hidden field and sent in each request to be verified on the server that the GUID matches the one from the hidden field, it is very difficult for application scanners to correctly identify this implementation. To effectively test Cross-Site Request Forgery, an experienced pentester would need to manually verify this.

Account recovery is another area that is best tested manually.  No automated tool can process any email based flow, including the Forgot Password functionality. An application scanner does not know whether or not the Forgot Password functionality can be brute-forced in order to obtain valid usernames. It also does not know when a Forgot Password link expires or whether or not the strength of security questions is an issue. A vulnerability that has been identified often during my years as a penetration tester is having the ability to bypass the security questions altogether by browsing directly to the Password Change page. Application scanners have a difficult time with logic and process-based flows. Application scanners are also not aware of when sensitive account changes are made – this requires a manual check to verify that users have been appropriately notified of account changes.

There are many other vulnerabilities that are better identified manually, including password management, logout functionality, session length and token handling. Every application is different - it is very important to think outside of the box each time because what may work with one application may not work with the next. A successful penetration test includes good time management to break down the application and know where to spend the bulk of the time on each pentest engagement. Manual testing requires experience and knowledge of how each application works and what to look out for and is equally as important as running an application scanner against the website.

Cindee Tran

Cindee Tran is a Senior Security Consultant at AppSec Consulting.  She has spent the past 5 years performing black-box and white-box style testing for a wide variety of projects of different sizes and requirements, including large scale web applications, web services, and IOS/Android/Windows Mobile applications.  Cindee is an outside-the-box thinker who excels in identifying and documenting unique vulnerabilities that would only be found by an experienced human tester, such as logical issues, clever ways win game battles, and techniques for bypassing various input validation filters.  She has a deep understanding of mobile privacy threats, and enjoys spending time researching and identifying vulnerabilities that can lead to leakage of user data.  She has identified and responsibly disclosed many vulnerabilities within mobile and web applications. 


Cindee obtained a Bachelor’s degree in Computer Science at Stevens Henager College and has over 10 years of IT experience.  Prior to joining AppSec Consulting, she worked as a DBA and .NET Software Developer building and maintaining highly sensitive web applications for Fortune 500 companies that required strict adherence with Sarbanes-Oxley. 

read more articles by Cindee Tran