Förhindra Cross-Site Scripting (XSS) i Spring Boot med Content-Security Policys (CSP:er)

Beskrivning

Säkerheten för användare och deras personliga data när de använder en webbapplikation är av största vikt. Även om denna vägledande princip har erkänts redan från de tidiga stadierna av webbutveckling – hittar dåliga aktörer kryphål i applikationer och kan utnyttja dina användare.

Många "standard" attacker är välkända och dokumenterade, och skydd mot dem är inte svårt. För att avlasta utvecklaren från att implementera säkerhetspraxis själva, har ramverk som Spring Boot abstraherat bort olika säkerhetsåtgärder och låter dig helt enkelt tillämpa säkerhetsfilter i dina applikationer för att förhindra välkända attacker.

I den här korta guiden tar vi en titt på vad Cross-Site Scripting (XSS) är, hur någon skulle kunna utföra denna attack på ditt eget program och hur du enkelt kan förhindra det med Spring Boot.

Vad är Cross-Site Scripting (XSS)?

Cross-Site Scripting är en välkänd, spridd exploatering, där en dålig skådespelare injicerar ett manus i en webbapplikation.

Vanligtvis tillämpas en princip med samma ursprung på webbapplikationer, vilket begränsar skript på en webbsida för att komma åt data från källor om deras ursprung inte stämmer överens. Enligt samma ursprungspolicy – ​​om en sida från en pålitlig webbplats kan komma åt data som gränsar till användaren (såsom cookies, till exempel), andra sidor från samma ursprung kan också göra det. Denna form av åtkomstkontroll verkade vara tillräcklig för att skydda dataintegriteten i webbapplikationer vid den tiden.

Cross-Site Scripting kringgår principen om samma ursprung, genom att injicera ett skadligt skript på en betrodd webbplatssida. Eftersom skriptet körs från en betrodd webbplats, körs det som ett betrodd skript. Det fanns inget entydigt sätt att skilja mellan skadliga skript och icke-skadliga skript – så godtycklig kodexekvering var möjlig med Cross-Site Scripting. Detta sträcker sig allt från att infoga irriterande varningar, till sociala ingenjörsattacker, tyst insamling av användarinformation eller omdirigering av användare till nätfiskesidor som verkar vara delar av betrodda webbplatser.

Många webbplatser är mottagliga för Cross-Site Scripting-attacker, och det är fortfarande en vanlig attack idag, även om denna typ av exploatering har varit känd sedan 90-talet.

Förhindra XSS i en Spring Boot Application med Content-Security Policy (CSP)

Spring Boot tar säkerheten på allvar, och Springs säkerhetsmodul implementerar flexibla och kraftfulla säkerhetsrutiner som gör det möjligt för utvecklare att minimera sin oro när det kommer till säkerhet, vilket ofta kräver en låg nivå förståelse för principerna för hur meddelanden utbyts på en webb Ansökan.

Som standard implementerar Spring Boot flera säkerhetsrubriker:

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 ingår som standard! Denna säkerhetsrubrik försöker upptäcka XSS försöker och blockerar dem. Detta är dock inte en felsäker process, och webbläsare har olika implementeringar av detektorer. Vissa webbläsare, som Chrome, har till och med tog bort sin XSS Auditor. Dessutom fungerar den automatiska upptäckten för Reflekterade XSS-attacker, medan andra typer av attacker också finns.

Ett modernare alternativ till X-XSS-Protection är Innehållssäkerhetspolicy (CSP), som i första hand handlar om policyer om vilka resurser som kan laddas, från vilket ursprung och vid vilka slutpunkter. Från och med 2022 är CSP den bästa förebyggande åtgärden mot XSS, Clickjacking och andra typer av attacker. Inte alla webbläsare implementerar CSP, vilket är anledningen till att den inte ingår i säkerhetshuvudena som standard.

Notera: Även med CSP på plats är det alltid det bästa sättet att validera vilken som helst användarinmatning och se till att det är säkert att bearbeta med ditt system, för att förhindra kodinjektion.

I Spring Boot – för att konfigurera anpassade webbsäkerhetsåtgärder, utökar du vanligtvis WebSecurityConfigurerAdapter klass och åsidosätt configure() metod:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

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

Där innehållssäkerhetspolicyn (levereras som en ;-separerad sträng) beror på ditt användningsfall och vilka källor du vill lita på:

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

Till exempel kan en webbapplikation lista betrodda webbplatser från vilka skript kan laddas med:

script-src https://trusted.com;

Eller så kan du hoppa över att lita på en tredjepartswebbplats:

script-src self;

På samma sätt kan en applikation lita på plugins:

object-src https://trusted.com

Det finns en mängd olika direktiv du kan tillhandahålla, inklusive:

• default-src – Standard reserv
• child-src – Giltiga webbarbetarkällor
• frame-src – Giltiga källor för s och s
• img-src – Giltiga källor för bilder
• media-src – Giltiga källor för , och taggar
• script-src – Giltiga skriptkällor (hjälper till att förhindra XSS)
• style-src – Giltiga källor för element
• base-uri – Begränsar resurser tillgängliga från elementet
• frame-ancestors – Giltiga föräldrar till , , , etc. element
• och så vidare

Till exempel, här är en säker uppsättning policydirektiv:

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;

Låt oss lägga till dessa i vår 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 använda CSP-Evaluator för att utvärdera om dina CSP-direktiv är giltiga och säkert, och det kommer att påpeka vilka direktiv som är lätta att utnyttja. Här är ett CSP-direktiv som tillåter Googles 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'

Slutsats

I den här korta guiden har vi tagit en titt på vad Cross-Site Scripting (XSS) är och hur det fungerar på en holistisk nivå. Sedan har vi utforskat några XSS-förebyggande åtgärder som enkelt kan implementeras med Spring Boot för att göra dina applikationer säkra, och ställer in en Innehållssäkerhetspolicy (CSP).

Slutligen har vi utforskat CSP-direktiven och tagit en titt på ett par olika säkra policyer.