Bezpieczeństwo aplikacji internetowych – cz. 1. SQL Injection

SQL Injection

Kiedyś, około 2000 roku, korzystanie z Internetu ograniczało się zazwyczaj do przejrzenia poczty i przeczytania kilku newsów. Niektórzy bardziej „zaawansowani” podejmowali się internetowych zakupów np. na rozwijającym się wówczas Allegro. Obecnie technologia poszła do przodu tak bardzo, że jesteśmy w stanie zrobić większość rzeczy bez wychodzenia z domu. Płacimy rachunki, robimy zakupy, doładowujemy telefon, korzystamy z portali społecznościowych. Wszystkie te udogodnienia spowodowały również wzrost czyhających na użytkowników zagrożeń. Obecne strony internetowe mają dużo więcej zadań niż tylko wyświetlić teksty, obrazki czy kilka tabel. Często są to poważne aplikacje internetowe, które przyjmują sporo danych od użytkowników i wykonują różne, niejednokrotnie skomplikowane operacje.

OWASP Top 10

Twórcy oprogramowania powinni być świadomi, na co narażone są aplikacje i nie powinni podchodzić do tematu bezpieczeństwa niedbale. Skąd mogą czerpać wiedzę na ten temat? Z pomocą przychodzi OWASP. Jest to fundacja działająca non-profit, mająca na celu zwiększenie poziomu bezpieczeństwa aplikacji internetowych. Fundacja ta regularnie wydaje dokument OWASP Top 10, który zawiera, jak sama nazwa wskazuje, listę 10 najpopularniejszych podatności występujących w aplikacjach internetowych. Po więcej informacji na temat działalności organizacji i jej projektów zapraszam na stronę internetową.

Proponuję Wam serię wpisów blogowych, z których każdy będzie poświęcony jednej z pozycji z listy OWASP Top 10. W tym artykule zajmiemy się numerem jeden – Injection.

Czym są ataki typu Injection?

Injection to podatność polegająca na wstrzyknięciu danych, które zmuszają aplikację do nieprawidłowego, często szkodliwego działania. Czym może skończyć się taki atak? Możliwości jest wiele. Są to np.:

  • Kompromitacja całego systemu
  • Utrata danych
  • Ominięcie uwierzytelnienia
  • Kradzież danych

Nieprawidłowe działanie niejednokrotnie jest spowodowane brakiem odpowiedniej filtracji parametrów pochodzących od użytkownika. Do rodzajów wstrzyknięć należą m.in.:

SQL Injection
Polega na wstrzyknięciu złośliwego kodu w zapytanie SQL, co może spowodować np. zwrócenie poufnych informacji z bazy danych. Na ten atak narażone są aplikacje przyjmujące dane od użytkownika, które bezpośrednio bez żadnego filtrowania trafiają do zapytania SQL.

OS Command Injection
Atak zbliżony do SQL Injection, ale zamiast fragmentu kodu SQL atakujący wstrzykuje ładunek, który zostaje wykonany jako komenda systemowa. Atak ten jest możliwy, jeżeli aplikacja wykonuje wywołania systemowe i dane od użytkownika uczestniczą w ich wykonaniu.

LDAP Injection
Analogicznie do pozostałych, ale zamiast kodu SQL i komend systemowych, atakujący wstrzykuje złośliwy kod w wyrażenie LDAP

XPATH Injection
XPATH to mechanizm umożliwiający pobieranie wybranego fragmentu z pliku XML. Atakujący skupia się na uzyskaniu dostępu do zawartości pliku XML, próbując wstrzyknąć złośliwy kod do zapytania XPATH.

SQL Injection

W dobie nowoczesnych frameworków, dużej liczby publikacji na temat pisania bezpiecznego kodu oraz znanych sposobów zapobiegania tego typu atakom, podatność ta jest ciągle żywa. Występuje raczej w starszych aplikacjach. Do wytłumaczenia mechanizmu działania podatności związanych ze wstrzyknięciami posłużę się przykładem opartym na SQL Injection.

Atak ten polega na doklejeniu szkodliwego fragmentu do zapytania znajdującego się w kodzie programu. Najczęściej winą jest zapisanie zapytania jako zwykłego stringa i doklejenie do niego parametrów za pomocą konkatenacji. Poniżej przedstawiam przykład takiego zapytania:

SQL Injection – zapytanie 1

Parametry username oraz password są dostarczane przez użytkownika np. z pól formularza. W celu pokazania, do jakich danych może dostać się osoba, której udał się atak, użyłem aplikacji mutillidae udostępnionej przez OWASP. Służy ona do przeprowadzenia ćwiczeń związanych z testowaniem bezpieczeństwa aplikacji internetowych. Poniżej pokazuję przykładowy formularz do logowania pochodzący z wymienionej wyżej aplikacji.

Name and password

