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.
During a web application penetration test, we discovered a vulnerability related to the configuration and mismanagement of access controls on GraphQL.
In 2021, the OWASP top 10, which highlights the most common vulnerabilities in applications, has slightly changed. Injection vulnerabilities, previously the most critical, are now in third place.
One reason for this is that developers are becoming more aware of the risks associated with injection vulnerabilities through the implementation of more secure application development tools and practices. And of course, the most important measure to mitigate the risk of SQL injection is the use of prepared statements.
This is usually done using an ORM, which can introduce new risks as we will see in this article.
When developing a game, you may need to save a player’s run to a file so that you don’t lose their progress and they can return to where they left off. Similarly, when developing an online text editor, you may want to preserve the content that the user has written.
Indeed, there are many cases where we want to save the state of our application to restore it in the future. Two terms are used to define this process: serialization and deserialization.
Deep links are predefined URIs (Uniform Resource Identifiers) that allow direct access to an activity in a web or mobile application when clicked.
These links are usually found on pages within a web application or in the webviews of a mobile application. When the user clicks on a deep link, and has the application to open that type of link, a popup suggests opening the link with the corresponding application.
During a penetration test, we came across this situation:
