SQL Injection SQLi

Czym jest SQL injection

Prowadzisz sklep internetowy. Odwiedzający wpisuje w wyszukiwarkę coś dziwnego, naciska Enter, a strona pokazuje mu imiona, numery telefonów i historię zamówień wszystkich Twoich klientów. Nikt nie ukradł hasła. Wpisał właściwe słowa w niewłaściwym miejscu, a resztę zrobiła Twoja strona. Tak właśnie wygląda SQL injection.

Większość stron trzyma swoje informacje w bazie danych: uporządkowanym magazynie tabel, trochę podobnym do zestawu arkuszy kalkulacyjnych. Aby odczytać lub zmienić te informacje, strona posługuje się językiem o nazwie SQL (Structured Query Language). Każda prośba, którą wysyła, to zapytanie, na przykład „znajdź klienta z tym adresem e-mail”.

Do SQL injection dochodzi, gdy strona bierze to, co wpisał odwiedzający, i wkleja to wprost do jednego z takich zapytań. Jeśli odwiedzający wpisze SQL zamiast zwykłego tekstu, baza danych nie zauważy różnicy i wykona polecenie atakującego tak, jakby napisała je sama strona. Nazwę często skraca się do SQLi.

Jak przebiega atak SQL injection

Wyobraź sobie pracownika banku, który każdą karteczkę od klienta przekazuje słowo w słowo ludziom ze skarbca. Zwykła karteczka mówi „pokażcie mi moje saldo”. Podchwytliwa mówi „pokażcie mi moje saldo, a przy okazji otwórzcie wszystkie skrytki”. Jeśli pracownik nigdy wcześniej nie czyta karteczki, ludzie ze skarbca robią, co tam napisano.

Na stronie internetowej kroki wyglądają zwykle tak:

1. Atakujący szuka miejsca, które wysyła tekst do bazy danych: formularza logowania, wyszukiwarki, formularza kontaktowego albo samego adresu strony, na przykład strony produktu kończącej się na „?id=25”.
2. Wpisuje krótki fragment SQL zamiast zwykłego tekstu. Znany przykład to wpisanie ' OR '1'='1 w polu hasła w formularzu logowania.
3. Strona bez sprawdzania dokleja ten tekst do własnego zapytania. Zapytanie brzmi teraz mniej więcej tak: „wpuść tę osobę, jeśli hasło jest poprawne albo jeśli 1 równa się 1”.
4. Ponieważ 1 zawsze równa się 1, baza danych odpowiada tak, a atakujący loguje się, nie znając żadnego hasła.

Niektóre ataki są cichsze. Przy ślepym SQL injection strona nie pokazuje żadnych danych, więc atakujący zadaje bazie pytania z odpowiedzią tak lub nie i patrzy, jak reaguje strona albo ile czasu się ładuje. Ręcznie to powolna praca, dlatego atakujący zlecają ją darmowym automatycznym narzędziom.

Co może zrobić atakujący

Gdy baza danych zaczyna wykonywać jego polecenia, szkody zależą od tego, na co pozwala konto bazodanowe strony. Często jest to dużo więcej, niż strona potrzebuje. Atakujący może zdołać:

• odczytać prywatne dane, takie jak imiona i nazwiska, adresy, e-maile i historię zamówień klientów, dokumentację medyczną albo zapisane hasła
• zalogować się jako inny użytkownik, także jako administrator
• zmienić dane, na przykład ceny, salda albo status zamówień
• usunąć całe tabele lub całą bazę danych
• w niektórych konfiguracjach dostać się do samego serwera i zostawić na nim szkodliwe pliki

Dlaczego to ważne dla Twojej firmy

SQL injection to jeden z najstarszych ataków w sieci i wciąż się zdarza. OWASP, otwarta społeczność, która publikuje znaną listę OWASP Top 10 zagrożeń dla aplikacji internetowych, od lat trzyma ataki typu injection na tej liście. Łatwo go spróbować, a wiele stron wciąż ma jakiś zapomniany formularz, który go przepuszcza.

