Introduction
La sécurité des utilisateurs et de leurs données personnelles lors de l'utilisation d'une application Web est primordiale. Bien que ce principe directeur ait été reconnu dès les premières étapes du développement Web, les acteurs malveillants trouvent des failles dans les applications et peuvent exploiter vos utilisateurs.
De nombreuses attaques « standard » sont bien connues et documentées, et il n'est pas difficile de s'en protéger. Pour décharger le développeur de la mise en œuvre de pratiques de sécurité lui-même, des frameworks comme Spring Boot ont fait abstraction de diverses mesures de sécurité et vous permettent d'appliquer simplement des filtres de sécurité dans vos applications pour empêcher les attaques bien connues.
Dans ce petit guide, nous examinerons ce qu'est le Cross-Site Scripting (XSS), comment quelqu'un pourrait effectuer cette attaque sur votre propre application et comment vous pouvez l'empêcher facilement avec Spring Boot.
Qu'est-ce que le Cross-Site Scripting (XSS) ?
Le Cross-Site Scripting est un exploit bien connu et largement répandu, dans lequel un mauvais acteur injecte un script dans une application Web.
En règle générale, une politique de même origine est appliquée aux applications Web, ce qui limite les scripts d'une page Web à accéder aux données des sources si leurs origines ne correspondent pas. Dans le cadre de la politique de même origine - si une page d'un site Web de confiance peuvent accéder à des données d'interface avec l'utilisateur (telles que des cookies, par exemple), d'autres pages de même origine peuvent également le faire. Cette forme de contrôle d'accès semblait suffisante pour protéger l'intégrité des données sur les applications Web à l'époque.
Cross-Site Scripting contourne la politique de même origine, en injectant un script malveillant dans la page d'un site Web de confiance. Étant donné que le script est exécuté à partir d'un site Web de confiance, il est exécuté en tant que script de confiance. Il n'existait aucun moyen clair de différencier les scripts malveillants des scripts non malveillants. L'exécution de code arbitraire était donc possible avec le Cross-Site Scripting. Cela va de l'insertion d'alertes gênantes aux attaques d'ingénierie sociale, en passant par la collecte silencieuse d'informations sur les utilisateurs ou la redirection des utilisateurs vers des pages de phishing qui semblent faire partie de sites Web de confiance.
Merci beaucoup les sites Web sont sensibles aux attaques de type "Cross-Site Scripting", et cela reste une attaque courante aujourd'hui, même si ce type d'exploit est connu depuis les années 90.
Empêcher XSS dans une application Spring Boot avec la politique de sécurité du contenu (CSP)
Spring Boot prend la sécurité au sérieux et le module de sécurité de Spring implémente des pratiques de sécurité flexibles et puissantes qui permettent aux développeurs de minimiser leurs inquiétudes en matière de sécurité, ce qui nécessite souvent une compréhension de bas niveau des principes de la manière dont les messages sont échangés sur un site Web. application.
Par défaut, Spring Boot implémente plusieurs en-têtes de sécurité :
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-XSS-Protection est inclus par défaut ! Cet en-tête de sécurité tente de détecter XSS tente et les bloque. Ce n'est cependant pas un processus infaillible, et les navigateurs ont différentes implémentations de détecteurs. Certains navigateurs, comme Chrome, ont même a supprimé son auditeur XSS. De plus, la détection automatique fonctionne pour Attaques XSS réfléchies, tandis que d'autres types d'attaques existent également.
Une alternative plus moderne à X-XSS-Protection est le Politique de sécurité du contenu (CSP), qui traitent principalement des politiques sur lesquelles les ressources peuvent être chargées, à partir de quelles origines et à quels points de terminaison. À partir de 2022, CSP est la meilleure mesure de prévention contre XSS, Clickjacking et autres types d'attaques. Tous les navigateurs n'implémentent pas CSP, c'est pourquoi il n'est pas inclus par défaut dans les en-têtes de sécurité.
Remarque: Même avec CSP en place, c'est toujours la meilleure ligne de conduite à valider tous l'entrée de l'utilisateur et assurez-vous qu'elle peut être traitée en toute sécurité à l'aide de votre système, afin d'empêcher l'injection de code.
Dans Spring Boot - pour configurer des mesures de sécurité Web personnalisées, vous étendez généralement le WebSecurityConfigurerAdapter classe, et remplacer la configure() méthode:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("csp-directives");
}
}
Lorsque les directives de politique de sécurité du contenu (fournies en tant que ;-chaîne séparée) dépendent de votre cas d'utilisation et des sources auxquelles vous souhaitez faire confiance :
Content-Security Policy: directive1; directive2; directive3; ... directiveN;
Par exemple, une application Web peut répertorier les sites Web de confiance à partir desquels les scripts peuvent être chargés avec :
script-src https://trusted.com;
Ou vous pouvez éviter de faire confiance à un site Web tiers :
script-src self;
De même, une application peut faire confiance aux plugins :
object-src https://trusted.com
Il existe une grande variété de directives que vous pouvez fournir, notamment :
default-src– Repli par défautchild-src– Sources de travail Web validesframe-src– Sources valides pours etsimg-src– Sources valides pour les imagesmedia-src– Sources valides pour,ainsi queétiquettesscript-src– Sources de script valides (aide à empêcher XSS)style-src– Sources valides pourélémentsbase-uri– Restreint les ressources accessibles depuis leélémentframe-ancestors– Parents valides de,,, etc. éléments- et ainsi de suite
Consultez notre guide pratique et pratique pour apprendre Git, avec les meilleures pratiques, les normes acceptées par l'industrie et la feuille de triche incluse. Arrêtez de googler les commandes Git et en fait apprendre il!
Par exemple, voici un ensemble sécurisé de directives de stratégie :
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
report-uri https://csp.example.com;
Ajoutons-les à notre application Spring Boot :
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; report-uri https://csp.example.com;");
}
}
Vous pouvez utiliser le CSP-Evaluateur pour évaluer si vos directives CSP sont valides ainsi que sûr, et il indiquera quelles directives sont facilement exploitables. Voici une directive CSP qui autorise les API Google :
default-src 'self';
object-src 'none';
frame-src 'self' data:;
script-src 'self' 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' https://storage.googleapis.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self' data:;
base-uri 'self'
Conclusion
Dans ce petit guide, nous avons examiné ce qu'est le Cross-Site Scripting (XSS) et son fonctionnement à un niveau holistique. Ensuite, nous avons exploré certaines mesures de prévention XSS qui peuvent facilement être mises en œuvre avec Spring Boot pour sécuriser vos applications et définir un Politique de sécurité du contenu (CSP).
Enfin, nous avons exploré les directives CSP et examiné quelques politiques de sécurité différentes.
