Pobieranie parametrów od użytkownika i późniejsze wyświetlanie ich na stronie internetowej zawsze wiąże się z prawdopodobieństwem ataku XSS czyli Cross Site Scripting.
Ale czy można przeprowadzić taki atak bez użycia tagów HTML?
XSS to wykonanie nieautoryzowanego kodu JavaScript na naszej stronie internetowej.
Dlaczego ten atak jest niebezpieczny?
Przy użyciu takiego kodu możemy ukraść dane bieżącego użytkownika i wykonać za niego jakąś akcję.
Na przykład opublikować jakiś post na stronie, czy też usunąć zdjęcie.
Wpisując w wyszukiwarkę Google słowo kluczowe XSS payloads możemy znaleźć wiele stron, które zawierają listę potencjalnych ciągów tekstowych, używanych przez pentesterów.
Częstą praktyką jest użycie funkcji alert(), która to wyświetla okienko z naszym napisem w oknie przeglądarki.
Jeśli więc, korzystając z tych ciągów znaków uda się nam wyświetlić dane okienko oznacza to, że jesteśmy podatni na ten atak.
Jak możemy zauważyć, ataki te opierają się na wykorzystaniu tagów HTML.
Tagi natomiast są otwierane przy użyciu znaku mniejszości a zamykane przy użyciu znaku większości.
Popatrzmy zatem na dzisiejszy kod.
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.6.0/angular.js"></script>
<div ng-app>
<?php
$s = str_replace('<', '<', $_GET['s']);
echo str_replace('>', '>', $s);
?>
</div>Przy użyciu funkcji str_replace1 poszukujemy znaku większości i mniejszości i zamieniamy je na odpowiadające im encje.
Kiedy przeglądarka napotyka encję, wie wtedy, że użytkownik nie chce otworzyć jakiegoś tagu a po prostu wyświetlić dany znak.
Potencjalnie więc zamieniając wszystkie znaki większości i mniejszości powinniśmy być w stanie ochronić się przed atakiem XSS.
Sprawdźmy to w praktyce.
Spróbujmy wykonać przykładowy payload i zobaczyć co się stanie.
Jak widać nic złego się nie dzieje.
Gdzie zatem znajduje się dzisiejszy błąd?
Przyjrzymy się przykładowi nieco bliżej.
Oprócz użycia funkcji str_replace, dodaliśmy tam również zewnętrzną bibliotekę JavaScript nazwaną Angular2.
Jest to otwarty framework firmowany przez Google, wspomagający tworzenie aplikacji internetowych na pojedynczej stronie.
Aby korzystać z jego dobroci użyłem również tagu div z atrybutem ng-app.
To sprawia, ze Angular wie, że dana strona korzysta z jego funkcjonalności.
Jeśli zatem i Twoja strona korzysta z Angulara - zasady ochrony przed atakami XSS ulegają zmianie.
Tutaj bowiem podobnie jak w atakach [Server Side Template Injection]({% link _posts/od0dopentestera/2018-10-03-ssti-server-side-template-injections.md %}) można używać specjalnych poleceń zawartych pomiędzy podwójnymi cudzysłowami.
Najprostszą metoda sprawdzenia czy nasza strona jest podatna na ten atak to skorzystanie z matematyki:
{{5-2}}Jak widać na naszej stronie wyświetlił się wynik odejmowania.
Pora na wykonanie nieco ciekawszych z punktu widzenia pentestera czynności.
Jeszcze nie tak dawno twórcy Angulara próbowali ochronić nieświadomych użytkowników tego frameworka przed wyżej wymienionym atakiem, implementując w swojej bibliotece tak zwany sandbox, który miał za zadanie filtrować komendy podawane przez użytkownika i nie wykonywać tych, które są złośliwe.
Badacze jednak znajdowali luki w tym rozwiązaniu i raz za razem publikowali nowe obejścia tego problemu - co można sprawdzić na stronie twórców Burpa3.
Dlatego też od wydania wersji 1.6 sandbox został całkowicie porzucony, co ułatwiło zadanie osobom znajdującym błędy.
Teraz wystarczy zamiast naszego odejmowania użyć prostego payloadu i naszym oczom ukaże się okienko z alert boxem.
constructor.constructor('alert(1)')()Właśnie wykonaliśmy kod JavaScript bez używania tagów HTML.
Przedstawiany atak nazywa się Client Side Template Injection.
Jak zatem ochronić się przed tym atakiem?
W miejscu gdzie dane są podawane i wyświetlane przez użytkownika należy dodać specjalny argument[^4]:
ng-non-bindableDodajmy go więc do naszego diva w przykładowym skrypcie.
Teraz przekazywany przez nas parametr jest wyświetlany jako tekst.