Dla właściciela firmy prawdziwa strata rzadko jest techniczna. To wyciek listy klientów, sklep sprzedający po złej cenie, system rezerwacji, który traci tydzień wizyt, albo wiadomość, którą musisz wysłać klientom, że ich dane wyciekły. W wielu krajach przepisy o ochronie danych, takie jak RODO (GDPR), wymagają też, by chronić dane osobowe i zgłaszać wycieki.

Czy każdy formularz na Twojej stronie powstał z myślą o tym ryzyku? Strony złożone w pośpiechu ze starych wtyczek albo zmieniane przez lata przez wiele osób częściej ukrywają słaby punkt.

Jak chronić stronę przed SQL injection

Główne rozwiązanie jest dobrze znane i działa. Większość ochrony zależy od tego, jak zbudowano stronę, więc to dobre pytania do Twoich programistów albo dostawcy.

• Prepared statements. Nazywa się je też zapytaniami parametryzowanymi. Strona wysyła zapytanie i tekst odwiedzającego osobno, więc baza danych zawsze traktuje ten tekst jako zwykłe dane, nigdy jako polecenie. To najważniejsza ochrona. Nowoczesne frameworki, takie jak Laravel, robią to domyślnie, gdy programiści korzystają z ich wbudowanych narzędzi do bazy danych.
• Sprawdzanie danych wejściowych. Pole na numer telefonu powinno przyjmować tylko cyfry, a pole daty tylko daty. Wczesne odrzucanie dziwnych danych zamyka wiele drzwi.
• Najmniejsze uprawnienia. Konto, przez które strona łączy się z bazą, powinno mieć tylko te uprawnienia, których potrzebuje. Publiczna strona wyszukiwania nie ma żadnego powodu, by usuwać tabele.
• Oszczędne komunikaty o błędach. Szczegółowy błąd bazy danych na ekranie daje atakującemu mapę. Pokazuj odwiedzającym krótki, prosty komunikat, a szczegóły trzymaj w prywatnych logach.
• Aktualizacje. Aktualizuj platformę, wtyczki i biblioteki, bo stare wersje często mają znane luki.
• Web application firewall. To filtr przed stroną, który blokuje wiele znanych wzorców ataków, zanim dotrą do Twojego kodu. Pomaga, ale nie naprawia niebezpiecznego kodu.
• Regularne testy. Test penetracyjny (bezpieczny, zaplanowany atak przeprowadzany przez ekspertów) i skanowanie podatności znajdują słabe punkty, zanim zrobi to atakujący.

Tak wypadają niektóre codzienne nawyki w porównaniu:

Częste błędy

• Zaufanie do sprawdzania w przeglądarce. Sprawdzanie, które działa na urządzeniu samego odwiedzającego, łatwo obejść, więc serwer musi sprawdzić wszystko jeszcze raz.
• Przekonanie, że mała strona jest bezpieczna. Automatyczne narzędzia przeszukują ogromną liczbę stron, nie patrząc na ich wielkość.
• Poprawienie jednego formularza i zapomnienie o reszcie. Wyszukiwarka, filtry, adres strony i API za aplikacją mobilną potrzebują tej samej troski.
• Przechowywanie haseł zwykłym tekstem. Jeśli dane wyciekną, hasła zapisane z silnym hashowaniem (zamienione w pomieszany kod, którego nie da się odczytać z powrotem) dużo trudniej wykorzystać.
• Poleganie wyłącznie na firewallu. Filtr daje Ci czas. Niebezpieczne zapytanie za nim i tak trzeba naprawić.

Jak możemy pomóc

W Linkysoft testy pod kątem SQL injection są częścią naszych usług z zakresu cyberbezpieczeństwa. Przeprowadzamy bezpieczne, symulowane ataki na Twoją stronę, aplikację i API, przeglądamy kod i dajemy Ci zrozumiałą listę tego, co znaleźliśmy, oraz sposobów naprawy. Po poprawkach testujemy ponownie. Sprawdza się to także przy stronach zbudowanych przez inne zespoły, a bezpłatna kontrola bezpieczeństwa to łatwy pierwszy krok.

Planujesz nowy system? Nasze aplikacje internetowe i systemy zarządzania są bezpieczne od etapu projektu, ze wzmocnieniem według OWASP Top 10 i testem penetracyjnym przed startem.