Has your organization developed a web-based application, either in-house or using outside developers? If so, a penetration test can prove invaluable by identifying web application security vulnerabilities so they can be remediated before being exploited by an attacker.
Web applications that store, process, or transmit sensitive data are a lucrative target for hackers. In fact, 26% of organizations said they either confirmed or suspected a web app data breach over the past 12 months, according to a 2019 survey.
Successful web application security attacks can be particularly devastating. They can result in extended downtime due to denial-of-service, 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.
Web Application Penetration Testing
Organizations often engage a trusted third-party advisor to conduct a penetration test, also known as ethical hacking. The ethical hacker will simulate a real world attack by attempting to gain unauthorized access to the web application by exploiting vulnerabilities. The project results in a detailed report regarding whether the system was successfully compromised (and how), the vulnerabilities identified, and a comprehensive list of recommended remediation steps.
Credentialed vs. Non-Credentialed Pen Test
- Tests the web application using a valid login
- Multiple user roles can be tested, including administrative and user
- Tests the web application without a valid login
- Useful for static applications without login functionality
- Tests the web application both with and without a valid login
- Recommended approach as it provides comprehensive testing
The penetration tester will perform a non-credentialed pen test whereby they simulate attacks against the portions of the web application that are accessible without credentials. These attacks are typically limited to testing that requires brute force attacks, where automated attempts are made to identify the credentials of an existing user.
Brute force attacks can be conducted in one of four ways:
- Match multiple passwords with a single username;
- Match multiple usernames with one password, which is known as password spraying;
- Utilize multiple passwords and usernames in various combinations; or
- Conduct offline attacks where brute force attempts are made to crack hashes of passwords.
In the end, a brute force attack is just a numbers game.
Did You Know?
A weak password could allow a hacker access to a web application in a few seconds via a brute force attack. Conversely, a strong, encrypted password could take years to crack.
While non-credentialed testing can reveal some vulnerabilities, the ideal approach is to combine it with credentialed pen testing whereby the ethical hacker can assess the web application’s security while logged in with a valid user name and password. 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 being logged in. If executing a test without user credentials, the results will not only miss individual pages but entire functions as well.
Not only does credentialed pen testing provide a more thorough assessment, but it also simulates the common occurrence where the attacker gains access to the web application through stolen user credentials. For example, over 770 unique email addresses and over 20 million passwords were exposed and listed for sale on the dark web in 2019. Through a process known as credential stuffing, hackers will launch automated login requests against hundreds of web applications using the stolen user names and passwords. If that user name and password are the same for a different web application (i.e., password reuse), then an attacker may find an easy way into the app to launch their attack.
Whether credentialed or non-credentialed, reconnaissance is typically one of the first steps in a web application security test. Reconnaissance involves the collection of data about the particular target web application.
The collection of data might include identifying all subdomains, the presence of firewalls, frameworks and
programming languages, content management systems, plugins, themes, and other relevant information.
This collection leads to a more informed, and therefore more thorough, penetration test. With this information
available, cybersecurity engineers can refine their testing procedures and develop a customized attack plan.
Manual Crawl and Spidering
Every web application security 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 with user
credentials and 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 incorporating this step in the process is that the penetration tester can obtain a solid idea of the sitemap, features, and infrastructure, which aids them later in the process. As they crawl the site, more and more requests will be captured and passively scanned by the web application testing software.
Contrary to a manual crawl, spidering is automated and may discover unclicked links. For the best results, spidering should also be done using a logged-in account. Yet, even by visiting each link, cybersecurity engineers and the web application testing software are limited to uncovering pages that the site links to directly. To further expand the discovery of site content during the web application security test requires 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, among other things. Using brute force attempts, this type
of attack is known as Predictable Resource Location, File Enumeration, Directory Enumeration, or Resource
These lists can be extensive and, based on their size, can significantly increase the time needed for penetration testing. The benefit, however, is a far more thorough web application security test.
Real World Example
Hackers gained access to an e-commerce organization’s web application source code. They were able to inject a malicious script containing malware using a backend MySQL database. This injected code allowed the hackers to steal credit card information as payments were being processed. This code was exploited for two years before being discovered.
While spidering and forced browsing are occurring, the web application will be scanned for potential vulnerabilities and return the information as alerts. Typically, there is nothing required on the users’ end to activate this. A good web application security test, however, may include additional scripts, extensions, and add-ons.
With the web application thoroughly mapped, and the content discovered, the penetration testing process will transition to active scanning. Active scanning modifies and sends a variety of web requests that test for the OWASP Top 10 Web Application vulnerabilities, including SQL injection, XSS, and others. New attack vectors that have become prevalent include cross-site scripting (XSS) through the uploading of files or In-Direct Object Reference, more commonly known as IDOR. The popularity of attacks often changes; therefore, staying informed on the newest or most prevalent vulnerabilities is essential to conducting a more thorough web application security test.
False Positives and Validation
Common Web Application Security Threats:
- Cross-Site Scripting
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities
- Broken Access Control
- Insecure Deserialization
- Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
False positives and validation is an essential part of the web application security process. It differentiates an actual penetration test from a vulnerability scan, because what good is a penetration test without confirmation?
It is not uncommon for web application testing software to generate false positives. This issue can be
extremely 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 because it does not account for manipulation. For example, scans cannot identify how vulnerabilities work together. So two low priority vulnerabilities that may get overlooked could, in theory, be combined to create a critical vulnerability if manipulated correctly. Without the capability and understanding necessary to perform validation, the results can be clouded.
The Human Element
There are many facets to conducting an effective web application security test, many of which have been discussed above. One of the most important factors, however, is the human element. Identifying the right people with the right experience to partner with for your next pen test is essential. After all, the objective of a penetration test is to reveal what would happen if your web application was attacked by a highly motivated and skilled hacker.
Furthermore, 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 denial of service attack on the client’s web application. Admittedly, the result is the same.
Web Application Security in the Cloud
As with many technologies, organizations are utilizing cloud computing platforms such as Amazon Web Services (AWS) and Microsoft Azure to host their web applications. The reliability, scalability, and affordability of this approach make it an especially enticing option. Although cloud providers may provide some peace of mind in terms of data security, they do not necessarily have responsibility for the security of the web application they are hosting. For example, AWS has the Shared Responsibility Model that specifically highlights the fact that “Security and Compliance is a shared responsibility between AWS and the
While the hosting provider manages the security of the cloud infrastructure, it is still the customer’s responsibility to ensure the security of their web application and the data within it. As such, it is essential not to fall into the trap of having a false sense of security because your organization is using a popular cloud computing platform. Understanding what your security responsibilities are is crucial.
According to the 2019 Verizon Data Breach Investigations Report, approximately 25% of breaches occur through web application attacks. 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 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.