This is part 3 of a multi-episode series where the Offsec group at SecurIT360 dives into the details of various Offensive Security Tests, what they mean, what to expect, war stories and much more!
If you’re on to go, listen here or on your favorite podcast app: https://www.buzzsprout.com/1731753/11612271
Written by Darrius Robinson
In today’s technological landscape, Web Applications (and by further extension, APIs, but that’s a story for another day) make up the majority of what people interact with using the internet. In fact, depending on how you came across this blog post, there’s a good chance you may be using a web app right now.
With web applications being so integrated into today’s society, it’s no wonder that they have become juicy targets for threat actors. In comes Web Application penetration tests to save the day and reduce the risk Web Applications pose to companies.
What is a web app penetration test?
A company may ask for a Web App Pentest for a multitude of reasons, such as compliance. However, the goal and process of a Web App Pentest remains the same in most cases. The goal is to gain an understanding of the web app’s security posture and the risk it possesses.
Performing web app penetration tests is an essential step for any business/developers’ software development lifecycle (SDLC) for any public-facing web applications. A web application that seems simple and insignificant could pose a critical risk that could result in the exfiltration of sensitive data or even the complete compromise of the application and its underlining infrastructure.
Web app penetration tests VS Other forms of penetration tests
A common misconception is that web application penetration tests are the same as other types of penetration testing. This is far from the truth! Unlike with network or external penetration testing, where the goal is to assess the configurations and controls of a network/domain, web app testing focuses more on identifying insecure use of software and development flaws. Because of this, it is not uncommon for a customer to provide credentials and in some cases source code of the application.
How to prepare for a web app penetration test?
While not all-encompassing, here are some general tips for preparing for a web application penetration test:
- Define a clear scope prior to the engagement. This will increase efficiency and result in a more productive engagement.
- As much as possible, understand the application being tested. Doing so, will help relaying important information to the tester.
- Spin up a test environment prior to the engagement.
- If you have a web application firewall (WAF) or other 3rd party controls in place, consider whitelisting the tester. Remember that the point of a web app penetration test is to find the risk associated with the application and underlying code, not test if your WAF is configured correctly. Additionally, WAFs can be bypassed with enough effort.
- Consider providing the source code to testers. While the tester performing the work should be able to execute the test without it, reading the source code can assist in finding vulnerabilities faster.
Web App Penetration Test Process
After contracts have been signed and kick-off calls meeting have occurred, web app penetration tests follow a process that consists of both automated and manual testing.
The first phase of most web application penetration tests is to crawl and audit the site. By doing so, both with automated and manual processes, the tester familiarizes themselves with the application and identifies potential weak points. This phase is normally performed multiple times. At the bare minimum, testers should perform an unauthenticated crawl and an authenticated one with each set of credentials they’ve been given.
Based upon the findings from the previous phase, the tester will then begin to attack the application. These attacks may range from SQL injections to authentication bypasses or my personal favorite, unrestricted file uploads and remote code execution (it happens more than you may think). As the tester validates their findings, they will collect evidence that will be used within their final report.
After thoroughly investigating and testing, the tester will produce a detailed report outlining all the findings, their corresponding evidence, and most importantly, how to fix all the vulnerabilities that were found.
Web App Pentest Tools
Some common web app penetrations tools are as follows:
- PortSwigger Burp suite – One of, if not the most popular tool for web application penetration testing. At its core, it serves as a proxy that sits between the tester and the web application. It is feature rich, but some of the more notable features are the ability to capture and modify requests made to the application, scan the application for the common vulnerabilities, and includes the ability to create and add custom plugins.
- OWASP Zed Attack Proxy (ZAP) – Another web proxy tool that was developed by OWASP. This tool is 100% free and offers similar features to that of Burp suite. While not as popular, it is still a powerhouse in its own regard.
- SQL Map – A utility for detecting and exploiting SQL injection (SQLi) vulnerabilities found within web applications. It’s a must have for testing and supports most modern databases.
- XSSer – A utility for detecting and exploiting Cross Site Scripting (XSS) vulnerabilities found within web applications.
- Gobuster – A common utility used to find common and hidden directories within an web application. The benefit of using Gobuster over other similar utilities is the fact that it is written is Go, which makes it extremely fast and portable.
- Wfuzz – Another utility that makes web application pentesting more efficient. Wfuzz assists with the process of fuzzing an application. This is an extremely important step during testing as fuzzing often leads to finding other vulnerabilities such as XSS or SQLi.
- SQLNINJA – Another utility similar to SQL Map.
Common Web App Vulnerabilities
While not all-encompassing, some common web app vulnerabilities are:
- Broken Access Controls
- Cryptographic Failures
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery
Work with Us: https://securit360.com