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
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? SQLi jest jednym z pierwszych obszarów, które sprawdzam.