Einleitung
Die Sicherheit der Benutzer und ihrer persönlichen Daten bei der Nutzung einer Webanwendung ist von größter Bedeutung. Obwohl dieses Leitprinzip bereits in den frühen Phasen der Webentwicklung anerkannt wurde, finden Angreifer Schlupflöcher in Anwendungen und können Ihre Benutzer ausnutzen.
Viele „Standard“-Angriffe sind bekannt und dokumentiert, und der Schutz vor ihnen ist nicht schwer. Um den Entwickler von der Implementierung von Sicherheitspraktiken selbst zu entlasten, haben Frameworks wie Spring Boot verschiedene Sicherheitsmaßnahmen abstrahiert und ermöglichen es Ihnen, einfach Sicherheitsfilter in Ihren Anwendungen anzuwenden, um bekannte Angriffe zu verhindern.
In dieser kurzen Anleitung werfen wir einen Blick darauf, was Cross-Site Scripting (XSS) ist, wie jemand diesen Angriff auf Ihre eigene Anwendung ausführen könnte und wie Sie ihn mit Spring Boot einfach verhindern können.
Was ist Cross-Site-Scripting (XSS)?
Cross-Site Scripting ist ein bekannter, weit verbreiteter Exploit, bei dem ein Angreifer ein Skript in eine Webanwendung einschleust.
In der Regel wird auf Webanwendungen eine Same-Origin-Richtlinie angewendet, die den Zugriff von Skripts auf einer Webseite auf Daten aus Quellen einschränkt, wenn deren Ursprünge nicht übereinstimmen. Unter der Same-Origin-Policy – wenn eine Seite von a vertrauenswürdige Webseite kann auf Daten zugreifen, die mit dem Benutzer verbunden sind (wie zum Beispiel Cookies), andere Seiten desselben Ursprungs können dies ebenfalls tun. Diese Form der Zugriffskontrolle schien damals ausreichend zu sein, um die Integrität von Daten in Webanwendungen zu schützen.
Cross-Site Scripting umgeht die Same-Origin-Policy, indem ein schädliches Skript in die Seite einer vertrauenswürdigen Website eingefügt wird. Da das Skript von einer vertrauenswürdigen Website ausgeführt wird, wird es als vertrauenswürdiges Skript ausgeführt. Es gab keine eindeutige Möglichkeit, zwischen bösartigen Skripts und nicht bösartigen Skripts zu unterscheiden – daher war die Ausführung willkürlichen Codes mit Cross-Site Scripting möglich. Dies reicht vom Einfügen lästiger Warnungen bis hin zu Social-Engineering-Angriffen, dem stillen Sammeln von Benutzerinformationen oder dem Umleiten von Benutzern auf Phishing-Seiten, die scheinbar Teile vertrauenswürdiger Websites sind.
Viele Websites sind anfällig für Cross-Site-Scripting-Angriffe, und es ist auch heute noch ein häufiger Angriff, obwohl diese Art von Exploit seit den 90er Jahren bekannt ist.
Verhindern von XSS in einer Spring Boot-Anwendung mit Content-Security Policy (CSP)
Spring Boot nimmt Sicherheit ernst, und das Sicherheitsmodul von Spring implementiert flexible und leistungsstarke Sicherheitspraktiken, die es Entwicklern ermöglichen, ihre Sorgen in Bezug auf die Sicherheit zu minimieren, was oft ein geringes Verständnis der Prinzipien des Nachrichtenaustauschs in einem Web erfordert Anwendung.
Standardmäßig implementiert Spring Boot mehrere Sicherheitsheader:
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 ist standardmäßig enthalten! Dieser Sicherheitsheader versucht dies entdecken XSS versucht und blockiert sie. Dies ist jedoch kein ausfallsicherer Prozess, und Browser haben unterschiedliche Implementierungen von Detektoren. Einige Browser, wie Chrome, haben sogar ihren XSS-Auditor entfernt. Zusätzlich funktioniert die automatisierte Erkennung z Reflektierte XSS-Angriffe, während es auch andere Arten von Angriffen gibt.
Eine modernere Alternative zur X-XSS-Protection ist die Inhaltssicherheitsrichtlinie (CSP), die sich hauptsächlich mit Richtlinien befassen, welche Ressourcen von welchem Ursprung und an welchen Endpunkten geladen werden können. Ab 2022 ist CSP die beste Präventionsmaßnahme gegen XSS, Clickjacking und andere Arten von Angriffen. Nicht alle Browser implementieren CSP, weshalb es standardmäßig nicht in den Sicherheitsheadern enthalten ist.
Hinweis: Selbst wenn CSP vorhanden ist, ist dies immer die beste Vorgehensweise für die Validierung jedem Benutzereingaben und stellen Sie sicher, dass die Verarbeitung mit Ihrem System sicher ist, um Code-Injection zu verhindern.
In Spring Boot – um benutzerdefinierte Websicherheitsmaßnahmen zu konfigurieren, erweitern Sie normalerweise die WebSecurityConfigurerAdapter Klasse, und überschreiben Sie die configure() Verfahren:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("csp-directives");
}
}
Wenn die Richtlinienrichtlinien zur Inhaltssicherheit (bereitgestellt als ;-getrennte Zeichenfolge) hängen von Ihrem Anwendungsfall ab und welchen Quellen Sie vertrauen möchten:
Content-Security Policy: directive1; directive2; directive3; ... directiveN;
Beispielsweise kann eine Webanwendung vertrauenswürdige Websites auflisten, von denen Skripte geladen werden können mit:
script-src https://trusted.com;
Oder Sie können das Vertrauen in Websites von Drittanbietern überspringen:
script-src self;
Ebenso kann eine Anwendung Plugins vertrauen:
object-src https://trusted.com
Es gibt eine Vielzahl von Anweisungen, die Sie bereitstellen können, darunter:
default-src– Standardfallbackchild-src– Gültige Webworker-Quellenframe-src– Gültige Quellen fürs undsimg-src– Gültige Quellen für Bildermedia-src– Gültige Quellen für,undTagsscript-src– Gültige Skriptquellen (hilft XSS zu verhindern)style-src– Gültige Quellen fürElementebase-uri– Schränkt Ressourcen ein, auf die über die zugegriffen werden kannElementframe-ancestors– Gültige Eltern von,,, usw. Elemente- usw.
Sehen Sie sich unseren praxisnahen, praktischen Leitfaden zum Erlernen von Git an, mit Best Practices, branchenweit akzeptierten Standards und einem mitgelieferten Spickzettel. Hören Sie auf, Git-Befehle zu googeln und tatsächlich in Verbindung, um es!
Hier ist beispielsweise ein sicherer Satz von Richtlinienanweisungen:
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;
Fügen wir diese zu unserer Spring Boot-Anwendung hinzu:
@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;");
}
}
Sie können die Verwendung CSP-Evaluator um auszuwerten, ob Ihre CSP-Anweisungen gültig sind und sicher, und es wird darauf hingewiesen, welche Direktiven leicht ausgenutzt werden können. Hier ist eine CSP-Anweisung, die Google-APIs zulässt:
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'
Zusammenfassung
In dieser kurzen Anleitung haben wir uns angesehen, was Cross-Site Scripting (XSS) ist und wie es auf ganzheitlicher Ebene funktioniert. Dann haben wir einige XSS-Präventionsmaßnahmen untersucht, die mit Spring Boot einfach implementiert werden können, um Ihre Anwendungen sicher zu machen, und eine festgelegt Inhaltssicherheitsrichtlinie (CSP).
Schließlich haben wir CSP-Richtlinien untersucht und uns ein paar verschiedene sichere Richtlinien angesehen.
