Aspect de sécurité Web côté client

La traduction de l'article a été préparée en prévision du début du cours "Sécurité des applications Web" .








Dans cet article, le premier de trois, nous examinerons les menaces de sécurité Web et la façon dont les outils de sécurité côté client gèrent une classe de cyberattaques souvent négligée comme Magecart . Il décrit les techniques traditionnelles de défense contre les menaces de sécurité Web basées sur des normes côté client telles que la politique de sécurité du contenu et l'intégrité des sous-ressources. Ces approches évolutives sont considérées dans le contexte d'une plate-forme de sécurité représentative côté client.



introduction



La variabilité continue est peut-être la pierre angulaire de la cybersécurité en tant que discipline professionnelle. En d'autres termes, dès l'apparition de cyberattaques affectant la confidentialité, l'intégrité ou l'accessibilité de certaines ressources Internet, des solutions appropriées sont développées pour les éliminer. Dès que ces solutions sont intégrées dans l'infrastructure de la ressource compromise, de nouvelles cyberattaques apparaissent, de nouvelles solutions sont inventées et le cycle se ferme.



Dans certains cas, les solutions cyber-défensives disposent de mécanismes qui anticipent de nouvelles formes d'attaques malveillantes - et lorsque cela fonctionne, les risques de sécurité peuvent être évités dans une variété de scénarios. Par exemple, l'authentification à deux facteurs a été créée pour lutter contre la devinette des mots de passe et constitue désormais un élément de sécurité important dans le développement de nouveaux protocoles de communication entre les appareils IoT .



Nulle part le processus d'émergence et de maîtrise des menaces n'est plus évident que dans le domaine de la sécurité Web, également appelé sécurité des applications Web. Étant donné que les actifs précieux sont le plus souvent traités et gérés via des interfaces Web, la valeur des exploits Web continue de croître. L'une des conséquences de cette croissance est que malgré les nombreuses technologies de protection des ressources web, l'écart entre le nombre d'attaques et le niveau de protection se creuse.



La prémisse principale de cette série d'articles techniques est une lacune de sécurité Web qui découle du fait que la plupart des applications fonctionnent dans des navigateurs modernes. La communauté de la sécurité Web reconnaît depuis longtemps la nécessité de déployer des fonctionnalités pour se protéger contre les vulnérabilités côté serveur servant des contenus statiques et des contenus aux clients. Cependant, trop peu d'attention est accordée à la sécurité côté client, qui n'est pas moins attrayante pour les attaquants, mais est largement ignorée par l'infrastructure de sécurité moderne.



Dans cette série en trois parties, nous voulons combler cet écart. Dans la première partie, nous parlerons des cyberattaques les plus courantes sur les sites Web. Dans une deuxième partie, nous examinerons les solutions de sécurité Web qui sont le plus souvent déployées en production aujourd'hui. Et dans la partie 3, nous explorerons comment une solution de sécurité représentative côté client peut vous aider à trouver des vulnérabilités dans votre infrastructure qui pourraient être exploitées par des attaquants.



Attaques courantes sur les sites Web



Au milieu des années 90 du siècle dernier, en même temps que les idées de Tim Berners-Lee, du niveau des protocoles de transfert hypertexte et des langages de balisage au protocole Internet (IP), il y avait aussi des moyens d'attaquer les infrastructures, les systèmes et les applications qui composent le soi-disant web ou réseau (web). Puis est née une discipline telle que la sécurité Web, qui peut être définie comme un ensemble de mesures de protection nécessaires à la gestion des risques dans le domaine de la sécurité informatique en réseau.



Comme vous vous en doutez, la taxonomie des problèmes de sécurité Web a évolué rapidement dans différentes directions, mais les premières étapes se sont concentrées sur la prévention des attaques par déni de service, la sécurisation de l'infrastructure d'hébergement et la garantie de la libre circulation du contenu Web vers les utilisateurs. Cette focalisation sur l'accessibilité a été motivée par le fait que si un site Web est en panne ou ne fonctionne pas comme prévu, les transactions électroniques ne pourront pas se dérouler en toute sécurité, avec des revenus évidents.



Outre les problèmes au niveau de l'infrastructure, il a été pris en considération que les problèmes au niveau de l'application peuvent également avoir des conséquences graves, en particulier pour les clients qui visitent un site Web. Ainsi est né le soi-disantmenace dans le domaine de la sécurité des réseaux , qui est passée d'un petit problème à un grand problème de sécurité. Aujourd'hui encore, trouver une application Web vulnérable est assez simple.



Au cours des dernières années, un ensemble standard de stratégies d'attaque a émergé qui sont extrêmement difficiles à supprimer. La persistance de ces problèmes est due à la complexité du développement de nombreuses applications Web, ainsi qu'à l'inexpérience et à l'ignorance relatives de nombreux administrateurs réseau. Ci-dessous, nous décrivons quatre stratégies qui conduisent à des vulnérabilités dans l'infrastructure de commerce électronique et posent des défis à de nombreuses entreprises et à leurs équipes de sécurité.



