SQL-iniekcja: czym jest niebezpieczna i jak ją zamknąć
SQL-iniekcja — to luka, w której tekst wprowadzony przez odwiedzającego trafia do zapytania do bazy danych nie jako wartość, a jako część komendy. W rezultacie osoba trzecia może odczytać, zmienić lub usunąć to, do czego nie powinna mieć dostępu.
Analogia dla właściciela strony
Jest archiwum i formularz: „przynieś sprawę numer ___”. Jeśli w rubryce z numerem ktoś dopisze „…a przy okazji wynieś całą szafę i zostaw drzwi otwarte”, a pracownik przeczyta formularz w całości jako polecenie — to zrobi. Nie archiwum jest zagrożone, lecz nawyk sklejania polecenia z obcego tekstu. Rozwiązanie — formularz, w którym numer sprawy zawsze pozostaje numerem i nigdy nie jest odczytywany jako komenda.
Co można stracić
| Co się dzieje | Jakie są konsekwencje |
|---|---|
| Odczyt obcych tabel | Wycieczka bazy klientów i zamówień — a z nią powiadomienia dla ludzi i pytania regulatora |
| Dostęp do kont | Hashe haseł administratorów, dostęp do panelu administracyjnego, kontrola nad stroną |
| Wpisanie obcego kodu do bazy | Zarażenie, które powraca nawet po oczyszczeniu plików — zob. złośliwy kod na stronie |
Jak to wpływa na SEO
Nie ma bezpośredniego czynnika rankingowego — wpływa na to skutek. Poprzez iniekcję do bazy wlewa się spamowy content i ukryte linki do obcych tematów. Dalej typowy scenariusz: wyszukiwarka przeszacowuje tematykę strony, pozycje spadają, część stron wypada z indeksu, a przy wpadnięciu domeny do baz niebezpiecznych stron przeglądarki wyświetlają ostrzeżenie i ruch się urywa.
Jak to wygląda w raporcie Security Shield
Skaner wysyła jedno nieszkodliwe próbne zapytanie do znalezionych parametrów i sprawdza, czy strona nie zwróci tekstu błędu bazy danych. Jeśli zwróci — pojawia się znalezisko „Wskaźnik SQL-iniekcji (błąd Bazy Danych)”: wysoka powaga, klasa CWE-89, kategoria OWASP A03:2021. W dowodzie widoczny jest fragment błędu, a adnotacja „wymaga weryfikacji” oznacza, że serwis rejestruje objaw, a nie włamał się do bazy.
Próba wykonywana jest tylko w płatnych trybach i na potwierdzonej domenie. Skaner patrzy z zewnątrz i widzi tylko te parametry, które znalazł na stronach — brak znaleziska nie oznacza, że iniekcji nie ma nigdzie. Co dokładnie jest sprawdzane — w artykule o Security Shield.
Błąd bazy w odpowiedzi oznacza, że obcy tekst dotarł do zapytania. Przekaż programiście adres strony i nazwę parametru z raportu. Ręczne eskalowanie cudzysłowów i „czarne listy” słów nie są rozwiązaniem.
Jak to zamknąć
- Parametryzowane zapytania. Główne rozwiązanie: tekst zapytania jest określany z góry, a wartości są przekazywane oddzielnie — przygotowanym wyrażeniem. Wtedy zawartość pola fizycznie nie może stać się częścią komendy.
- ORM lub warstwa zapytań frameworka. Nowoczesne biblioteki robią to domyślnie; problemy pojawiają się tam, gdzie zapytanie zbudowano ręcznie jako ciąg.
- Minimalne prawa użytkownika bazy. Konto strony prawie nigdy nie potrzebuje praw do usuwania tabel i pracy z plikami.
- Ukryj błędy techniczne przed odwiedzającym — wyjście debugowania powinno trafiać do logu, a nie na stronę.
- Aktualizuj CMS i rozszerzenia. Na typowych stronach iniekcja częściej pochodzi z podatnego wtyczki, niż z twojego kodu.
Jak nie dopuścić do powtórki
Umów się z programistą, że zapytania zbudowane przez konkatenację ciągów nie przechodzą przeglądu. Firewall przed stroną — to środek na czas poprawek, a nie zastąpienie przygotowanymi wyrażeniami. Po poprawkach powtórz głębokie skanowanie. Warto również skonsultować się z audytem strony — pokaże obce strony i linki, jeśli coś już trafiło do bazy.