Forebyg Cross-Site Scripting (XSS) i Spring Boot med Content-Security Policies (CSP'er)

Introduktion

Sikkerheden for brugere og deres personlige data, mens de bruger en webapplikation, er altafgørende. Selvom dette vejledende princip er blevet anerkendt selv fra de tidlige stadier af webudvikling - finder dårlige aktører smuthuller i applikationer og kan udnytte dine brugere.

Mange "standard" angreb er velkendte og dokumenterede, og beskyttelse mod dem er ikke svært. For at aflaste udvikleren fra selv at implementere sikkerhedspraksis har frameworks som Spring Boot abstraheret forskellige sikkerhedsforanstaltninger og giver dig mulighed for blot at anvende sikkerhedsfiltre i dine applikationer for at forhindre velkendte angreb.

I denne korte guide tager vi et kig på, hvad Cross-Site Scripting (XSS) er, hvordan nogen kunne udføre dette angreb på din egen applikation, og hvordan du nemt kan forhindre det med Spring Boot.

Hvad er Cross-Site Scripting (XSS)?

Cross-Site Scripting er en velkendt, udbredt udnyttelse, hvor en dårlig skuespiller injicerer et script i en webapplikation.

Typisk anvendes en politik med samme oprindelse på webapplikationer, som begrænser scripts på en webside til at få adgang til data fra kilder, hvis deres oprindelse ikke stemmer overens. Under samme oprindelsespolitik – hvis en side fra en pålidelig hjemmeside kan få adgang til data, der interfacer med brugeren (såsom cookies, for eksempel), kan andre sider fra samme oprindelse også gøre det. Denne form for adgangskontrol syntes tilstrækkelig til at beskytte integriteten af ​​data på webapplikationer på det tidspunkt.

Cross-Site Scripting omgår politikken for samme oprindelse, ved at injicere et ondsindet script på en pålidelig hjemmesides side. Da scriptet køres fra et pålideligt websted, udføres det som et betroet script. Der var ingen entydig måde at skelne mellem ondsindede scripts og ikke-ondsindede scripts - så vilkårlig kodeudførelse var mulig med Cross-Site Scripting. Dette spænder over alt fra indsættelse af irriterende advarsler til social engineering-angreb, lydløs indsamling af brugeroplysninger eller omdirigering af brugere til phishing-sider, der ser ud til at være dele af pålidelige websteder.

Mange websteder er modtagelige for Cross-Site Scripting-angreb, og det er stadig et almindeligt angreb i dag, selvom denne type udnyttelse har været kendt siden 90'erne.

Forebyggelse af XSS i en Spring Boot-applikation med Content-Security Policy (CSP)

Spring Boot tager sikkerhed seriøst, og Springs sikkerhedsmodul implementerer fleksible og kraftfulde sikkerhedsmetoder, der gør det muligt for udviklere at minimere deres bekymringer, når det kommer til sikkerhed, hvilket ofte kræver en lav forståelse af principperne for den måde, meddelelser udveksles på på et web Ansøgning.

Som standard implementerer Spring Boot flere sikkerhedsheadere:

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 er inkluderet som standard! Denne sikkerhedsheader forsøger at opdage XSS forsøger og blokerer dem. Dette er dog ikke en fejlsikker proces, og browsere har forskellige implementeringer af detektorer. Nogle browsere, som Chrome, har endda fjernet deres XSS Auditor. Derudover fungerer den automatiske detektion for Afspejlede XSS-angreb, mens andre typer angreb også findes.

Et mere moderne alternativ til X-XSS-Protection er Indholdssikkerhedspolitik (CSP), som primært beskæftiger sig med politikker om, hvilke ressourcer der kan indlæses, fra hvilke oprindelser og på hvilke endepunkter. Fra 2022 er CSP den bedste forebyggelsesforanstaltning mod XSS, Clickjacking og andre typer angreb. Ikke alle browsere implementerer CSP, hvorfor det ikke er inkluderet i sikkerhedsheaderne som standard.

Bemærk: Selv med CSP på plads, er det altid den bedste fremgangsmåde at validere enhver brugerinput og sørg for, at det er sikkert at behandle ved hjælp af dit system, for at forhindre kodeinjektion.

I Spring Boot – for at konfigurere tilpassede websikkerhedsforanstaltninger vil du typisk udvide WebSecurityConfigurerAdapter klasse, og tilsidesætte configure() metode:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

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

Hvor indholdssikkerhedspolitiske direktiver (leveres som en ;-separeret streng) afhænger af din use-case og hvilke kilder du ønsker at stole på:

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

For eksempel kan en webapplikation angive pålidelige websteder, hvorfra scripts kan indlæses med:

script-src https://trusted.com;

Eller du kan springe over at stole på et tredjepartswebsted:

script-src self;

På samme måde kan en applikation stole på plugins:

object-src https://trusted.com

Der er en bred vifte af direktiver, du kan levere, herunder:

• default-src – Standard fallback
• child-src – Gyldige webarbejderkilder
• frame-src – Gyldige kilder til s og s
• img-src – Gyldige kilder til billeder
• media-src – Gyldige kilder til , , tags
• script-src – Gyldige scriptkilder (hjælper med at forhindre XSS)
• style-src – Gyldige kilder til elementer
• base-uri – Begrænser ressourcer, der er tilgængelige fra element
• frame-ancestors – Gyldige forældre til , , , osv. elementer
• etc.

Her er f.eks. et sikkert sæt politiske direktiver:

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;

Lad os tilføje disse til vores Spring Boot-applikation:

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

Du kan bruge CSP-evaluator for at vurdere, om dine CSP-direktiver er gyldige , sikkert, og det vil påpege, hvilke direktiver der er let at udnytte. Her er et CSP-direktiv, der tillader Google API'er:

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'

Konklusion

I denne korte guide har vi taget et kig på, hvad Cross-Site Scripting (XSS) er, og hvordan det fungerer på et holistisk niveau. Derefter har vi undersøgt nogle XSS-forebyggelsesforanstaltninger, der nemt kan implementeres med Spring Boot for at gøre dine applikationer sikre, og indstille en Indholdssikkerhedspolitik (CSP).

Endelig har vi udforsket CSP-direktiver og kigget på et par forskellige sikre politikker.