Veuillez indiquer la source de la réimpression : Le dernier chapitre de l'analyse détaillée des attaques et des défenses de sécurité HTML5 : les améliorations de sécurité du HTML5
HTML5 apporte de nombreux ajouts aux anciennes stratégies de sécurité.
1. bac à sable iframe
HTML5 ajoute un attribut sandbox à l'élément iframe pour empêcher les pages Web non fiables d'effectuer certaines opérations, telles que l'accès au DOM de la page parent, l'exécution de scripts, l'accès au stockage local ou aux bases de données locales, etc. Mais cette stratégie de sécurité entraînera d'autres risques, ce qui est très intéressant. Par exemple, les attaques ClickJacking empêchent l'exécution de scripts JavaScript pour contourner les méthodes de défense JavaScript.
2. Politique de sécurité du contenu CSP
XSS contourne la politique de même origine grâce à du faux contenu et au clickbaiting. Le cœur de l’attaque XSS est que le navigateur ne peut pas distinguer si le script est injecté par un tiers ou s’il fait réellement partie de votre application. CSP définit l'en-tête HTTP Content-Security-Policy pour vous permettre de créer une liste blanche de sources fiables afin que le navigateur exécute et restitue uniquement les ressources de ces sources, plutôt que de faire aveuglément confiance à tout le contenu fourni par le serveur. Même si un attaquant parvient à trouver une vulnérabilité pour injecter un script, celui-ci ne sera pas exécuté car la source n'est pas incluse dans la liste blanche.
Le principe de l'attaque XSS
3. Filtre XSS
Les navigateurs modernes tels que Chrome et Safari ont également mis en place des mesures de défense de sécurité et fournissent des filtres XSS sur le front-end. Par exemple, http://www.php.cn/?;/p><script>alert(1)</script> ne sera pas exécuté dans Chrome, comme le montre la figure ci-dessous.
4. Autres
De plus, les applications HTML5 ont un accès plus restreint aux ressources système que Flash.
Enfin, les spécifications de sécurité spécifiques à HTML5 sont encore en discussion. Certaines personnes souhaitent les répartir dans différents chapitres des spécifications HTML5, et d'autres souhaitent les répertorier séparément. Il n'existe actuellement pas de contenu séparé, car il ne s'agit pas uniquement de la sécurité du Web. Les développeurs d'applications doivent être pris en compte, nous devons également prendre en compte les fournisseurs qui implémentent le support HTML5, les normaliser et les guider.
Je pense personnellement que les spécifications de sécurité de HTML5 seront expliquées dans un chapitre unifié et mentionnées en conséquence dans chaque module fonctionnel.
Ce qui précède est le dernier chapitre de l'analyse détaillée des attaques et des défenses de sécurité HTML5 : améliorations de la sécurité HTML5. Pour plus de contenu connexe, veuillez prêter attention au site Web PHP chinois (www.php.cn) !