Due to their accessibility via networks, web applications are a frequent target of attacks. Hackers capture valuable data via cross-site scripting, injections, or authentication errors. We pentest both standard and custom software and uncover unknown vulnerabilities. This will not only give you protection but also will make customers trust you more.
Penetration tests are now common practice in many companies, even if there are still companies in which not a single penetration test has been performed to date. These tests are performed from the attacker’s perspective and a professional tester performs the dynamic analysis. Penetration tests can have many different goals and methodology. For example, there are very simple tests against the infrastructure through port and vulnerability scans with manual evaluation. This is the lowest level of a test, both in terms of effort, but also in terms of knowledge gained. A specific form of testing is web application penetration. The article shows the most important planning aspects and stumbling blocks.
Table of Contents
Definition of penetration testing
There are a wide variety of definitions of what constitutes a penetration test. For example, NIST and BSI have published corresponding documents. If you shorten the definitions, you end up with the following formula: an attacker with a defined level of knowledge and defined authorizations performs a test in a defined time against a defined target.
The procedure and the result of the pentest:
- Preparation: After you have formulated expectations and goals, legal and organizational aspects are clarified. Here, for example, we define test periods as well as methods and delimit target systems.
- Analysis: Using publicly and non-publicly available information, we create a detailed overview of the current state of the systems to be examined. We then assess the risk of potential vulnerabilities and determine a promising and economically efficient course of action.
- Active tests: We use active tests to determine the extent to which a suspected vulnerability represents an actual risk. We conduct these tests with the necessary care to avoid system failures. Even if we have successfully penetrated a system, any remaining tests are carried out in full.
- Results report: In the results report, you receive a comprehensible description of the approach and an evaluation of the vulnerabilities found according to their risk. We discuss concrete recommendations for action with you and also support you in the further procedure after the check.
Motivation
“A penetration test only causes work.” This statement by a security manager is quite true in most cases. Often, especially when testing custom-built web applications, penetration testers find various vulnerabilities. Depending on the maturity of the software development process and possibly the moment of luck in selecting the right frameworks, developers have quite a bit of work ahead of them after a penetration test to fix the vulnerabilities they find. Based on customer feedback, the primary motivation for penetration testing is not a company’s own quality or security requirements, but rather compliance requirements from customers or legal requirements. In particular, the purchasing conditions of large pentesting have become standard in the purchase of software and IT-supported solutions. If you want to conclude a deal in this area, an audit by an independent third party is indispensable.
The planning phase
In order to tender for a penetration test and request it on the market, several things are important for service companies. First, a tester must understand what the application does in terms of content. In the case of an online store, this is comparatively simple. The business case is immediately clear. In the case of special applications, for example in the fields of human resources, logistics, pharmaceuticals or finance, the applications are in part very individually and subject-specifically structured. Some even use their own protocols, such as EBICS in the banking environment. It is a good idea to prepare a short presentation that explains the most important aspects and the functional scope of the application.
Rights models
Many applications offer user administration and different roles and rights models. A comparatively time-consuming service, because it can only be performed manually, is checking for privilege escalation. Both horizontal expansion, i.e. the selective assumption of the role of another user in the same rights context, and vertical utilization, i.e. an increase in the user’s own rights, can be checked. One test would be to call a function that is only available to user A, but is called by user B. This would be a test of the user’s own rights. In contrast to functional tests, however, this is not done by using the user interface, but one level deeper. In advance, it must be defined which roles and rights are to be checked and which functions are to be within the role and rights model are to be specifically checked. Particularly in complex environments, a complete check of the role rights model is a very time-consuming check. It is therefore advisable to select a defined number of test cases on a risk-oriented basis.
Production or test environment
Checks in the production environment are associated with the very highest risks. A simple example: on the production environment is a contact form. This contact form is imported into first-level support as a ticket or an email is generated. During a penetration test, variables, in particular, are iterated to determine vulnerabilities. Even with a form like a contact form with few input fields, such a form can be accessed up to several thousand times. If this is not coordinated in advance, a thank-you from first-level support, both the planners and the testers are certain. It is therefore essential that the product owner, for example, discusses in advance with his developers on the business side which workflows may not be checked automatically, or only within a defined framework.
WAF or not WAF
A web application firewall (WAF) intervenes in the data stream and uses signatures to try to fend off known attacks. From the author’s point of view, a penetration test should always be about checking the actual web application. For example, it makes sense to deactivate the WAF for a test or to switch it to “on” specifically for the addresses of the testers. If specific vulnerabilities in the application have been identified during the checks, the WAF can be reactivated. Now the vulnerabilities found can be specifically tested again with the WAF activated. This means that, with a minimum of additional effort, you not only obtain a statement about which vulnerabilities exist in the application, but also whether the WAF offers the level of resilience expected for specific attacks on known vulnerabilities.
Let me through, I am a tester
Due to a large number of possible vulnerabilities, variables are often iterated as described and forms are sent frequently. Sensitive functions in particular, such as a login screen, are usually protected by mechanisms that prevent such mass testing. For active operation, this is a good idea. However, they also prevent a high level of testing depth through penetration tests, at least with reasonable effort. Therefore, it must be considered in advance whether corresponding mechanisms such as captchas or rate limiting can be temporarily deactivated for testing, at least on one test instance. This increases the test depth.
A captcha is only capable of making a mass check more difficult. However, it does not prevent the exploitation of a vulnerability. Let’s assume that there is an SQL injection vulnerability in the login function. While a captcha would make it much more difficult to find the vulnerability, since the testing tools inherently send many queries to the application to find the vulnerability, so does the tester in his manual testing. However, if the tester sends the attack signature (payload) matching the vulnerability at the very beginning of his testing, he will find the vulnerability. Therefore, it makes sense to seriously discuss a temporary disablement, even though it may sound silly at first to disable protections for security testing.
Off to the time capsule
So what is a valid test time for a penetration test? The rule of thumb is: the more complex and functionally extensive the application to be tested, the more extensive the test. However, a penetration test is not a deterministic testing method. Thus, a total execution period is normally offered in a project. Let’s assume that this period is ten days. How much time within these ten project days will be necessary for testing and how much time for documentation, nobody knows before the tests! The extent of documentation is primarily defined by the number and description intensity of the vulnerabilities found.
By their very nature, these are not known before the test. In this respect, the tester cannot know before a test how much time will be needed for the documentation within the project period. If the application has a lot of vulnerabilities very quickly, the tester will stop testing after a few days to document the vulnerabilities found to date. If the application is very resilient, he will be able to test for a long time, as the documentation period will be correspondingly much shorter. However, the test statement is very helpful in both cases. For the first case, it is clear that the application has massive and extensive vulnerabilities that should not be taken lightly. In the second case, with the same overall effort, it is clear that it is a resilient application where very many things were obviously done right in development.
Hello, is anyone there?
Once all the arrangements have been made and a testing period has been agreed upon, testing can begin. During the testing period, it is necessary that it is always available both on the tester’s side and on the client’s side. A daily status update can be useful. In practice, however, it has been shown that it is usually most efficient for the testers to contact the client immediately at the earliest when high-risk vulnerabilities are found. After the tests, a comprehensible and transparent test report written by the tester himself must be available. This can be discussed in a telephone or personal meeting.
Why, why, why?
As described, penetration tests are usually associated with a gain in knowledge. This gain in knowledge entails work. However, instead of simply fixing the vulnerabilities, a critical look should be taken at the processes that could actually have prevented the occurrence of such vulnerabilities. Are developers required to pay sufficient attention to security issues, or are they just chasing technical guidelines? Are there company-wide guidelines for critical elements of an application, such as the storage of passwords and all aspects of cryptography, which correspond to the state of the art? Can these defaults be easily and efficiently set by development? An organization is missing a great opportunity if the focus is solely on fixing the specific vulnerabilities.
Conclusion
Even though penetration tests cannot, in principle, provide a one hundred percent security statement, they are a good indicator of the resilience of a web application. Especially for applications with a lot of self-developed or commissioned code, a penetration test is helpful to avoid being part of the next data scandal.
Web applications have been experiencing enormous popularity for several years. The high availability and constant presence of (micro) computers and the Internet have given rise to an enormous variety of applications available everywhere – be it photo book services, the service for reserving a rental car, the purchase of online train tickets, or the booking of entire trips via web applications on the Internet.
Due to term-driven functionalities, security is often only suboptimally considered in web applications. As a result, systems are vulnerable and attacks can reach their target. And hacker attacks are every company’s nightmare: customer data is published on the Internet, customer confidence drops rapidly, clients migrate, sales plummet.
Attacks on web applications are one of the most common attacks on the Internet. Of hundreds of web applications tested, 62% have flawed authentication, 71% have flawed access rights, 94% are vulnerable to cross-site scripting (XSS), 78% have information leaks, and 92% are vulnerable to cross-site requests forgery (CSRF).
Penetration testing for web applications represents one of the most effective means to extremely increase security. Web applications are put through their paces by IT security testing. This increases the security of the application, ensures the confidentiality of the information, and prevents hacker intrusion. A penetration test can take anywhere from a few days to several weeks. In addition to the selected modules and test objectives, the scope of the test influences the effort required.
