Voorkom Cross-Site Scripting (XSS) in Spring Boot met Content-Security Policies (CSP's)

Introductie

De veiligheid van gebruikers en hun persoonlijke gegevens tijdens het gebruik van een webapplicatie staat voorop. Hoewel dit leidende principe zelfs vanaf de vroege stadia van webontwikkeling is erkend, vinden kwaadwillenden mazen in applicaties en kunnen ze uw gebruikers uitbuiten.

Veel 'standaard'-aanvallen zijn bekend en gedocumenteerd, en bescherming ertegen is niet moeilijk. Om de ontwikkelaar te ontlasten van het zelf implementeren van beveiligingspraktijken, hebben frameworks zoals Spring Boot verschillende beveiligingsmaatregelen geabstraheerd en kunt u eenvoudig beveiligingsfilters in uw applicaties toepassen om bekende aanvallen te voorkomen.

In deze korte handleiding bekijken we wat Cross-Site Scripting (XSS) is, hoe iemand deze aanval op uw eigen applicatie zou kunnen uitvoeren en hoe u deze gemakkelijk kunt voorkomen met Spring Boot.

Wat is Cross-Site Scripting (XSS)?

Cross-Site Scripting is een bekende, wijdverbreide exploit, waarbij een kwaadwillende een script in een webtoepassing injecteert.

Meestal wordt een beleid van dezelfde oorsprong toegepast op webtoepassingen, waardoor scripts in een webpagina worden beperkt om toegang te krijgen tot gegevens uit bronnen als hun oorsprong niet overeenkomt. Onder hetzelfde-oorsprong beleid – als een pagina van a vertrouwde website kan toegang krijgen tot gegevens die interfacing met de gebruiker (zoals cookies, bijvoorbeeld), andere pagina's van dezelfde oorsprong kunnen dit ook doen. Deze vorm van toegangscontrole leek destijds voldoende om de integriteit van data op webapplicaties te beschermen.

Cross-Site Scripting omzeilt het beleid van dezelfde oorsprong, door een kwaadaardig script in de pagina van een vertrouwde website te injecteren. Aangezien het script wordt uitgevoerd vanaf een vertrouwde website, wordt het uitgevoerd als een vertrouwd script. Er was geen duidelijke manier om onderscheid te maken tussen kwaadaardige scripts en niet-kwaadaardige scripts - dus het uitvoeren van willekeurige code was mogelijk met Cross-Site Scripting. Dit varieert van het invoegen van vervelende waarschuwingen tot social engineering-aanvallen, het stilletjes verzamelen van gebruikersinformatie of het omleiden van gebruikers naar phishing-pagina's die onderdeel lijken te zijn van vertrouwde websites.

Veel websites zijn vatbaar voor Cross-Site Scripting-aanvallen en het blijft een veelvoorkomende aanval, ook al is dit type exploit al sinds de jaren 90 bekend.

XSS voorkomen in een Spring Boot-applicatie met Content-Security Policy (CSP)

Spring Boot neemt beveiliging serieus en de beveiligingsmodule van Spring implementeert flexibele en krachtige beveiligingspraktijken waarmee ontwikkelaars hun zorgen over beveiliging tot een minimum kunnen beperken, wat vaak een laag begrip vereist van de principes van de manier waarop berichten worden uitgewisseld in een web sollicitatie.

Spring Boot implementeert standaard verschillende beveiligingsheaders:

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 is standaard inbegrepen! Deze beveiligingsheader probeert: opsporen XSS probeert en blokkeert ze. Dit is echter geen feilloos proces en browsers hebben verschillende implementaties van detectoren. Sommige browsers, zoals Chrome, hebben zelfs hun XSS-auditor verwijderd. Bovendien werkt de geautomatiseerde detectie voor: Weerspiegelde XSS-aanvallen, terwijl er ook andere soorten aanvallen bestaan.

Een moderner alternatief voor X-XSS-Protection is de Inhoud-beveiligingsbeleid (CSP), die zich voornamelijk bezighouden met beleid op welke bronnen kunnen worden geladen, van welke oorsprong en op welke eindpunten. Vanaf 2022 is CSP de beste preventiemaatregel tegen XSS, Clickjacking en andere soorten aanvallen. Niet alle browsers implementeren CSP, daarom is het niet standaard opgenomen in de beveiligingsheaders.

Opmerking: Zelfs met CSP is dit altijd de beste manier om te valideren elke gebruikersinvoer en zorg ervoor dat het veilig is om uw systeem te gebruiken om code-injectie te voorkomen.

In Spring Boot – om aangepaste webbeveiligingsmaatregelen te configureren, breid je meestal de WebSecurityConfigurerAdapter klasse, en overschrijven de configure() methode:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
	http
	.headers()
		.contentSecurityPolicy("csp-directives");
    }
}

Waar de richtlijnen voor het inhoudsbeveiligingsbeleid (geleverd als een ;-gescheiden string) zijn afhankelijk van uw use-case en welke bronnen u wilt vertrouwen:

Content-Security Policy: directive1; directive2; directive3; ... directiveN;

Een webtoepassing kan bijvoorbeeld vertrouwde websites weergeven van waaruit scripts kunnen worden geladen met:

script-src https://trusted.com;

Of u kunt het vertrouwen op websites van derden overslaan:

script-src self;

Op dezelfde manier kan een toepassing plug-ins vertrouwen:

object-src https://trusted.com

Er is een grote verscheidenheid aan richtlijnen die u kunt geven, waaronder:

• default-src – Standaard terugval
• child-src – Geldige bronnen voor webwerkers
• frame-src – Geldige bronnen voor s en s
• img-src – Geldige bronnen voor afbeeldingen
• media-src – Geldige bronnen voor , en labels
• script-src – Geldige scriptbronnen (helpt XSS voorkomen)
• style-src – Geldige bronnen voor geeft je de mogelijkheid
• base-uri – Beperkt bronnen die toegankelijk zijn vanaf de element
• frame-ancestors – Geldige ouders van , , , enz. elementen
• enz.

Hier is bijvoorbeeld een veilige set beleidsrichtlijnen:

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;

Laten we deze toevoegen aan onze Spring Boot-applicatie:

@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;");
    }
}

U kunt gebruik maken van de CSP-evaluator om te evalueren of uw CSP-richtlijnen geldig zijn en veilig, en het zal aangeven welke richtlijnen gemakkelijk kunnen worden misbruikt. Hier is een CSP-richtlijn die Google API's toestaat:

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'

Conclusie

In deze korte handleiding hebben we gekeken naar wat Cross-Site Scripting (XSS) is en hoe het op holistisch niveau werkt. Vervolgens hebben we enkele XSS-preventiemaatregelen onderzocht die eenvoudig kunnen worden geïmplementeerd met Spring Boot om uw applicaties veilig te maken, en een Inhoud-beveiligingsbeleid (CSP).

Ten slotte hebben we CSP-richtlijnen onderzocht en een aantal verschillende veilige beleidsregels bekeken.