Les signatures WAF sont conçues pour détecter les modèles d'attaque connus dans les requêtes HTTP ciblant les vulnérabilités serveur en analysant les requêtes entrantes. Les attaques côté client utilisent des requêtes HTTP complètement légitimes pour livrer du JavaScript qui ne devient malveillant que lorsqu'il s'exécute dans le navigateur. Souvent les attaques côté client sont récupérées par le navigateur de l'utilisateur depuis un point de terminaison tiers, ce qui signifie que le WAF du propriétaire du site web n'est même pas dans le flux de la requête, le rendant inutile. De plus, la charge utile malveillante est souvent obfusquée ou utilise une logique conditionnelle qui apparaît inoffensive dans la requête HTTP mais révèle ses intentions malveillantes uniquement lors de l'exécution dans un environnement navigateur spécifique que votre WAF ne voit jamais.
cside peut-il fonctionner avec mon WAF existant sans conflits ?
Nous surveillons une dimension entièrement différente de la pile applicative ; par conséquent, il n'y a pas d'interférence.
Comment cside résout-il l'angle mort côté client que les WAF ne peuvent pas traiter ?
cside analyse chaque script tiers de notre côté avant son exécution, facilitant l'arrêt des attaques en analysant le contenu JavaScript de manière asynchrone et en hachant une liste de mauvais scripts, les empêchant d'être rechargés.
Pourquoi l'environnement navigateur est-il invisible pour la surveillance WAF ?
Un WAF (Web Application Firewall) opère au périmètre, analysant le trafic lorsqu'il traverse entre les réseaux externes et votre réseau interne vers vos serveurs web.
Un WAF peut-il protéger contre les attaques de chaîne d'approvisionnement sur les bibliothèques JavaScript tierces ?
Les WAF ne peuvent pas protéger contre les attaques de chaîne d'approvisionnement côté client car ils n'interceptent pas la récupération vers le point de terminaison tiers et n'ont donc aucune visibilité sur les fichiers JavaScript des sources tierces.