Les vulnérabilités liées à la désérialisation sont souvent difficiles à exploiter. Dans la plupart des cas, il faut accéder au code source pour identifier les classes disponibles ou les bibliothèques utilisées. Cela permet de choisir une « gadget chain » adaptée ou d’en construire une nouvelle.
Cependant, l’accès au code source n’est pas toujours possible. Il demande généralement des privilèges élevés, ou l’exploitation préalable d’une autre faille.
Dans le cadre de nos missions d’audit interne, nous rencontrons régulièrement des infrastructures AD CS (Active Directory Certificate Services) déployées sur les réseaux d’entreprise.
Ce composant retient systématiquement notre attention, car une configuration inadéquate peut rapidement ouvrir la voie à une compromission totale du domaine Active Directory.
Dans le cycle de développement d’une application web, la sécurité ne doit jamais être reléguée au second plan.
Elle s’invite à chaque étape : dès la phase de conception, lors des choix d’architecture, tout au long du développement, mais aussi après le déploiement, au travers de tests continus.
Pour améliorer la rapidité d’affichage des pages web et alléger la charge des serveurs, de nombreuses entreprises s’appuient sur des mécanismes de mise en cache.
Ce système permet de stocker temporairement des ressources fréquemment sollicitées (comme des images, des scripts ou des pages HTML), afin de les servir plus rapidement lors de prochaines requêtes.
Sur de nombreuses applications web, la possibilité d’uploader des fichiers fait partie des fonctionnalités standard.
Qu’il s’agisse d’ajouter une photo de profil ou de transmettre un document, l’upload de fichiers simplifie les interactions utilisateurs. Mais cette fonctionnalité n’est pas sans risques.
Les injections SQL sont des vulnérabilités bien connues et largement documentées. Elles exploitent les failles des bases de données relationnelles pour manipuler ou extraire des données sensibles.
Avec l’essor des applications web modernes, les bases NoSQL ont gagné en popularité, offrant plus de flexibilité et une meilleure adaptabilité que leurs homologues SQL.
Les attaques DoS figurent parmi les plus courantes sur le web. Il en existe de nombreuses variantes. L’une d’elles, particulièrement simple à exploiter et peu coûteuse en ressources, mérite notre attention : les attaques Slow HTTP.
Dans cet article, nous présenterons les principes et le fonctionnement d’une attaque Slow HTTP. Nous verrons également les principaux types ainsi que les bonnes pratiques sécurité pour se prémunir.
Lorsqu’un client accède à un site web, il communique avec le serveur via le protocole HTTP. Initialement textuel, ce protocole est devenu binaire avec HTTP/2, mais son fonctionnement repose toujours sur TCP.
Chaque échange commence par l’établissement d’une connexion entre le client et le serveur. Avec HTTP/1.0, cette connexion était fermée après chaque requête. Mais avec HTTP/1.1, le mode Keep-Alive est devenu la norme, permettant de maintenir la connexion ouverte pour plusieurs échanges successifs.
WebSocket est un protocole de communication bidirectionnel en temps réel, conçu pour un échange efficace de données entre un client (navigateur web, application) et un serveur.
Contrairement aux requêtes HTTP classiques, qui nécessitent d’ouvrir une nouvelle connexion à chaque échange, WebSocket établit une connexion persistante. Une fois activée, elle permet aux deux parties de transmettre des messages en continu, sans interruption.
