Zapobiegaj atakom Cross-Site Scripting (XSS) w Spring Boot dzięki zasadom bezpieczeństwa zawartości (CSP)

Wprowadzenie

Bezpieczeństwo użytkowników i ich danych osobowych podczas korzystania z aplikacji internetowej jest najważniejsze. Chociaż ta wiodąca zasada została uznana już od wczesnych etapów tworzenia stron internetowych – źli aktorzy znajdują luki w aplikacjach i mogą wykorzystywać użytkowników.

Wiele „standardowych” ataków jest dobrze znanych i udokumentowanych, a ochrona przed nimi nie jest trudna. Aby odciążyć programistę od samodzielnego wdrażania praktyk bezpieczeństwa, frameworki, takie jak Spring Boot, oddzieliły różne środki bezpieczeństwa i pozwalają po prostu zastosować filtry bezpieczeństwa w aplikacjach, aby zapobiec dobrze znanym atakom.

W tym krótkim przewodniku przyjrzymy się, czym jest Cross-Site Scripting (XSS), w jaki sposób ktoś może wykonać ten atak na Twojej własnej aplikacji i jak możesz łatwo temu zapobiec za pomocą Spring Boot.

Co to są skrypty między witrynami (XSS)?

Cross-Site Scripting to dobrze znany, szeroko rozpowszechniony exploit, w którym zły aktor wstrzykuje skrypt do aplikacji internetowej.

Zazwyczaj do aplikacji internetowych stosuje się zasady tego samego pochodzenia, które ograniczają skrypty na stronie internetowej do dostępu do danych ze źródeł, jeśli ich źródła nie są zgodne. Zgodnie z polityką tego samego pochodzenia – jeśli strona z a zaufana strona internetowa mogą uzyskiwać dostęp do danych łączących się z użytkownikiem (takich jak na przykład pliki cookie), inne strony z tego samego pochodzenia również mogą to robić. Ta forma kontroli dostępu wydawała się wówczas wystarczająca do ochrony integralności danych w aplikacjach internetowych.

Cross-Site Scripting omija zasady tego samego pochodzenia, wstrzykując złośliwy skrypt na stronę zaufanej witryny. Ponieważ skrypt jest uruchamiany z zaufanej witryny, jest wykonywany jako zaufany skrypt. Nie było jednoznacznego sposobu na odróżnienie złośliwych skryptów od niezłośliwych – dzięki temu możliwe było wykonanie dowolnego kodu dzięki Cross-Site Scripting. Obejmuje to wstawianie irytujących alertów, ataki socjotechniczne, potajemne zbieranie informacji o użytkownikach lub przekierowywanie użytkowników na strony phishingowe, które wydają się być częścią zaufanych witryn.

Wiele strony internetowe są podatne na ataki Cross-Site Scripting i nadal jest to powszechny atak, mimo że tego typu exploity są znane od lat 90.

Zapobieganie XSS w aplikacji Spring Boot za pomocą polityki bezpieczeństwa treści (CSP)

Spring Boot poważnie traktuje bezpieczeństwo, a moduł Spring Security implementuje elastyczne i potężne praktyki bezpieczeństwa, które pozwalają programistom zminimalizować ich obawy, jeśli chodzi o bezpieczeństwo, co często wymaga zrozumienia na niskim poziomie zasad wymiany wiadomości w sieci. aplikacja.

Domyślnie Spring Boot implementuje kilka nagłówków bezpieczeństwa:

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 jest domyślnie dołączony! Ten nagłówek bezpieczeństwa próbuje wykryć XSS próbuje i blokuje je. Nie jest to jednak proces odporny na awarie, a przeglądarki mają różne implementacje detektorów. Niektóre przeglądarki, takie jak Chrome, mają nawet usunęli swojego audytora XSS. Dodatkowo automatyczne wykrywanie działa na: Odbite ataki XSS, istnieją również inne rodzaje ataków.

Bardziej nowoczesną alternatywą dla X-XSS-Protection jest Polityka bezpieczeństwa treści (CSP), które zajmują się głównie zasadami, według których można ładować zasoby, z jakich źródeł i na których punktach końcowych. Od 2022 r. CSP jest najlepszym środkiem zapobiegającym atakom XSS, Clickjacking i innym rodzajom ataków. Nie wszystkie przeglądarki implementują CSP, dlatego domyślnie nie jest on uwzględniany w nagłówkach zabezpieczeń.

Uwaga: Nawet przy wdrożonym CSP, zawsze jest to najlepszy sposób działania do zweryfikowania każdy danych wprowadzonych przez użytkownika i upewnij się, że przetwarzanie w systemie jest bezpieczne, aby zapobiec wstrzyknięciu kodu.

W Spring Boot – aby skonfigurować niestandardowe środki bezpieczeństwa w sieci, zazwyczaj rozszerzysz WebSecurityConfigurerAdapter klasę i pomiń configure() metoda:

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

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

Gdzie dyrektywy polityki bezpieczeństwa treści (dostarczane jako ;-separated string) zależy od przypadku użycia i źródeł, którym chcesz zaufać:

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

Na przykład aplikacja internetowa może wyświetlać zaufane strony internetowe, z których można załadować skrypty:

script-src https://trusted.com;

Możesz też pominąć ufanie dowolnej witrynie innej firmy:

script-src self;

Podobnie aplikacja może ufać wtyczkom:

object-src https://trusted.com

Istnieje wiele różnych dyrektyw, które możesz dostarczyć, w tym:

• default-src – Domyślna rezerwa
• child-src – Prawidłowe źródła web worker
• frame-src – Prawidłowe źródła dla si s
• img-src – Prawidłowe źródła obrazów
• media-src – Prawidłowe źródła dla , i tagi
• script-src – Prawidłowe źródła skryptów (pomaga zapobiegać XSS)
• style-src – Prawidłowe źródła dla Elementy
• base-uri – Ogranicza zasoby dostępne z element
• frame-ancestors – Prawidłowi rodzice , , , itp. elementy
• itd.

Na przykład, oto bezpieczny zestaw dyrektyw zasad:

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;

Dodajmy to do naszej aplikacji 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;");
    }
}

Możesz użyć Ewaluator CSP aby ocenić, czy Twoje dyrektywy CSP są prawidłowe i bezpieczne i wskaże, które dyrektywy można łatwo wykorzystać. Oto dyrektywa CSP, która zezwala na interfejsy Google API:

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'

Wnioski

W tym krótkim przewodniku przyjrzeliśmy się, czym jest Cross-Site Scripting (XSS) i jak działa na poziomie holistycznym. Następnie zbadaliśmy niektóre środki zapobiegawcze XSS, które można łatwo wdrożyć za pomocą Spring Boot, aby zapewnić bezpieczeństwo aplikacji i ustawić Polityka bezpieczeństwa treści (CSP).

Na koniec zbadaliśmy dyrektywy CSP i przyjrzeliśmy się kilku różnym bezpiecznym zasadom.