7 Reasons Why You Need a Manual Penetration Test

7 Reasons Why You Need a Manual Penetration Test

Vulnerability Scans vs. Penetration Testing

If you’re investing in penetration testing, you need to make sure that the firm you’ve partnered with is not merely passing off vulnerability scanning as a penetration test. While automatic vulnerability scanners are great for discovering low-hanging fruit, automatic vulnerability scanners should not be confused with an advanced, manual penetration test. Allowing manual penetration testers to gain a basic understanding of an organization’s current security footprint and grant them the ability to target other areas of the application that will require more time and attention, but will be worth it. Vulnerability scanners are only capable of matching patterns and definitions, and are unable to find flaws that require human logic and comprehension. So, what are the benefits of advanced penetration testing?

Benefits of a Manual Penetration Test

Even with the dawn of machine learning programs, there are still items that require human attention to detail, to accurately determine, or to verify. This is where the value of a manual penetration tester is so important. Advanced penetration testers can use their ingenuity, business logic, and abilities in analysis to discover the deep, nested flaws within a system. If an organization only hires a firm that uses automatic vulnerability scanners, critical items could be missed. These items that require human attention are what we believe to be the seven reasons why you need a manual penetration test.

DOM Based Cross-Site Scripting (XSS)

Cross-site scripting (XSS) occurs when arbitrary code, such as JavaScript, Action Script, or VCScript, is injected into a parameter and returned with a following response. Typically, XSS will fall into the following categories: reflected, stored, or DOM based injection. DOM based XSS injection is incredibly dangerous to users of an application because each HTML document becomes a “Document Object” when it is loaded into a web browser and acts as the root node of the HTML document. The Document Object Model (DOM) contains many nodes, which are represented visually to the user. If a developer allows input to alter a response of a page, including one of the nodes with the DOM, external JavaScript, inputs, and other items can be tampered with to inject arbitrary code, resulting in an XSS attack that will be stored with the DOM of the returned response. Such vulnerabilities can be difficult for automatic vulnerability scanners to detect. Source code can be crawled and basic assumptions can be made, but manual testing of the objects should be required to verify or discover these issues.

Blind SQL Injection

SQL injection occurs when a user of the application injects SQL commands into the backend of a database. While developers have found ways to suppress errors displayed on the screen and instead log errors on the back-end, malicious hackers are still able to find ways to exploit vulnerable areas. Because of this, automatic vulnerability scanners will often fail in discovering these vectors of attack, which is why a manual penetration test is so important. A trained human eye is required to examine the responses of the application, as many are not revealed within a returned message. During a manual penetration test, the penetration tester will inject commands to cause the database to sleep or delay, and they will slowly watch for a delayed response in the return or visual disturbances within the response.

CSRF (Cross-SiteRequest Forgery) Attacks

Cross-Site Request Forgery (CSRF) attacks occur when an application fails to provide a mechanism to verify that the request being issued is known by the account user and is truly being requested by them. Most commonly, sensitive attacks such as creating a user account or changing a password should be tied with a unique token, which is issued along with the web request. This token should be usable once for that action and then rendered unusable for future requests to prevent “replay” attacks. Such attacks are difficult for automatic vulnerability scanners to detect because they either show a false positive when they believe a CSRF token is not present, or they show a false negative when tokens are present but are not functioning properly. Considering this, manual penetration testing is needed to determine the application’s vulnerability.

Logic Flaws

Logic flaws are among the toughest issues to find within an application as they require more in-depth inspection and are not blatantly obvious in their presence. Logic flaws creep up in the development of an application, especially within some of the more complex components such as session handling. Let’s say a developer has created a shopping cart functionality for a web application. In calculating the price, the cart functionality takes the quantity and price of the item, displays the price, and allows the user to proceed. A logic flaw may exist if a person inputs a negative value for the quantity. So, if an item costs $399, when calculated with a negative value of-1, the item would then become -$399. When the payment goes through, the purchasing value is then rendered to be free or $399 might even be refunded to the user.

Template Injections

Template injections are becoming more common with some of the newer frameworks, as critical security findings allow remote access into the backend system. This access, also known as “Server-Side Template Injection,” allows certain inputs to interact with the backend system because of the ability to allow for dynamic generation of custom pages. For example, when a user inputs their email or username, if proper protections are not in place, server-side code can instead be injected. Template injections can sometimes be detected by automatic vulnerability scanners, but often protections are in place that can fool most of the automatic vulnerability scanners into missing the findings. During advanced penetration testing, the penetration tester can play with the input and escape blacklists, resulting in successful exploitation.

Broken Access Control

Access control and session handling are two of the hardest areas to secure within web applications. If done incorrectly, critical security issues can arise from poor coding implementation. This is another blind spot for automatic vulnerability scanners. It is difficult to determine, based off of a signature, whether an application is vulnerable. During a manual penetration test, a penetration tester will have to incorporate a lot of repetitive work, including in-depth examinations of the components at work.

Miscellaneous Injection Attacks

Some of the newer frameworks today include their own custom scripting languages or incorporate other forms of coding to help extend functionality. While some automatic vulnerability scanners can detect common injections, such as JavaScript, XML, and ActionScript, they can’t include all varieties of languages. Having a manual penetration test would be of great value, because a manual penetration tester can see custom language being used and will then be able to try to manipulate the outcome.

Automatic vulnerability scanners have their purpose within the security field. The problem with security scanners becomes apparent when they are solely relied upon to provide a security assessment. 

If you’re investing in your organization’s security by undergoing penetration testing, make sure that you’re actually receiving a penetration test. Don’t let firms misguide you into thinking that an automatic vulnerability scanner can detect all of your system’s vulnerabilities. If the firm you’ve hired doesn’t use manual methods from an expert during the penetration test, you’re not receiving a quality penetration test. Contact us today to learn more about our quality, advanced penetration testing services.

More Penetration Testing Resources

Penetration Steps for a Secure Business

Not All Penetration Tests Are Created Equal

Components of a Quality Penetration Test

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *