In the early days of the internet, security was an afterthought. Then, things gradually began to change as hackers began to take advantage of the company’s lax security posture. At first, nonprofits like the Electronic Frontier Foundation started pushing web users to use HTTPS Everywhere. In response, certification authorities began offering free SSL certificate variants to any site administrator who wanted an SSL certificate. As a result, at least 79.6% of active websites now use SSL.
That’s just the beginning. Over the next few years, developers and web application administrators gradually began to harden their applications against a wide variety of attacks. They introduced more complex password requirements. They started adding two-factor authentication as a default measure. They even started putting public-facing services behind high-performance web application firewalls.
But despite all the progress, vulnerabilities remain, meaning web application developers and administrators must understand how to do the penetration test on their systems to see if any known vulnerabilities can penetrate their multi-layered defenses. To do this, they must understand the various stages of the penetration testing process to avoid leaving any security holes. Below are the four main steps involved in web application penetration testing.
Step 1: Web Application Observation
The first important step in the Web application penetration testing process involves adopting the same strategy as the attacker: learn as much as possible about the target. The first thing to do is to gather information about the target web application from a public website like Google. The search modifier can collect a complete list of subdomains and pages associated with the application. This provides a pretty good map of the potential attacks that a hacker must deal with.
The next thing to do is to use a network scanner like Nmap to collect data specific to the web application itself. The idea is to figure out how much information about the software and the server is visible to the outside world. Then, a full scan using security testing software like Burp Suite should reveal everything from the server software version to the application environment.
Step 2: Vulnerability Research and Attacks
The next major step in the Web application penetration testing process is to use the data collected to begin narrowing down the list of vulnerabilities that can be attempted to be exploited. In other words, if you find a specific version of Apache and PHP that an attacker can tell you are using, then you should start looking for known vulnerabilities in those versions in order to try to exploit them.
Fortunately, there are some great open source penetration testing tools that can automate some of this work. You can choose from these based on the type of vulnerabilities you are checking. Popular choices include :
- W3af
- Metasploit
- SQLMap
- Hydra
The idea is to try to find every potentially exploitable vulnerability and catalog the ones that are found. If possible, it’s a good idea to use these vulnerabilities to simulate an attack to see how far a malicious actor can go by exploiting them.
Step 3: Catalog and Reports
The next step in the process is to create a report detailing everything found in the first two steps. The idea is to create a central repository that the entire development team can use as a roadmap for fixing issues. This is where the data you collect in attack simulations will come in handy.
Reports should categorize vulnerabilities according to their severity. There are various publicly available sample penetration test reports that you can use to develop a format that suits your needs. This makes it easier to prioritize efforts to close all security holes. This is an absolutely critical step if you are working on an already running application. Remember, the vulnerabilities you find may already be on a hacker’s radar, so the sooner you can patch serious vulnerabilities, the better.
Step 4: Patch and Repeat
The final step is to review the penetration test report and begin addressing the vulnerabilities identified in it. For an already existing application, it’s best to start by applying as many expedients as possible. These might include changing website access rules in your web application layer firewall or taking particularly vulnerable parts of your application offline.
Then, proceed to determine the best possible fixes for the reported vulnerabilities. Starting with the most serious issues. This will help you know where to focus your next round of testing, which you will have to start after completing the remediation work
Create a hard target
By repeating the above process until no vulnerabilities are discovered, web application developers and administrators can have reasonable assurance that they are not sitting ducks waiting to be attacked. Of course, this is only for known vulnerabilities, so this process doesn’t make the attack impossible, just unlikely. In an ever-changing cybersecurity landscape, this is often the best one can hope for. Remember, not so long ago, SSL and complex ciphers were the ultimate goal of web application security, so constant vigilance will always be the price of proper security.
