Wstrzykiwanie SQL (SQLi) – jak się bronić w praktyce

Czym jest SQL injection?

SQL injection (SQLi) polega na tym, że atakujący wstawia do aplikacji fragmenty zapytania SQL (np. w formularzu, w parametrze URL). Jeśli aplikacja skleja wejście użytkownika z zapytaniem SQL bez escapowania lub parametryzacji, baza wykona ten kod. Skutkiem może być: odczyt cudzych danych, modyfikacja lub usunięcie danych, a w skrajnych przypadkach – przejęcie serwera.

SQLi jest w OWASP Top 10 (obecnie w kategorii Injection) i wciąż bardzo często występuje w audytach i pentestach.

Zasada nr 1: parametryzowane zapytania

Zamiast:

"SELECT * FROM users WHERE id = " + userInput

używaj prepared statements / zapytań parametryzowanych:

"SELECT * FROM users WHERE id = ?"  // i przekaż userInput jako parametr

Wtedy dane użytkownika są traktowane wyłącznie jako wartość, nigdy jako część składni SQL. To usuwa większość klasycznych SQLi.

ORM i builder zapytań

Dobre ORM-y (np. w Pythonie, Node, Javie) domyślnie parametryzują zapytania – pod warunkiem że nie używasz „surowych” fragmentów SQL z konkatenacją. Builder zapytań (Knex, SQLAlchemy itd.) też zwykle wymusza parametry. Uważaj na raw / execute z wstawionym stringiem od użytkownika.

Dodatkowe kroki

• Konto aplikacji w DB – ogranicz uprawnienia (np. tylko SELECT/INSERT/UPDATE na potrzebnych tabelach, bez DROP ani zarządzania użytkownikami).
• Walidacja wejścia – nawet przy parametryzacji: jeśli pole ma być liczbą, przyjmuj tylko liczbę; ogranicz długość i znaki tam gdzie to ma sens.
• Logowanie i monitoring – nietypowe zapytania lub błędy SQL mogą sygnalizować próby ataku.

Podsumowanie

Obrona przed SQLi sprowadza się w praktyce do: zapytań parametryzowanych (lub ORM) + minimalnych uprawnień w DB + walidacji wejścia. Pentest lub przegląd kodu potwierdzą, czy Twoja aplikacja jest odporna.

Planujesz [test bezpieczeństwa aplikacji](/testy-penetracyjne/)? SQLi jest jednym z pierwszych obszarów, które sprawdzam.