Deserialisation vulnerabilities are often difficult to exploit. In most cases, you need access to the source code to identify the available classes or libraries used. This allows you to choose a suitable gadget chain or build a new one.

However, access to the source code is not always possible. It generally requires high privileges or the prior exploitation of another vulnerability.

As part of our internal penetration tests, we regularly encounter AD CS (Active Directory Certificate Services) infrastructures deployed on corporate networks.

This component always catches our attention, as inadequate configuration can quickly pave the way for total compromise of the Active Directory domain.

On many web applications, the option of uploading files is a standard feature.

Whether it’s adding a profile photo or sending a document, file upload simplifies user interaction. But this functionality is not without risks.

To improve the display speed of web pages and lighten server loads, many companies rely on caching mechanisms.

This system enables frequently requested resources (such as images, scripts or HTML pages) to be stored temporarily, so that they can be served up more quickly on subsequent requests.

SQL injections are well-known and widely documented vulnerabilities. They exploit flaws in relational databases to manipulate or extract sensitive data.

With the rapid growth of modern web applications, NoSQL databases have gained in popularity, offering greater flexibility and scalability than their SQL counterparts.

Denial of Service (DoS) are among the most common attacks on the web. There are many variants. One of them, which is particularly easy to exploit and inexpensive in terms of resources, deserves our attention: Slow HTTP attacks.

In this article, we will explain how a Slow HTTP attack works. We will also look at the main types of attack and the security best practices to prevent them.

When a client accesses a website, it communicates with the server through the HTTP protocol. Initially text-based, this protocol became binary with HTTP/2, but its operation is still based on TCP.

Each exchange begins with the creation of a connection between the client and the server. With HTTP/1.0, this connection was closed after each request. But with HTTP/1.1, the Keep-Alive mode became the norm, allowing the connection to be kept open for several successive exchanges.