Hacking III: Web application attacks

User authentication by password is often implemented in web applications. Individual users may be assigned different roles. As a payment service provider, for example, Dubius Payment Ltd. operates a payment gateway, where so-called “merchants“ can make credit card transactions. The merchant accounts are created by an administrator. Depending on the role of our user and his or her permissions, different functionalities of an application are thus available to us. In principle, every communication channel with a service or application is within our scope (attack surface). In terms of web applications, this comprises the following interfaces:

• User interface (UI) - forms and fields
• HTTP headers und cookies
• (Connected) application programming interface (API)

For the user interface (UI), the user input may be limited from the client side. The validity date of a credit card may be restricted through an HTML selection list, or the name of the credit card holder may be limited to a maximum of 100 characters. Generally speaking, it is also possible for restrictions to be implemented on the client side by using JavaScript, such as the validation of valid e-mail addresses. But none of the above precautions can keep us as the attacker from transmitting “forbidden values“ to the application via these fields. Because client-side limitations can be circumvented via a so-called web application proxy by intercepting our outgoing HTTP request with the proxy and editing all parameters after the fact. The Burp Suite can be used for this (https://portswigger.net/burp). The freely available edition of Burp includes a proxy and repeater, among other things. To use Burp as a proxy, we must additionally configure it in the network settings of our browser. Using Burp’s repeater, we can then intercept requests in order to modify them in various ways and resend them.

But all of this is only of value if we actually have an application for testing. It is possible that we will only encounter static pages, such as the Apache homepage “It works“ or the server-side response “403 Forbidden“ in response to an HTTP request. But that doesn’t mean that there is no application on the web server. It may only mean that we have not yet found the right directory. The payment gateway of Dubius Payment Ltd. may be hidden behind https://paygate.dubius-payment.com/transaction/. Using the ffuf tool, we can automatically search for existing and hidden directories or files using word lists:

ffuf -w ${word list} -X GET -u ${URL}/FUZZ

Once we have found a web application, we can try different attack vectors to penetrate the IT system. A detailed list of possible vulnerabilities is provided by the OWASP Testing Guide (https://owasp.org/www-project-web-security-testing-guide/). Next, we will take a closer look at SQL injection and cross-site scripting attacks, as these occur often.

The internal PCI DSS documentation of Dubius Payment Ltd. can be viewed in the company’s Wiki and be supplemented with TODO points. The software used for this has a known web application vulnerability. A hacker will find and use this in order to execute instructions on the IT system. But a pentester will find at least three more vulnerabilities in the web application. Are you only a vitriolic hacker or a professional penetration tester? ;)