Zalogowanie do aplikacji jest możliwe w sytuacji, w której otrzymuje ona rekord, który spełnia warunki z wyrażenia znajdującego się powyżej. Jest to idealny cel do przeprowadzenia ataku SQL Injection. W polu name oraz w polu password wpisujemy 1′ OR ‚1’  = ‚1. Tak jak na obrazku poniżej:

Please enter name and password

Gdy spróbujemy się zalogować, wyrażenie SQL, które jest pod spodem, przyjmuje następującą postać:

SQL Injection – zapytanie 2

Na zielono oznaczyłem apostrofy, które łączą się z zaznaczonym na czerwono fragmentem podanym w polach formularza i tworzą jedno spójne zapytanie. 1=1 to warunek logiczny, który zawsze daje nam wartość True, w związku z tym w naszym wyrażeniu zawsze będziemy mieć spełniony warunek, który znajduje się po słowie kluczowym OR, przez co atakujący dostaje z powrotem wszystkie dane, które są zwracane przez takie wyrażenie.

Poniżej zamieszczam przykład, który pokazuje, co zwraca nam aplikacja mutillidae.

Results

Oczywiście jest to tylko prosty przykład. Atakujący może spowodować nawet usunięcie całej bazy danych.

Blind SQL Injection

Nie zawsze jednak dostajemy dane bezpośrednio od użytkownika. Czasem nie mamy możliwości sprawdzenia odpowiedzi zwróconej przez serwer. Jest to specyficzna kategoria podatności z rodziny Injection. Z pomocą w testowaniu takich podatności przychodzi np. funkcja sleep. Umożliwia ona wstrzymanie wykonywania bieżącego wątku na określony czas.

Pewnym ograniczeniem takiego testowania jest to, że możemy uzyskać jedynie odpowiedź „tak” lub „nie”. W poniższym przykładzie sprawdzamy, czy podana przez nas litera jest równa pierwszej literze hasła, które próbujemy złamać:

SQL Injection – zapytanie 3

Jeżeli zapytanie wykona się błyskawicznie, to znaczy, że „A” nie jest pierwszą literą łamanego hasła. W przeciwnym wypadku, jeśli odpowiedź będzie trwała dłużej, oznacza to, że warunek został spełniony, a my możemy szukać kolejnej litery.

To tylko dwa przykłady podatności typu Injection. Temat jest dość szeroki, a jego rozwinięcie można znaleźć na stronie OWASP.

SQLMap

Dzięki automatyzacji nie jesteśmy skazani na żmudne szukanie takich podatności. Z pomocą przychodzą nam różne programy. Jednym z popularniejszych jest SQLMap, open source’owe narzędzie umożliwiające łatwe testowanie aplikacji pod kątem występowania podatności SQL Injection.

SQLMap posiada sporo funkcjonalności. Są to m.in.:

  • Obsługa następujących baz danych: MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB i HSQLDB

  • Obsługa różnych typów SQL Injection
    • wstrzykiwanie oparte na wartościach boolowskich (boolean-based blind)
    • wstrzykiwanie bazujące na czasie (time-based blind)
    • wstrzykiwanie bazujące na błędach (error-based)
    • z użyciem UNION (UNION query)
    • z użyciem stosów zapytań (stacked queries)
  • Możliwość działania jako klient bazy danych
  • Integracja z projektami Metasploit i w3af
  • Wsparcie dla pobierania i wysyłania plików do serwera bazy danych

Więcej o SQLMap można dowiedzieć się na stronie projektu. Jeżeli pojawi się zainteresowanie tematem, to chętnie poświęcę osobny artykuł na omówienie obsługi tego narzędzia. 🙂

Wnioski

Liczba podatności w aplikacjach internetowych nie maleje. A wraz z nowymi technologiami pojawiają się nowe luki. Całe szczęście rośnie również świadomość programistów na temat tego typu zagrożeń. Dodatkowo w Internecie można znaleźć sporo artykułów na temat bezpiecznego pisania kodu.

Przede wszystkim nie powinniśmy pod żadnym pozorem używać budowania wyrażeń za pomocą konkatenacji. Zapytania powinny być budowane np. za pomocą prepared statement. Wszystkie parametry przychodzące od użytkownika powinny być odpowiednio walidowane i filtrowane. Należy również zwracać uwagę na to, żeby w zespole była świadomość występowania takich podatności, co pozwoli wykryć ewentualne błędy np. podczas code review. Jeżeli używamy nowoczesnych frameworków, to problem bardzo często nas nie dotyczy, co nie znaczy, że jesteśmy w 100% bezpieczni. Dlaczego? Zainteresowanym tym tematem polecam lekturę artykułu „HQL Injection Exploitation in MySQL”.

Bardziej szczegółowy opis metod zabezpieczenia przed tego typu podatnościami można znaleźć w materiale SQL Injection Prevention udostępnionym przez OWASP.

Paweł Kaleciński  – Full Stack Developer w Onwelo. Zainteresowany nowinkami technicznymi, bezpieczeństwem aplikacji internetowych i muzyką rockową.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *