Most web applications manipulate personal and/or business data, in other words, sensitive data. Passwords, email addresses, credit card numbers, health data and others are at the centre of the battle between two opposing sides. On one side, companies, whether small, medium or large, seeking to defend themselves against intrusions into their information systems, and on the other, increasingly experienced attackers, attracted by the lure of gain and stimulated by the many breaches too often ignored by their future victims.
Web Applications, Main Targets of Cyberattacks
Being exposed to the public, web applications naturally have a large attack surface and maybe features with a large number of various potentially vulnerable elements. Even on a secure web server running on an operating system that is known to be safe, security flaws may remain because they are mostly due to programming errors in the application itself or errors in the configuration of the server hosting it.
In this first post, in a series of articles dedicated to the most common flaws encountered during our penetration tests, we will focus on vulnerabilities in the application layer of web platforms. We will cover server and API security in upcoming articles.
Moreover, this article is not a “incriminating” judgement, in the sense that we are aware of the challenges faced by many developers, CTOs or CISOs: budget, availability, organisation, etc. Nor is it an “absolution”, as attacks very often succeed due to carelessness that could easily be avoided. The objective of this article is to show why it is important to pay particular attention to security, from the design phase, throughout the development and lifecycle of your web applications to protect yourself against increasingly numerous and sophisticated attacks.
Implementing security measures tailored to your challenges, raising awareness or training your developers and employees, performing penetration tests are all means available to strengthen your security and counter the attacks that we present in this article.
What Are the Most Common Vulnerabilities in Web Applications and How to Protect Yourself?
Authentication Feature and Brute Force Attacks
Of course, a web application can be attacked head-on. Targeting the authentication feature is the most direct and obvious attack. The most common attack against authentication systems is brute force. In this case, an attacker, through the use of specific tools, bombs an authentication page with username and password values until they obtain access to a web application.
This type of attack is made easier if the error message of authentication failure gives the origin of the error. For example, “the user does not exist” allows the attacker not to attempt to enter passwords for that user who is not in the database. “Incorrect password” allows the attacker to focus on that user, saving him/her a lot of time.
There are many variations of brute force attacks. Password spraying, which involves testing a limited set of passwords on multiple accounts, is one of them. In this case, attackers attempt to gain access to a platform by testing a small number of commonly used passwords on a large number of accounts. They assume that within a large group of people, there is likely to be at least one person using a common password, and unfortunately this is too often the case.
This slower approach allows them to attempt to access multiple accounts without being blocked, which could alert the target of the attack. A concrete example of a password spraying attack that we performed during a black box penetration test on a SaaS application:
- Extraction of LinkedIn company profiles
- Creation of emails from the last name, first name and pattern [email protected]
- Password spraying on the Backoffice using a small list of passwords: Company, company, company2021, Company2021, company2021, Company2021! and company2021!
- Getting an administrator account with access to the Backoffice
- Extraction of the list of all users with access to the Backoffice
- Password spraying again, which has enabled us to obtain other accounts.
Brute force attacks are fearsome and are not to be taken lightly. It is advisable to implement technical measures against them, such as:
- Secure the authentication mechanism by limiting the number of invalid logins and increasing the delay after and between each login attempt.
- Implement a multi-factor authentication system (at least two factors) to ensure that the login process is performed by a person and not a bot. This may be an answer to a secret question, the entry of a code received by text message, or a validation through a captcha.
Other basic measures (strong password policy, generic error messages, regular log review, etc.), continuous awareness-raising and training on web security are good ways to prevent this type of attack.
Management of Access Rights and Privileges Escalation
Users of an application are expected to be trustworthy and to respect the security policies. But are they always? Legitimate users have many potential reasons to become “malicious” at certain times:
- To avoid a procedure that they do not understand and that they can bypass, by using a feature they are not supposed to have access to
- To access another user’s data for various reasons
- To access features only available to a group of users, such as using free services for which a fee is charged, for example
Access rights management is a key element in the security of web applications. It is certainly the most targeted aspect by malicious attackers, wishing to “escalate their privileges” to achieve their ends. Privilege escalation occurs when a user exploits a flaw, design flaw or configuration error in an application, to gain high access to resources that should normally be inaccessible to him/her. He/she can then use the newly acquired privileges to steal sensitive data, execute administrative commands or deploy malwares; and potentially cause serious damage to your information system and your brand image.
Typically, attackers begin by exploiting an access rights vulnerability in a target system or application, allowing them to override the limitations of the current user account. They can then access another user’s features and data. Then their goal will be to obtain high privileges, usually those of an administrator (the Holy Grail!) or another powerful user.
A concrete example that we performed during a grey box penetration test on a SaaS application:
- Access to a standard user account in the production environment, with limited actions in the Backoffice: consulting documents, sending requests of various types through workflows, etc.
- Thanks to a bug in the Backoffice related to URL parameters, it was possible to access features only available to the support team, especially the rights to update the email addresses of all other users (including people with super admin rights on the Backoffice).
- With these newly acquired features, it was possible to modify the email of a super admin and to reset the password through the email notification received in this regard.
Fortunately, this critical vulnerability was discovered through a penetration test. There is no need to specify how disastrous the consequences would have been for the company if such an attack had ever occurred.
Applications are the easiest entry point for any attack, so it is vital to secure them: implement best development practices to avoid programming and configuration errors, use vulnerability scanners to check whether your applications are fallible, and perform penetration tests to ensure that the implemented rights levels are well partitioned.
Exploitation of XSS Vulnerabilities
Let’s suppose that the Backoffice door of a web application is robust, and its enclosure protected by impenetrable bulwarks. “Diehards” attackers will then turn to the front-office to try to inject malicious content into the application through any available field or data sending system.
Cross Site Scripting (or XSS) is a common vulnerability in web applications which, if properly exploited, can be used to hijack a session, replace part of the user interface, download malwares [etc.] through code injection (JavaScript, HTML, CSS). There are 2 types of XSS attacks:
- Stored XSS attacks that send malicious content to the server hosting a web application so that it can be sent back to the users’ browser.
- Reflected XSS attacks that do not store the malicious content on the web server but deliver it to the users through a URL or directly on the browser.
In short, all XSS attacks are based on sending malicious content displayed on the browser of the users of a web application, in the form of a pop-up or a redirection to an external website.
It is difficult to detail all the possible consequences of XSS attacks, the list would be very long. To protect yourself against them, you have to assume that data received by a web application cannot always be considered safe. It is important to follow strict rules when processing data coming from outside. All content must be cleaned, validated and/or encoded before being used by the application. Vulnerability scanners can identify some of these vulnerabilities, but a penetration test or code review will be more exhaustive.
SQL Injection Attacks
Injection attacks are made easier by the very functioning of web applications, as they need data to operate. And the more data is needed, the more opportunities there are for injection attacks.
A common vulnerability: SQL injection flaws, which allow interaction with an application’s database through unexpected queries. These flaws can lead to data theft, data loss, deletion or manipulation of stored data.
Security of Interconnected Systems
Web applications are often interfaced to third-party services or systems, mostly to enable data sharing. For example, most FinTech companies use payment systems, developed and distributed by third parties, to integrate them into their in-house web applications. These payment systems are usually secure because there are many security standards in the field of electronic payment, PCI-DSS for example.
However, a third-party application can be robust in terms of security, but vulnerabilities very often appear due to a misconfiguration and/or mis-implementation of the interconnection system (web services, API: we will detail the most common flaws and best security practices for APIs in our next article).
Security of Third-Party Components
Third-party components are one of the attackers favourite hot spots because most web applications incorporate them. Using libraries or frameworks is common practice. It enables to develop applications faster and easier, with the support of an active community. However, these third-party components are exposed to web attacks. And to make matters worse, the more popular a component is, the more it is targeted by attacks. Indeed, when a security flaw is discovered on a component, it often becomes public.
The solution: a patch is developed to correct this flaw in the new version, which will usually be installed by developers using these third-party components. The problem: attackers also wait for updates containing details of the vulnerabilities discovered, in order to quickly launch attacks on critical components.
As with any other application, there are many possible vulnerabilities (injections, XSS, authentication flaws, etc.). An example encountered during a grey box penetration test on a SaaS application that manages corporate financial data:
- Closed platform from the point of view of an external attacker, only an authentication form was accessible
- After in-depth tests and extensive research into the third-party components used, we identified a javaScript library
- As the installed version was outdated, it had a known vulnerability that made it possible to read any file present on the server hosting it
- By exploiting it, it was possible to extract many sensitive files from the web server, and ultimately to access all the data managed by the web platform.
To counter these attacks, we advise you to limit the use of third-party components as much as possible, if you have the resources allowing you to do without them. You will always have more control over the security of an in-house development than an external component.
If this is not possible, it is important to maintain an up-to-date list of the third-party components used on your web application and their versions. This will facilitate the identification of vulnerable components and your development team will be able to act if necessary, with a precise knowledge of the elements used. To do so, it is advisable to ensure a technical and technological watch to monitor new versions available and vulnerabilities discovered on the third-party components used. Subscribing to project mailing lists (those of the components used), or security mailing lists are all ways of staying informed and on the alert.
Beyond the Technical Flaws, the Often Forgotten Logical Flaws
Technical vulnerabilities are inherent in web applications. Beyond these vulnerabilities, there are also logical flaws that are related to workflows and undetectable with automatic tools (scanners and others). What is a logical flaw?
A logical flaw exists when the normal operation of an application, i.e. a logical step or intended process, can be avoided or bypassed. A concrete example of a logical flaw discovered during a black box penetration test on an e-shop:
- Creating an account to make purchases on the platform
- Adding products to the basket and then going to the basket validation step
- Changing the price of the products added to the basket (without changing their references) by directly editing the HTML code, which resulted in a decrease in the “displayed” value of our basket
- Lastly, it was possible to validate the payment of our basket (at a reduced rate), as the price indicated in the payment request sent to the bank took as a reference the price of the basket displayed in our browser
This was possible because the platform did not perform any verification and relied on user input. To prevent this, it is recommended that the server specifies the price to be paid to the bank according to the reference of the desired products. The display of the user-side price should only be a visual indication and not a value to be taken into account.
In summary, logical flaws are usually the result of a design defect in web applications or a lack of in-depth testing from a security angle. And if there are security tests, it is important to focus on what the application is not supposed to achieve in order to detect its logical weaknesses.
To do so, it is essential to have a good understanding of the expected behaviour of the application, the business logic and rules, the resulting security controls, and therefore the risks of functional abuse, then to be creative in building unexpected scenarios, and finally to test them on the application.
Performing Web Application Penetration Testing to Assess and Reduce Security Risks
Web application penetration tests are the best solution for dealing with computer attacks. Isn’t it said that the best defence is offence! This maxim perfectly sums up the principle of penetration testing, which consists of testing the security of an application or another system by performing various attacks in order to identify potential technical and logical vulnerabilities.
There are three possible approaches to web application penetration testing: black box tests, grey box tests or white box tests. These approaches relate to different levels of information and access provided to pentesters. Black box penetration tests target the attack surface accessible to any external attacker, while grey box penetration tests will concern elements available with access provided by the Client. A white box penetration test enables the level of security to be analysed by having all or part of the application’s source code and access to the infrastructure hosting it.
Web application penetration tests are used to search for vulnerabilities related to the configuration of web servers as well as flaws in the application layer. On the server side, these include, for example, open and poorly secured services, out-of-date software or configuration errors. We will discuss these in our next article. On the application side, these are the vulnerabilities listed by the OWASP (the Top 10 vulnerabilities, some of which were discussed above), as well as logical flaws.
A detailed report is provided following a penetration test. This deliverable includes the methodology used, the vulnerabilities identified (classified by level of criticality: low, high, critical), the possible exploitation and recommendations for remediation. A presentation of the results of the audit by the pentester(s) in charge helps discuss the findings of the security audit.
At Vaadata, we are democratising penetration testing with offers designed for both start-ups and large companies. It is just as possible to perform an initial one-day penetration test for €675 (including report and presentation of results), as it is to perform a more in-depth audit with a budget between €2500 and €10,000 (rate determined according to the functional and technical complexity and your web application, as well as the desired level of depth).
Contact us for any question about a penetration test project on your web application. We will discuss your needs and provide you with a solution tailored to your security challenges and your constraints, whether budgetary or organisational.