The Importance of Performing a Web Application Penetration Test
Web application attacks have made the top three threats to small-to-mid-sized businesses (SMBs) two years in a row according to Verizon’s Data Breach Report. Delivered via a web browser, web applications are programs that run on a remote server. Many industries, including healthcare, financial services, insurance, and manufacturing, rely on them regularly.
Unfortunately, web apps often store sensitive information. This could include sensitive data, personally identifiable information (PII), or even protected health information (PHI). They are often targeted by cybercriminals since they are accessible via the internet.
As such, organizations must prioritize performing a penetration test. This helps ensure the product they are providing to their customers is secure.
Successful web application security attacks can be particularly devastating. They can result in:
- Extended downtimes due to denial of service (DoS) attacks;
- Data deletion through SQL injection attacks;
- Theft of customer credit cards or other information from malware; or
- Compromised end-user computers through cross-site scripting (XSS).
Click on the methodology components below to jump to the section you would like to learn more about.
- Web Application Penetration Testing 101
- Credentialed vs. Non-Credentialed Testing
- Reconnaissance
- Manual Crawl and Spidering
- Forced Browsing
- Passive Scanning
- Active Scanning
- False Positives and Validation
- The Human Element
- Web Application Security in the Cloud
- Next Steps
Web Application Penetration Testing 101
Organizations often engage a trusted third-party advisor to serve as an “ethical hacker.” They will perform web application penetration testing to simulate how a real-world attacker would try to compromise the organization’s application.
At project conclusion, the organization will receive a detailed pen test report. The report will explain if the system was successfully compromised and how. In addition, it will outline identified vulnerabilities and provide a comprehensive list of recommended remediation steps
Credentialed vs. Non-Credentialed Testing
Non-Credentialed Web App Penetration Testing
The penetration tester will begin the engagement by performing a non-credentialed pen test. During this stage, the pen tester will simulate an attack against the web application without credentials. These attacks are typically limited to testing that requires brute force attacks. This type of attack uses automated attempts to identify the login information of a user. Conducting brute force attacks can occur in one of four ways:
- Match multiple passwords with a single username;
- Match multiple usernames with one password, known as password spraying;
- Use multiple passwords and usernames in various combinations; or
- Attempt to crack hashes of passwords during an offline attack.
In the end, a brute force attack is a numbers game. While non-credentialed testing can reveal some vulnerabilities, it’s not the most effective. The ideal approach is to combine it with credentialed web app pen testing. This allows the ethical hacker to assess the web application’s security while logged in with a valid username and password.
Credentialed Web App Penetration Testing
With a credentialed approach, the attack surface dramatically increases. For example, imagine visiting a site without a user account. Certain features of the website are inaccessible without logging in. If executing a test without user credentials, the results could miss entire functions of the application. Credentialed pen testing provides a more thorough assessment. It also simulates what could happen if the attacker gains access to stolen user credentials. For example, in 2021, a single data breach exposed 8.4 billion passwords.
Using stolen credentials, a hacker can initiate a process known as credential stuffing. This allows hackers to launch automated login requests against hundreds of web applications. If using the same user name and password for multiple websites (i.e., password reuse), an attacker may find an easy way into the app to launch their attack.
Reconnaissance
Whether credentialed or non-credentialed, reconnaissance is often one of the first steps in a web application penetration test. Reconnaissance involves the collection of data about the particular target web application. The collection of data may include, but is not limited to, identifying:
- All subdomains
- The presence of firewalls
- Frameworks and programming languages
- Content management systems
- Plugins
- Themes
This collection leads to a more informed, and therefore more thorough, penetration test. With this information available, cybersecurity engineers can develop a customized attack plan.
Manual Crawl and Spidering
Every penetration test should begin with a manual crawl of the site, followed by automated spidering. During a typical penetration test, cybersecurity engineers will log in to the website. From there, they will manually click on every link. While doing this exercise, they will also complete the forms on the landing pages and submit the data. The general idea is to map the entire website by hand before relying on automation. The side benefit of including this step is that the pen tester can get a solid idea of the application’s layout. This includes items such as the sitemap, available features, and infrastructure. Information gathered during this stage will aid them later in the process. The pen tester will also continue to capture more requests as he or she crawls the site. These requests will then be passively scanned by the web application testing tool.
Spidering, on the other hand, is an automated process and may discover unclicked links. For the best results, the pen tester should complete this process while logged into the app. Yet, even by visiting each link, cybersecurity engineers and the web application testing tools are limited to uncovering pages that the site links to directly. Forced browsing is required to further expand the discovery of site content.
Forced Browsing
Forced browsing aims to identify possible directory paths and files in the web application that do not have direct links. Although files, such as domain directories, temporary files, or old backup/configuration files, are not referenced within the web application, they may still be accessible. Attempting to access these records during a penetration test is essential. Hackers often covet these files because of the sensitive information they may contain. Old backup/configuration files, for example, may have source code or internal network addressing. Using brute force attempts, this type of attack is known as Predictable Resource Location, File Enumeration, Directory Enumeration, or Resource Enumeration.
These lists can be extensive and, based on their size, can significantly increase the time needed for web application penetration testing. The benefit, however, is a far more thorough test and more significant end results.
Passive Scanning
While spidering and forced browsing are occurring, the web application will be scanned for potential vulnerabilities. The results will be returned as alerts. Typically there is nothing required on the users’ end to activate this. A good web application penetration test may include additional scripts, extensions, and add-ons.
Active Scanning
Active scanning will begin once the web application has been thoroughly mapped. This process modifies and sends a variety of web requests that test for the OWASP Top 10 Web Application vulnerabilities. These may include:
- SQL injection;
- Cross-site scripting (XSS);
- Insufficient logging and monitoring; and
- Others.
New attack vectors that have become prevalent include XSS through the uploading of files or In-Direct Object Reference, more commonly known as IDOR. The popularity of attacks often changes. Staying informed on the latest threats is essential to performing a more thorough web application penetration test.
False Positives and Validation
Arguably, this is an essential part of the penetration testing process. It differentiates an actual penetration test from a vulnerability scan. What good is a penetration test without confirmation after all?
It is not uncommon for web application testing software to generate false positives. This issue can be aggravating for the IT department responsible for patching or updating their site. Also, it can increase the cost of an organization’s remediation efforts
It is also possible for vulnerability scans to miss important alerts. This is because they do not account for manipulation. For example, scans cannot identify how vulnerabilities work together, known as vulnerability chaining. So two low priority vulnerabilities that may get overlooked could, in theory, be combined.
This combination could then result in a critical vulnerability. Without the understanding necessary to perform validation, the results can be clouded.
The Human Element
There are many components to conducting effective web application penetration testing. Many have already been discussed above. One of the most important factors, however, is the human element. Engaging the right people with the right experience is essential. After all, the point of a penetration test is to test how effective the web application security is at deterring a highly motivated and skilled hacker. Many exploits and vulnerabilities can result in unintended consequences if mishandled. Some are obvious. For example, a well-trained pen tester would not verify a denial of service (DoS) vulnerability. If they did, it could take the web application offline and result in downtime.
Other attacks may be less noticeable. For example, a buffer overflow exploit and other memory-based attacks may result in a denial of service. If the pen tester does not confirm this result as a possibility, or if they are not aware of it, they might as well have launched a DoS attack on the application. Admittedly, the result is the same.
Web Application Security in the Cloud
More organizations are utilizing cloud computing platforms to host their web applications. Amazon Web Services (AWS) and Microsoft Azure are two of the more common platforms. The reliability, scalability, and affordability of this approach make it an enticing option. Cloud providers can provide some peace of mind in terms of data security. They do not, however, have responsibility for the security of the web application they are hosting. For example, AWS has the Shared Responsibility Model. This specifically states that “Security and Compliance is a shared responsibility between AWS and the customer.”
The hosting provider manages the security of the cloud infrastructure. Meanwhile, the customer is responsible for securing the web application and sensitive data within. As such, organizations cannot afford to fall into the trap of having a false sense of security by using a popular cloud computing platform. Understanding what your security responsibilities are is crucial.
Next Steps
According to the 2021 Verizon Data Breach Investigations Report, web applications were the top threat vector resulting in a data breach, out-competing second place by over 75%. Penetration testing is a popular method for evaluating web application security and identifying vulnerabilities that could be exploited by hackers and result in a data breach. These findings can be invaluable to the application developers or IT departments who are tasked with maintaining the security of an application and remediating vulnerabilities. Not all pen tests, however, are created equal. Engaging the right people with the right tools and experience is vital for ensuring a thorough and accurate test.
Before you go, don’t forget to fill out the form to download the white paper:
If you have a question regarding web application penetration testing, or would like to secure your web application against cybersecurity threats, reach out to a member of our cybersecurity team at sales@nexuscyber.com.
Not All Pen Tests are Created Equal
[gravityform id=”32″ title=”false” description=”false” ajax=”true”]
0 Comments