Forhindre Cross-Site Scripting (XSS) i Spring Boot med Content-Security Policy (CSP-er)

Introduksjon

Sikkerheten til brukere og deres personlige data mens de bruker en nettapplikasjon er av største betydning. Selv om dette veiledende prinsippet har blitt anerkjent selv fra de tidlige stadiene av nettutvikling – finner dårlige aktører smutthull i applikasjoner og kan utnytte brukerne dine.

Mange "standard" angrep er velkjente og dokumenterte, og beskyttelse mot dem er ikke vanskelig. For å avlaste utvikleren fra å implementere sikkerhetspraksis selv, har rammeverk som Spring Boot abstrahert ulike sikkerhetstiltak og lar deg ganske enkelt bruke sikkerhetsfiltre i applikasjonene dine for å forhindre velkjente angrep.

I denne korte guiden tar vi en titt på hva Cross-Site Scripting (XSS) er, hvordan noen kan utføre dette angrepet på din egen applikasjon, og hvordan du enkelt kan forhindre det med Spring Boot.

Hva er Cross-Site Scripting (XSS)?

Cross-Site Scripting er en velkjent, vidt spredt utnyttelse, der en dårlig skuespiller injiserer et manus i en nettapplikasjon.

Vanligvis brukes en policy med samme opprinnelse på nettapplikasjoner, som begrenser skript på en nettside for å få tilgang til data fra kilder hvis opprinnelsen ikke stemmer overens. Under retningslinjene for samme opprinnelse – hvis en side fra en pålitelig nettsted kan få tilgang til data som har grensesnitt med brukeren (som for eksempel informasjonskapsler), andre sider fra samme opprinnelse kan også gjøre det. Denne formen for tilgangskontroll virket tilstrekkelig til å beskytte integriteten til data på nettapplikasjoner på den tiden.

Cross-Site Scripting omgår retningslinjene for samme opprinnelse, ved å injisere et ondsinnet skript på en pålitelig nettsides side. Siden skriptet kjøres fra et pålitelig nettsted, kjøres det som et klarert skript. Det var ingen entydig måte å skille mellom ondsinnede skript og ikke-ondsinnede skript - så vilkårlig kodekjøring var mulig med Cross-Site Scripting. Dette spenner alt fra å sette inn irriterende varsler, til sosiale ingeniørangrep, stille innsamling av brukerinformasjon eller omdirigere brukere til phishing-sider som ser ut til å være deler av pålitelige nettsteder.

Mange nettsteder er mottakelige for Cross-Site Scripting-angrep, og det er fortsatt et vanlig angrep i dag, selv om denne typen utnyttelse har vært kjent siden 90-tallet.

Forhindre XSS i en Spring Boot-applikasjon med Content-Security Policy (CSP)

Spring Boot tar sikkerhet på alvor, og Springs sikkerhetsmodul implementerer fleksible og kraftige sikkerhetspraksiser som lar utviklere minimere bekymringen når det kommer til sikkerhet, noe som ofte krever en forståelse på lavt nivå av prinsippene for måten meldinger utveksles på på nettet applikasjon.

Som standard implementerer Spring Boot flere sikkerhetsoverskrifter:

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 inkludert som standard! Denne sikkerhetsoverskriften prøver å oppdage XSS forsøker, og blokkerer dem. Dette er imidlertid ikke en feilsikker prosess, og nettlesere har forskjellige implementeringer av detektorer. Noen nettlesere, som Chrome, har til og med fjernet deres XSS Auditor. I tillegg fungerer den automatiske deteksjonen for Reflekterte XSS-angrep, mens andre typer angrep også finnes.

Et mer moderne alternativ til X-XSS-Protection er Innholdssikkerhetspolicy (CSP), som primært omhandler policyer om hvilke ressurser som kan lastes, fra hvilken opprinnelse og ved hvilke endepunkter. Fra og med 2022 er CSP det beste forebyggingstiltaket mot XSS, Clickjacking og andre typer angrep. Ikke alle nettlesere implementerer CSP, og derfor er det ikke inkludert i sikkerhetshodene som standard.

OBS: Selv med CSP på plass, er det alltid den beste handlingen å validere noen brukerinndata og sørg for at det er trygt å behandle ved hjelp av systemet ditt, for å forhindre kodeinjeksjon.

I Spring Boot – for å konfigurere tilpassede nettsikkerhetstiltak, vil du vanligvis utvide WebSecurityConfigurerAdapter klasse, og overstyre configure() metode:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

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

Hvor retningslinjene for innholdssikkerhet (leveres som en ;-separert streng) avhenger av brukssaken din og hvilke kilder du ønsker å stole på:

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

For eksempel kan en nettapplikasjon liste opp pålitelige nettsteder som skript kan lastes fra med:

script-src https://trusted.com;

Eller du kan hoppe over å stole på et tredjepartsnettsted:

script-src self;

På samme måte kan en applikasjon stole på plugins:

object-src https://trusted.com

Det er et bredt utvalg av direktiver du kan levere, inkludert:

• default-src – Standard fallback
• child-src – Gyldige webarbeiderkilder
• frame-src – Gyldige kilder for s og s
• img-src – Gyldige kilder for bilder
• media-src – Gyldige kilder for , og tags
• script-src – Gyldige skriptkilder (hjelper med å forhindre XSS)
• style-src – Gyldige kilder for elementer
• base-uri – Begrenser ressurser tilgjengelig fra element
• frame-ancestors – Gyldige foreldre til , , , etc. elementer
• og så videre

Her er for eksempel et sikkert sett med retningslinjer:

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;

La oss legge disse til vår Spring Boot-applikasjon:

@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 også bruke det CSP-evaluator for å vurdere om CSP-direktivene dine er gyldige og trygt, og det vil påpeke hvilke direktiver som er lett å utnytte. Her er et CSP-direktiv som tillater Google APIer:

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'

konklusjonen

I denne korte veiledningen har vi tatt en titt på hva Cross-Site Scripting (XSS) er, og hvordan det fungerer på et holistisk nivå. Deretter har vi utforsket noen XSS-forebyggende tiltak som enkelt kan implementeres med Spring Boot for å gjøre applikasjonene dine trygge, og angi en Innholdssikkerhetspolicy (CSP).

Til slutt har vi utforsket CSP-direktiver og tatt en titt på et par forskjellige trygge retningslinjer.