Les WAF n'effectuent pas d'analyse de contenu des fichiers JavaScript, et surtout si la charge utile malveillante provient d'une URL tierce, le WAF ne serait pas dans le flux de la requête. Ils valident uniquement que la requête HTTP elle-même vers le serveur web semble légitime. Lorsqu'un script tiers est mis à jour avec du code malveillant, votre WAF le traite comme n'importe quelle autre mise à jour de ce domaine de confiance. Les WAF n'ont pas la capacité de hacher, analyser ou comparer les versions de scripts pour détecter quand un code légitime devient compromis, ce qui est exactement comme les attaques de chaîne d'approvisionnement comme Polyfill réussissent.
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.