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.
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.
What is a Mass Assignment vulnerability?
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.
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.
IDORs (Insecure Direct Object References) are widespread vulnerabilities in web applications in the same way as XSS or SQL injections. Affiliated with broken access control, IDOR vulnerabilities are indeed among those we most commonly discover and exploit during our web application penetration tests.
Principles, attack scenarios and exploits, we present in this article an overview of IDORs, as well as the best security practices and rights control tests to be carried out to prevent the risks.