Most of us accept that cyber security is a growing problem for modern businesses. Organisations with any kind of digital components can be at risk from threat actors. One of the components at risk is a company’s web application. Here, we look at Application Security Testing (AST) and how it ensures web apps are more resistant to security threats.
Web application penetration testing describes the process of simulating an unobtrusive attack against a web application. Web application security testing is another term for this. It allows companies to understand vulnerabilities that are easy to miss during the development process. These weaknesses can have wide-reaching consequences to the application as well as the data stored within its database.
How common are web application vulnerabilities?
In our experience, most web applications have at least one high risk vulnerability. A single vulnerability can cause huge issues for an application and the data it contains. Many applications have vulnerabilities that are exploitable and go unnoticed during the development and QA stage of its development.
Web app vulnerabilities do not occur only during development. New features or minor updates to an application can often introduce new flaws, which, if not properly examined using a web app penetration test, can result in major implications for the application’s users and owners.
The Testing Process
So, how do we carry out a test for our clients? Are there preparations for them to make? It may be daunting for some, but there is no need to worry. Let’s look at the testing process.
Before you begin testing the application, the company (Sencode) and the client must agree on a scope. The scope will outline exactly which areas of the web application are in the parameters of testing. This may be from an unauthenticated, or authenticated perspective. Scope definition will provide test guidelines and will be the starting point for the engagement .
Firstly, the tester will look through the application to understand how its process flow works. The test will also find all the possible attack vectors on the application in the test. Once this process of discovery takes place, the tester will actively start attacking it. The tester will use several tools and methods (Such as OWASP) to test the web application.
The tester will look for SQL injection, cross-site scripting, and external entity injection, among other web application flaws. All of these vulnerabilities are frequently evident in web applications. The tester will classify and assess these findings to show the risk to the application during the test.
Frequently Asked Questions
The restrictions placed on a website’s development by time, money, and skill can lead to several vulnerabilities being left unfixed. Often the only way to discover these vulnerabilities is to have an external party check. Web application penetration testing is frequently used to highlight vulnerabilities any web application may have.
Companies that hold personal information on their users are legally responsible for storing and protecting that information. Failure to do so by not actively checking or security issues with an application can lead to severe fines by the ICO and can lead to lawsuits being brought against them by the people impacted if there were to be a data breach.
Web application testing has a lot of cross-over with API testing but also exposes the tester to a much deeper attack surface, often involving a much more diverse selection of attacking techniques. As with every type of testing, the first step is discovery. This includes finding which parts of the application can be tested, and what technologies are being used (.NET,PHP,Angular for example).
Once this has been completed, we can cater our attacks to the specific website technologies being tested. We will test for security vulnerabilities such as XSS, SQLi, OS command injection, access control violations and many more. Vulnerabilities can be chained together to create security issues with a higher severity. How can vulnerabilities be chained together? Take this example:
“During the testing we discovered the forgotten password function is vulnerable to username enumeration due to verbose responses. Account lockouts were not present on the system. Therefore we were able to chain these vulnerabilities together to compromise a large number of user accounts.”