Scripts intersites (XSS)



L'attaque la plus courante au niveau de l'application est l'écriture de scripts intersites, ou simplement XSS . À la base, une attaque intersite comporte une méthode telle que l'injection - c'est à ce moment qu'un attaquant trouve un moyen d'intégrer un script tiers dans le site et de le faire fonctionner. Le but ultime est que l'application web ciblée envoie le code de l'attaquant au navigateur de l'utilisateur à l'insu de ce dernier. Une attaque XSS fonctionne mieux lorsqu'un site Web accepte, traite et utilise des entrées sans grande vérification.



Le but ultime est d'injecter du code dans le navigateur de quelqu'un d'autre. L'utilisateur compromis s'attend à ce que tous les scripts à venir soient sûrs, car tout le contenu dynamique provient du site Web visité et censé être fiable. Le navigateur de l'utilisateur exécutera ce code, souvent en JavaScript, exposant ainsi des informations sensibles telles que des jetons de session ou des cookies à un attaquant. Le code XSS peut également rediriger l'utilisateur vers un site infecté.





Figure 1. Diagramme d'attaque XSS Des



organisations telles que l'Open Web Application Security Project ( OWASP) offrent diverses protections contre les attaques XSS. Leurs recommandations, dont beaucoup sont encore ignorées par les praticiens, incluent des procédures de codage et d'administration Web significatives qui améliorent la gestion des entrées des utilisateurs. La plupart d'entre eux impliquent une meilleure validation des entrées côté serveur, ce qui est une mesure de sécurité bienvenue et devrait être présente dans tout écosystème réseau.



Contenu et injection d'annonces



Récemment, les attaques liées à l'injection de contenu et de publicité, connues sous le nom de malvertising, sont devenues de plus en plus courantes . Cette tendance, cependant, ne devrait pas être une surprise étant donné la montée en puissance de l'écosystème de la publicité en ligne en tant que moteur des activités d'aujourd'hui. On estime que la publicité en ligne atteint actuellement 100 milliards de dollars. Les pirates informatiques et les criminels sont conscients de cette tendance et tirent parti des vulnérabilités disponibles.



Comment fonctionne la malvertisingsimilaire à XSS: les attaquants trouvent un moyen d'injecter leur code dans des sites Web via des réseaux publicitaires légitimes. Le but est également similaire à XSS, il est de rediriger les visiteurs d'un site vers un autre site cible avec un code malveillant, qui est le principal de toute attaque, comme par exemple le vol d'identité.



Certaines personnes parlent du processus d'injection comme d'un téléchargement au volant . Ce terme fait référence à un utilisateur qui consulte les annonces dans un navigateur présentant une vulnérabilité (ce qui, malheureusement, est un scénario très courant). Lorsqu'un utilisateur interagit avec une publicité, une redirection se produit, à la suite de laquelle un logiciel malveillant parvient à un visiteur du site Web sans méfiance.





Figure 2. Téléchargement au volant via une publicité malveillante

La solution traditionnelle à ce problème consiste à utiliser un contrôle tel qu'un pare-feu d'application Web (WAF). WAF sera configuré pour utiliser une analyse comportementale ou basée sur les signatures pour arrêter l'exécution de code malveillant provenant de sources non fiables. Comme avec XSS, cette protection côté serveur est couramment utilisée dans les écosystèmes publicitaires comme élément de contrôle clé. L'approche décrite s'applique à la malvertising , mais ne fonctionnera pas contre toutes les formes d'attaques.



Magecart



Le groupe de hackers Magecart est né il y a plusieurs années, après avoir commencé à terroriser les sites Web avec une attaque telle que l'écrémage de cartes. Habituellement, les groupes de pirates informatiques apparaissent et disparaissent assez rapidement, mais Magecart a longtemps rendu les sites Web et les applications Web des entreprises nerveux. Un grand nombre d'organisations ont été touchées par des piratages et les solutions de sécurité n'étaient pas évidentes pour la plupart des victimes.



Attaque l' homme au milieude Magicart est assez simple: tout d'abord, le code malveillant est ajouté au code JavaScript qui est envoyé du serveur au client. Le code malveillant traque et collecte ensuite des données sensibles, telles que les informations de carte de crédit des utilisateurs qui visitent le site via leur navigateur. Les données sont envoyées à un site malveillant et téléchargées illégalement. Tout est très simple.





Figure 3. Écrémage des cartes de Magicart



Cependant, le principal problème est que la sécurité côté serveur habituelle ne prend pas en compte l' attaque man-in-the-browser ( MITB ), car elle se produit côté client. Par exemple, les pare-feu d'application Web ( WAF) ne voient pas les actions JavaScript et ne disposent pas d'outils d'analyse de bibliothèque pour les injections de code. Lorsqu'une attaque provient de sites tiers, le résultat est en cascade et ce qu'on appelle le ferroutage se produit .






En savoir plus sur le cours.







All Articles