We do pentests every day. (Well, 5 days a week.) Today we’re taking you behind the scenes: we’ve got a closer look at the penetration tests performed in 2020, to share with you some figures on the vulnerabilities found.
We have also identified the three most frequent vulnerabilities found during our pentests and give our insight on the presence of these flaws. Finally, we present some other observations from our penetration tests.
Statistics on pentests performed by Vaadata
Specialised in penetration testing, we perform web solutions, mobile applications, company internal networks, connected devices and social. The following statistics only reflect our activity and are only one insight in a much larger cybersecurity environment. This article on cybersecurity statistics 2021, for example, gives a more global overview.
Concerning our client typology, almost 50% are startups (from early stage to series C or higher). A third are medium-sized or intermediate software companies, and the rest are divided between large companies and SMBs in various sectors. Our perspective is therefore mainly on the security of startups, compared to the perspective of other pentest companies.
We have conducted around 200 penetration tests during 2020 and about 40% of the pentest were performed for repeat clients.
We noted that:
- 29% of targets had at least one critical vulnerability,
- 44% had one or more important vulnerabilities,
- 47% had one or more medium vulnerabilities,
- 62% had medium, important or critical vulnerabilities.
On average, we found during each penetration test:
- 0.7 critical vulnerabilities,
- 1.3 important vulnerabilities,
- 1.5 medium vulnerabilities,
- 2.9 weak vulnerabilities,
- 0.7 vulnerabilities of information level.
It is difficult to compare the results of the 200 pentests with each other, as the scope and depth of the tests are different for each situation. Some ‘quick’ pentests where few flaws were reported could have had different results by extending the scope or adding time to investigate further.
Various elements must be taken into account to determine the security maturity of the test target (technologies used, company security culture, processes, individual skills within the team, etc.).
From a more global point of view, on all the flaws found,
- 11% were critical vulnerabilities,
- 19% were important vulnerabilities,
- 20% were medium vulnerabilities,
- 40% were weak vulnerabilities,
- 10% were information level vulnerabilities.
The risks of a security flaw are estimated by considering the probability of exploitation of the flaw and its potential impact. The security stakes are decisive and taken into account to establish the criticality of a vulnerability. Giving a clear assessment of the criticality level facilitates the prioritisation of corrections.
20% of pentests were followed by a verification phase. This phase makes it possible to complete the pentest by checking that all the flaws have been corrected, but also that the fixes are effective and have not created new security problems (side effects).
The three most frequently found vulnerabilities during a web penetration test
We perform pentests on a wide variety of targets, whether in terms of functional context, business or type of pentest conducted.
Most of our work is web penetration tests, as these targets have a high level of risk exposure. They are often vulnerable parts of information systems, and their attack surface is potentially large.
On these web pentests, we have noted that the three most frequently encountered vulnerabilities are
- Cross Site Scripting (XSS),
- missing access controls (privilege escalation, partitioning of data between users…),
- lack of rate limiting.
Knowing what the most common vulnerabilities are makes it possible to verify and strengthen elements that often create vulnerabilities. The aim of this article is to highlight them and to encourage you to pay attention to these elements to limit the risks.
Most frequently found vulnerabilities: Cross Site Scripting (XSS)
These flaws have been known and studied since the 2000s. But they are still frequently found and do not show signs of disappearing soon. The impact of this attack can be important. An XSS can be exploited to compromise the content of a page to retrieve sensitive information, to steal session tokens, etc.
More than the choice of language or technology used, we found that the presence of XSS vulnerabilities depends mainly on how the solutions are implemented. Several factors explain why these flaws are still present:
- We have observed a lack of awareness. Not all developers are necessarily trained in the risks associated with XSS and the impact of these vulnerabilities is sometimes not perceived correctly.
- We noted a lack of use of frameworks. Frameworks integrate and manage many security elements. When a site or an application is coded without a framework, it is unfortunately easy to write code that is vulnerable to XSS and to overlook the verifications and controls of the data received.
Frameworks are not yet used in all situations. They need to be learned to be used and this comes later when developers learn to code. It sometimes happens that companies have developed their solutions without a framework at the beginning, depending on the skills in the teams. When these companies grow, it becomes difficult to change everything to use a framework.
- We have also had situations where frameworks are used, but modified by the development teams, which has led to flaws. The frameworks have built-in protections, but it is possible to manually disable the protection. For example, with Symfony, you can activate the html so that the tags are interpreted, but this creates risks. It is then necessary to clean up what will be displayed.
How to protect yourself from Cross Site Scripting (XSS) vulnerabilities
To counter these flaws, we recommend that user data be encoded on output. All user input should be HTML encoded when it is reused in the web page of an application. For example, the characters < and > will be replaced with the corresponding HTML entities, i.e. < and > respectively.
As an option, you can also filter and validate the incoming data. This involves processing the data sent by users before accepting it. For example, in a form, it is possible to set filters so that the postcode is only five digits.
However, this solution should not be used on its own, as this is like applying a blacklist filter, and it’s easy to forget to include some dangerous items.
To learn more about Cross Site Scripting protection, OWASP provides a very good cheat sheet that details different encoding.
Technical teams can identify XSS flaws during manual code review or by automatic tools.
Most frequently found vulnerabilities: missing access controls
Access controls check whether the user is authorised to perform the requested action. There are multiple places where access controls are implemented and the workflows are sometimes subtle, that’s why this is a vulnerability we find very frequently.
Rights problems do not depend on the complexity of the solution (multiple levels of rights, various profiles that can be modified as needed, etc.) or on business functionalities. We found that there is rather a lack of awareness of these flaws. It is often forgotten that during exchanges between the client and the server, requests are easy to manipulate. It is possible, for example, to change a credential, to reuse a cookie in an unintended place, etc. if there are no suitable controls.
We observed that the access control flaws are most often related to insufficient or even no controls, not to poor implementation of controls. When there are authorisation controls in place, they are generally properly implemented.
Enforcing access controls
This vulnerability occurs when controls can be manipulated, bypassed or are insufficient, in order to achieve new functionality or other data.
There are in fact two types of data access control problems:
- vertical: in a system where there are different levels of access rights (user, manager, admin), the attacker tries to obtain the highest possible privileges, as this gives access to more functionality. Depending on the business, this may involve creating or deleting users, validating financial flows, accessing confidential data, etc.
- horizontal: in an application where there are different user accounts, the attacker tries to reach the data or resources of other users.
To protect against these vulnerabilities, one of the principles is to consider that access and resources are not authorised by default. Controls should then be put in place to check whether the user is allowed to do a certain action at a certain time. Final control must always happen on the server side, whether or not there is a check on the front side.
You can choose different methods of access control: role-based, organisation-based, attribute-based, etc. OWASP has a cheat sheet detailing the advantages and disadvantages of these different access control methods.
To identify these flaws, development teams can replay requests, for example with Postman. It is important to thoroughly test and audit the controls that have been put in place to ensure that they are working as intended.
Most frequently found vulnerabilities: lack of rate limiting
The lack of rate limiting is a vulnerability that we encounter very frequently. It is of low level or information and is mainly found on APIs and on some functionalities, like login, password reset…
Our explanation guess for this flaw is that as the impact is moderate, it is sometimes overlooked. Furthermore, the limits can be set in different places and in different ways, so it may seem like a lot of effort for such a vulnerability.
This flaw requires putting limits at the hosting level or in the application, in order to reduce load and protect the endpoints.
Implementing rate liming
Rate limiting, as its name suggests, limits the number of times an operation can be executed. It is used to protect against excessive use to maintain service availability and to avoid abuse of some functionalities (for example, email functions)
Lack of rate limiting can cause denial of service or slow the execution of the desired operation, but also allow brute force attacks.
To protect yourself, we advise you to set up a global rate limiting. This means setting a maximum number of possible requests per IP.
It is also possible to combine rate limiting per IP and per user.
Observations based on the pentests performed by Vaadata
We were also able to draw some more general observations from our experience. First, there are no languages where flaws are more frequent because it is a particular language. It is possible to have a secure solution with any language, the important thing is to choose a language adapted to your needs.
Secondly, the level of security isn’t determined by the functionality of the target. A site where you can only put comments can be secure, while another with an administrator panel isn’t. The security level of a solution depends much more on the company’s investment in security, if it is a priority and resources have been allocated to the teams.
When the company’s processes and project organisation include security, it is possible to transfer the security knowledge acquired during a pentest to untested targets. The recommendations following a pentest are then applied to new developments, to other assets of the organisation, etc. In this way, the company can strengthen its overall security level and become security mature.
Finally, we have noticed that the security of internal networks is often less robust than the security of web applications for example. Indeed, the internal network is still considered as a less risky element of the information system, because it is less exposed. Besides, network technologies are older: they were designed with little security as a priority and may be less easy to secure at first glance.
But with the spread of IoT and the increase in ransomware, the situation is changing. The risks to the infrastructure are now increasing and a secure network is becoming essential to ensure the smooth running of a business. Fortunately, it is entirely possible to have a secure infrastructure by following the current recommendations.