Zmora pentestera, czyli Content Security Policy

Każdy mniej lub bardziej doświadczony pentester miał styczność z nagłówkiem Content Security Policy. Generalizując całość, moglibyśmy powiedzieć, że CSP pozwala na zdefiniowanie, skąd mogą pochodzić zasoby (kod javascript, css, obrazki itd.) wykorzystywane przez aplikację. CSP należy do jednego z najbardziej znanych nagłówków stosowanych w obronie przed min. atakami typu XSS oraz clickjackingiem. Świadomość tego, w jaki sposób może zostać skonfigurowany CSP zaoszczędza czas w przypadku redteamingu – wiemy od razu, które z ataków mogą się nie powieść.

Ochrona przed wykonywaniem kodu javascript

Jak już wspomnieliśmy, jest to jeden z kilku powodów, do którego wykorzystywany jest CSP. OWASP wyróżnia pięć sposobów na ochronę przed XSS z użyciem CSP:

Ograniczanie skryptów inline

CSP blokuje bezpośrednie wykonywanie kodu znajdującego się między znacznikami <script>. Z jednej strony uniemożliwia to wstrzyknięcie złośliwego kodu, przykładowo:

<script>alert(1)</script>

Natomiast dla osób piszących aplikację wymusza to uporządkowanie kodu w taki sposób, aby zdarzenia wykorzystujące javascript były obsługiwane za pomocą metody element.addEventListener() w odsperowanym pliku. Jak mogłoby to wyglądać? Zamiast:

<script>
  var myVar = 'bugspace'
<script>

Użyjemy:

<script src="myScript.js">
</script>

Gdzie plik myScript.js przetrzymuje jedynie kod „var myVar = 'bugspace'„. Z kolei w przypadku metody element.addEventListener(), zamiast:

<button id="firstButton" onclick="callSomething()">

Dodamy listener:

document.getElementById("firstButton").addEventListener('click', callSomething);

Ograniczanie skryptów z zewnętrznych źródeł

CSP uniemożliwia ładowanie skryptów z dowolnego źródła. Poniższy atak nie będzie działał.

<script src="https://evil.bugspace.pl/evilCode.js"></script>

Ograniczanie kodu klasyfikowanego jako niebezpieczny

CSP uniemożliwia wykonywanie funkcji klasyfikowanych jako niebezpieczne. Należy do nich funkcja eval, przyjmująca jako argument ciąg znaków, który wykonywany jest jako kod javascript. W związku z powyższym nie będzie możliwe uruchomienie następującego kodu.

eval("alert(1)")

Ograniczanie przesyłania formularzy

CSP skutecznie ogranicza możliwości wykorzystania formularza ze strony. Nie będzie możliwe więc, aby został on przesłany w imieniu atakowanego po jego wejściu na niebezpieczną stronę (np. kampanii phishingowej).

Ograniczanie możliwości użycia znacznika <object>

CSP ogranicza możliwość używania znacznika w taki sposób, aby atakujący nie miał możliwości wstrzyknięcia na stronę złośliwych plików np. flash. Przykładowy, złośliwy kod:

<object data="https://evilpage.com/movie.swf"
  type="application/x-shockwave-flash">
</object>

Dyrektywy CSP

Content security policy udostępnia szereg dyrektyw, które są uszeregowane w zależności od ich funkcji. Należą do nich:

dyrektywy do zaciągania plików – mówią przeglądarce skąd można pobierać zasoby w postaci skryptów, zdjęć, plików wektorowych itd.,
dyrektywy dokumenty – instruują przeglądarkę o właściwościach dokumentu, które będzie wykorzystywał,
dyrektywy nawigacji – mówi przeglądarce o miejscach, do których dokument może nawigować,
dyrektywy raportowania – są zależne od innych dyrektyw i dotyczą ustawień raportowania,
specjalne dyrektywy – o części z nich wspomnieliśmy już wcześniej. Należą do nich dyrektywy min:. zezwalające na użycie skryptów lub stylów inline oraz funkcji eval.

CSP w praktyce

Zacznijmy od czegoś uniwersalnego.

Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; form-action 'self';

Co zostało ustawione w dyrektywach powyżej? Wszystkie zasoby muszą być hostowane przez tą samą, wspólną domenę. Ponadto, nie użyjemy funkcji eval oraz skryptów typu inline, a zewnętrzne strony nie będą mogły wrzucić jej w iframe, ani wykorzystywać jej formularzy.

Content-Security-Policy: upgrade-insecure-requests;

Powyższy nagłówek sprawia, że wszystkie żądania będą szyfrowane.

Allow Google Analytics, Google AJAX CDN and Same Origin

W ostatnim z przykładów ustawione jest, aby możliwe było korzystanie ze skryptów Google Analytics, Google AJAX CDN oraz z tych hostowanych przez tą samą domenę.

Źródła

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
https://content-security-policy.com/