Third-party components are omnipresent in web applications. Libraries, frameworks and other system components are used more and more, because they reduce costs and make development easier.
However, like any system, these third-party components may contain vulnerabilities that can be exploited in attacks on web applications. Furthermore, exploits that are discovered, and often made public, can have a snowball effect, compromising an entire web application, servers, database systems, etc.
Exploiting a RCE vulnerability for a pentester is something of a Holy Grail. Depending on the context, there are numerous techniques for executing code remotely and thus exploit a RCE.
Beyond the principle of this type of vulnerability, we present in this article examples of RCE attacks and exploitations, as well as best practices and measures to implement to protect yourself.
Before presenting practical examples of CORS misconfiguration, it is important to define several points. First, the principle of the Same-Origin Policy (SOP) will be explained, since the CORS mechanism modifies these rules by making them more flexible. We will then explain how CORS work. Finally, we will look at practical examples of improper configuration.
Most applications have a critical feature for identifying users. The aim is to guarantee the confidentiality and integrity of their data. Common methods used to enable the server to identify a user include session cookies, JSON Web Tokens (JWT) or, in some cases, customised solutions.
Clearly, the logic behind the generation of these session tokens is essential, because bypassing or hijacking them can lead to account takeover, with critical impacts on data security and even the total compromise of the system.
Faced with an ever-increasing number of internal attacks, network infrastructure security is a key factor in ensuring the confidentiality and integrity of data, as well as the continuity of an organization’s activities.
There are several ways of assessing the security of an internal network. In this article, we present the “offensive” approach, which we believe to be the most effective: internal penetration testing. We detail the principles and objectives, as well as use cases for black box and grey box penetration testing of an internal network.
When we visit a website, it is common to be able to browse different pages. Each page can be represented by a file on the server. In order to determine which file to provide, the application needs the client to specify which file it is interested in. To do this, sometimes the page the user wants is present in a request parameter.
Faced with an ever-increasing number of sophisticated attacks, web application security is a major challenge. Indeed, security is now crucial to reassure customers, build loyalty and convert prospects.
There are several ways of assessing the security of a web application. In this article, we present the “offensive” approach, which we believe to be the most effective: web application penetration testing. We detail the principles and objectives, as well as use cases for black box, grey box and white box penetration tests on various targets.
To make things easier for developers, many frameworks include features that automatically associate the parameters of an HTTP request with variables linked to an object in the application code.
A Mass Assignment vulnerability occurs when the server does not correctly filter the data transmitted by the user and associates it directly with an object without verification.
In a previous article, we reviewed the most critical and widespread vulnerability in web applications according to the OWASP Top 10: broken access control. Today, we tackle the common vulnerabilities and exploits related to the lack or absence of encryption in applications.
Recently, one of our clients asked us to review their Continuous Integration and Continuous Deployment (CI/CD) pipeline, deployed on an AWS infrastructure.
In this article, we will show how a developer with limited access to GitLab could have escalated his privileges and gained access to sensitive information to take control of the AWS infrastructure and cause significant damage to the organisation. We will also detail good practices and measures to implement to counter this type of risk.
In a previous article, we saw why it was important to store passwords in a database with robust hash functions such as Bcrypt and Argon2. This helps to render brute force or dictionary attacks completely ineffective.
However, a problem is regularly noted on already existing applications: how to use the latest recommendations on password storage on an existing database?
Access control is a central element in ensuring the security of web applications. It must be based on robust authentication and session management that takes into account various security risks, such as session hijacking.
XSS exploitation, session fixation, lack of encryption, MFA bypass, etc., there are many techniques to hijack a user’s session. In this article, we present the main attacks and exploits.
