Web Application Penetration Testing
Ever since the passage of the Health Insurance Portability and Accountability Act (HIPAA) in 1996, the Gramm-Leach-Bliley Act (GLBA) in 1999, and the Homeland Security Act in 2002, there has been a sustained focus on Information Security by regulators, legislators and industry. It’s certainly understandable that its profile should have risen. As the Internet, cloud computing, mobile devices, etc. have become mainstream, so have hacking and other threats. The pertinent risks have grown by orders of magnitude – cybersecurity, pandemic, third-party, etc.
Our Web Application Penetration Test and Vulnerability Assessment focuses primarily on the Organization’s Web Applications, with an emphasis on finding vulnerabilities, bad coding practices, or usage of vulnerable dependencies that can potentially expose the website to session hijacking, malicious scripts injections, credential capture, and other known web attacks. Potential targets identified during stages one and two are tested for vulnerabilities. Attempts are then made to exploit potential vulnerabilities to gain access to various systems. This test is performed from the perspective of a potential attacker using grey box testing methodologies.
As with the Network Penetration Testing, above, this exercise consists of four phases. During the first phase, using manual tools, we will explore all functionalities provided by the application. The process will include following all links, pressing all available buttons, and filling in and submitting all forms. If the applications support multiple roles, then we will perform such test for each of the roles.
During the next phase of our testing, we will use an automated scanning tool to find URLs that have either been missed or are hidden. Depending on your web application, we may also use an AJAX Spider to identify dynamic-built links. This information gathering stage will include browsing all available directories and identifying any possible source code disclosure vulnerabilities.
Third, in the vulnerability identification stage, we will use automated scanning tools to examine the targeted web application for security vulnerabilities, such as buffer overflow, CRLF injection, cross site scripting, et al. We will also a) scan the server for security vulnerabilities, such as path traversal and remote file inclusion, and b) perform an uncredentialled API vulnerability scan on the Organization’s API platform in order to ensure the Organization’s private API resources are not publicly exposed and that no network vulnerabilities exist via the cloud infrastructure supporting the platform.
Last, we will perform analysis and penetration attempts using the information we gathered from the previous three stages. However, destructive exploitation such as DoS (Denial of Service) or weakening the Organization’s security controls will not be tested. We will, however, immediately alert management upon discovery of such vulnerabilities.
The penetration attempts will be done using both proprietary tools and industry-standard tools that are commonly available to pen testers and hackers. Our goal in this stage is to further eliminate potential false positive that are found in the vulnerability identification stage. By testing the actual vulnerabilities, we eliminate any time wasted by the Organization’s IT personnel to chase down false positive results.