Impedisci lo scripting tra siti (XSS) in Spring Boot con i criteri di sicurezza dei contenuti (CSP)

Introduzione

La sicurezza degli utenti e dei loro dati personali durante l'utilizzo di un'applicazione web è fondamentale. Sebbene questo principio guida sia stato riconosciuto anche dalle prime fasi dello sviluppo web, i malintenzionati trovano scappatoie nelle applicazioni e possono sfruttare i tuoi utenti.

Molti attacchi "standard" sono ben noti e documentati e proteggerli non è difficile. Per alleggerire lo sviluppatore dall'implementazione delle pratiche di sicurezza, framework come Spring Boot hanno astrato varie misure di sicurezza e ti consentono di applicare semplicemente filtri di sicurezza nelle tue applicazioni per prevenire attacchi noti.

In questa breve guida, daremo un'occhiata a cos'è il Cross-Site Scripting (XSS), come qualcuno potrebbe eseguire questo attacco sulla tua applicazione e come puoi prevenirlo facilmente con Spring Boot.

Che cos'è il Cross-Site Scripting (XSS)?

Cross-Site Scripting è un exploit ben noto e ampiamente diffuso, in cui un cattivo attore inserisce uno script in un'applicazione web.

In genere, alle applicazioni Web viene applicata una politica della stessa origine, che limita gli script in una pagina Web ad accedere ai dati dalle origini se le loro origini non corrispondono. In base alla politica della stessa origine, se una pagina da a sito web affidabile possono accedere a dati di interfacciamento con l'utente (come ad esempio i cookie), possono accedervi anche altre pagine della stessa origine. Questa forma di controllo degli accessi sembrava sufficiente per proteggere l'integrità dei dati sulle applicazioni web in quel momento.

Il cross-site scripting elude la politica della stessa origine, iniettando uno script dannoso nella pagina di un sito Web attendibile. Poiché lo script viene eseguito da un sito Web attendibile, viene eseguito come script attendibile. Non esisteva un modo chiaro per distinguere tra script dannosi e script non dannosi, quindi l'esecuzione di codice arbitrario era possibile con il Cross-Site Scripting. Ciò spazia dall'inserimento di avvisi fastidiosi, agli attacchi di ingegneria sociale, alla raccolta silenziosa di informazioni sugli utenti o al reindirizzamento degli utenti a pagine di phishing che sembrano essere parti di siti Web affidabili.

Molti i siti Web sono suscettibili agli attacchi Cross-Site Scripting e rimane un attacco comune oggi, anche se questo tipo di exploit è noto dagli anni '90.

Prevenire XSS in un'applicazione Spring Boot con Content-Security Policy (CSP)

Spring Boot prende sul serio la sicurezza e il modulo Security di Spring implementa pratiche di sicurezza flessibili e potenti che consentono agli sviluppatori di ridurre al minimo le loro preoccupazioni quando si tratta di sicurezza, che spesso richiede una comprensione di basso livello dei principi del modo in cui i messaggi vengono scambiati in un Web applicazione.

Di default, Spring Boot implementa diverse intestazioni di sicurezza:

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

La protezione X-XSS è inclusa per impostazione predefinita! Questa intestazione di sicurezza tenta di individuare XSS tenta e li blocca. Tuttavia, questo non è un processo a prova di errore e i browser hanno diverse implementazioni di rilevatori. Alcuni browser, come Chrome, hanno anche rimosso il loro revisore XSS. Inoltre, il rilevamento automatico funziona per Attacchi XSS riflessi, mentre esistono anche altri tipi di attacchi.

Un'alternativa più moderna alla protezione X-XSS è il Politica di sicurezza dei contenuti (CSP), che si occupano principalmente di politiche su cui è possibile caricare le risorse, da quali origini e su quali endpoint. A partire dal 2022, CSP è la migliore misura di prevenzione contro XSS, Clickjacking e altri tipi di attacchi. Non tutti i browser implementano CSP, motivo per cui non è incluso nelle intestazioni di sicurezza per impostazione predefinita.

Nota: Anche con CSP in atto, è sempre la migliore linea d'azione da convalidare in qualsiasi input dell'utente e assicurati che sia sicuro elaborare utilizzando il tuo sistema, per prevenire l'iniezione di codice.

In Spring Boot: per configurare misure di sicurezza Web personalizzate, in genere estenderai il WebSecurityConfigurerAdapter classe e sovrascrivere il configure() Metodo:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

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

Laddove le direttive sulla politica di sicurezza dei contenuti (fornite come a ;-separated string) dipendono dal tuo caso d'uso e di quali fonti desideri fidarti:

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

Ad esempio, un'applicazione Web può elencare siti Web attendibili da cui è possibile caricare gli script con:

script-src https://trusted.com;

Oppure puoi saltare la fiducia di qualsiasi sito Web di terze parti:

script-src self;

Allo stesso modo, un'applicazione può fidarsi dei plugin:

object-src https://trusted.com

È possibile fornire un'ampia varietà di direttive, tra cui:

• default-src – Ritorno predefinito
• child-src – Fonti di lavoro Web valide
• frame-src – Fonti valide per s e s
• img-src – Fonti valide per le immagini
• media-src – Fonti valide per , ed tag
• script-src – Fonti di script valide (aiuta a prevenire XSS)
• style-src – Fonti valide per elementi
• base-uri – Limita le risorse accessibili dal elemento
• frame-ancestors – Genitori validi di , , , ecc. elementi
• ecc.

Ad esempio, ecco un insieme sicuro di direttive di policy:

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;

Aggiungiamo questi alla nostra applicazione Spring Boot:

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

È possibile utilizzare il Valutatore CSP per valutare se le tue direttive CSP sono valide ed sicuro e indicherà quali direttive sono facilmente sfruttabili. Ecco una direttiva CSP che consente le API di Google:

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'

Conclusione

In questa breve guida, abbiamo dato un'occhiata a cos'è il Cross-Site Scripting (XSS) e come funziona a livello olistico. Quindi, abbiamo esplorato alcune misure di prevenzione XSS che possono essere facilmente implementate con Spring Boot per rendere sicure le tue applicazioni e impostato un Politica di sicurezza dei contenuti (PSC).

Infine, abbiamo esaminato le direttive CSP e dato un'occhiata a un paio di diverse politiche di sicurezza.