SQL Injection w tworzeniu aplikacji mobilnych: co to jest, metody ataków i ochrona

Co to jest SQL Injection?

SQL Injection to podatność powstająca, gdy aplikacja tworzy zapytanie SQL poprzez konkatenację ciągów z danymi użytkownika. Osoba atakująca przekazuje do parametru zapytania specjalnie skonstruowany ciąg znaków, który zmienia strukturę polecenia SQL. Zamiast być danymi, wprowadzony ciąg staje się częścią kodu SQL, co pozwala atakującemu wykonywać dowolne zapytania do bazy danych. Według raportu Verizon Data Breach Report (2025), SQL Injection występuje w 8% wszystkich zbadanych wycieków danych.

Dlaczego SQL Injection jest nadal aktualny?

Pomimo znajomości podatności (pierwsze wzmianki — koniec lat 90.), SQL Injection występuje w nowoczesnych aplikacjach. Przyczyną jest czynnik ludzki: programiści dopuszczają konkatenację ciągów w kodzie, legacy-kod nie jest refaktoryzowany, a ORM-frameworki są używane nieprawidłowo (np. surowe zapytania z podstawianiem wartości przez ciągi). Według danych Veracode (2026), około 14% wszystkich przeskanowanych aplikacji zawiera co najmniej jedną podatność SQLi.

Co może zrobić osoba atakująca?

Udane wstrzyknięcie SQL daje atakującemu szeroki zakres możliwości: odczyt dowolnych tabel bazy danych, w tym skrótów haseł i danych osobowych użytkowników; modyfikacja i usuwanie rekordów; wykonywanie operacji administracyjnych (DROP TABLE, TRUNCATE); w niektórych konfiguracjach — zdalne wykonywanie poleceń przez xp_cmdshell (MSSQL) lub INTO OUTFILE (MySQL). Konsekwencje — od wycieku danych użytkowników do całkowitej utraty kontroli nad systemem.

Rodzaje wstrzyknięć SQL

Wstrzyknięcia SQL klasyfikuje się według sposobu wydobywania danych z bazy. Wybór metody zależy od tego, jak aplikacja przetwarza wyniki zapytania i komunikaty błędów. Klasyfikacja OWASP wyróżnia trzy główne typy: In-band (dane wydobywane tym samym kanałem), Inferential/Blind (wnioskowanie logiczne) i Out-of-band (dane przesyłane innym kanałem).

In-band SQL Injection (klasyczne)

Najczęstszy typ. Osoba atakująca wstrzykuje kod SQL do parametru zapytania, a wynik wstrzyknięcia jest widoczny bezpośrednio w odpowiedzi serwera. Dwa podtypy: Error-based (przez komunikaty błędów BD) i UNION-based (przez operator UNION SELECT). Error-based wykorzystuje informacje z komunikatów błędów, na przykład błąd składni MySQL, który może ujawnić nazwę tabeli lub strukturę zapytania. UNION-based pozwala połączyć wyniki legalnego zapytania z danymi z innych tabel bazy danych.

Blind SQL Injection (ślepe)

Stosowane, gdy aplikacja nie wyświetla wyników zapytania ani komunikatów błędów. Osoba atakująca zadaje pytania typu „tak/nie”, wysyłając zapytania z warunkami logicznymi i analizując różnicę w odpowiedzi serwera (np. czas odpowiedzi lub zawartość strony). Time-based Blind SQLi wykorzystuje funkcję opóźnienia (SLEEP, WAITFOR DELAY) do potwierdzenia warunków — jeśli strona ładuje się dłużej, warunek jest prawdziwy. Ta metoda jest bardzo wolna — wydobycie jednego rekordu może zająć godziny.

# Przykład Blind SQL Injection (time-based)
# Jeśli SQLi jest podatny, SLEEP(2) wykonuje się pod warunkiem
import requests
import time

payload = "' OR IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(2),0) -- "
url = "http://example.com/user?id=1" + payload

start = time.time()
response = requests.get(url)
elapsed = time.time() - start

# Jeśli odpowiedź przyszła po >2 sekundach — pierwsza litera hasła to 'a'
print(f"Time: {elapsed:.2f}s - First letter is 'a'" if elapsed > 2 else "First letter is not 'a'")

Out-of-band SQL Injection

Dane są przesyłane nie przez odpowiedź HTTP, ale przez alternatywne kanały: zapytania DNS, żądania HTTP do zewnętrznego serwera, SMTP. Stosowane, gdy aplikacja nie zwraca wyników zapytania i nie pokazuje błędów. MySQL obsługuje funkcję LOAD_FILE(), która może zainicjować zapytanie DNS, a MSSQL — xp_dirtree do wysyłania danych na zdalny serwer SMB. Out-of-band SQL Injection jest skuteczny, ale wymaga dodatkowych ustawień na serwerze atakującego i obecności określonych funkcji BD.

Jak działa wstrzyknięcie SQL?

Mechanizm SQL Injection opiera się na tym, że SQL używa cudzysłowów dla literałów ciągów. Jeśli aplikacja podstawia dane wejściowe użytkownika bezpośrednio do zapytania SQL bez escapowania, osoba atakująca może „zamknąć” ciąg i dodać dowolny kod SQL. Na przykład w zapytaniu SELECT * FROM users WHERE name = '$input' podstawienie ' OR '1'='1 zamienia zapytanie na SELECT * FROM users WHERE name = '' OR '1'='1', co zwraca wszystkich użytkowników.

Klasyczny przykład: ominięcie uwierzytelniania

Rozważmy formularz logowania z zapytaniem SELECT * FROM users WHERE username = '$user' AND password = '$pass'. Jeśli osoba atakująca wprowadzi w polu username admin' -- , a hasło pozostawi puste, wynikowe zapytanie staje się SELECT * FROM users WHERE username = 'admin' -- ' AND password = ''. Znaki -- komentują resztę zapytania, a warunek sprawdzania hasła jest wyłączony. Serwer zwraca rekord użytkownika admin, a atakujący loguje się do systemu bez znajomości hasła.

# Przykład SQL Injection — ominięcie uwierzytelniania
# PODATNY KOD: bezpośrednia konkatenacja ciągów
def login_vulnerable(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    cursor.execute(query)
    return cursor.fetchone() is not None

# username = "admin' --" zeruje sprawdzanie hasła
# BEZPIECZNA WERSJA: zapytanie sparametryzowane
def login_secure(username, password):
    query = "SELECT * FROM users WHERE username = %s AND password = %s"
    cursor.execute(query, (username, password))
    return cursor.fetchone() is not None

UNION-based: odczyt obcych tabel

Operator UNION SELECT pozwala połączyć wyniki dwóch zapytań SELECT. Jeśli osoba atakująca znajdzie podatny parametr, dodaje UNION SELECT z zapytaniem z innej tabeli. Na przykład: ' UNION SELECT username, password FROM admins --. Warunkiem powodzenia jest zgodność liczby kolumn w obu zapytaniach. Liczbę kolumn określa się przez ORDER BY (podstawienie ' ORDER BY 1--, następnie 2, 3... aż do błędu). Znając liczbę kolumn, atakujący podstawia UNION SELECT z taką samą liczbą pól.

SQL Injection w aplikacjach mobilnych

Aplikacje mobilne spotykają się z SQL Injection zarówno po stronie serwerowej (API), jak i po stronie klienta — w lokalnych bazach danych (SQLite, Realm). Chociaż ryzyko SQLi po stronie serwera w mobilnym API jest podobne do aplikacji webowych, lokalna BD tworzy dodatkowy wektor. Jeśli aplikacja przechowuje dane w SQLite i wykonuje zapytania z konkatenacją ciągów, złośliwe dane, które trafiły do lokalnej BD przez API, mogą spowodować SQLi przy późniejszym przetwarzaniu.

SQL Injection w SQLite na Android/iOS

Lokalna baza SQLite na urządzeniu jest również podatna na SQL Injection, jeśli aplikacja tworzy zapytania przez konkatenację ciągów. Content Providers na Androidzie i Core Data na iOS domyślnie używają parametryzacji, ale surowe zapytania wymagają uwagi programisty. SQLite nie obsługuje wielu zapytań przez średnik, co ogranicza możliwości atakującego, ale nie chroni przed odczytem danych przez warunki WHERE. Zawsze używaj selectionArgs w Androidzie i NSPredicate z parametrami w iOS.

SQL Injection przez API aplikacji mobilnej

API, do którego odwołuje się aplikacja mobilna, jest podatne tak samo jak każdy serwer webowy. Deweloperzy mobilni często uważają, że SQLi to problem tylko backendu, ale podatność powstaje na poziomie endpointu API, który przyjmuje parametry od klienta. Podział odpowiedzialności nie chroni: jeśli programista backendu zapomniał sparametryzować zapytanie, aplikacja mobilna użytkownika staje się wektorem ataku. Wymagaj od backendu używania ORM lub prepared statements.

// Przykład SQL Injection w lokalnym SQLite na Androidzie
// PODATNY KOD: bezpośrednia konkatenacja
fun getUserVulnerable(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = $userId", null
    )
}

// BEZPIECZNA WERSJA: parametryzacja przez selectionArgs
fun getUserSecure(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = ?",
        arrayOf(userId)
    )
}

Metody zapobiegania wstrzyknięciom SQL

Ochrona przed SQL Injection opiera się na prostej zasadzie: nigdy nie ufaj danym wejściowym użytkownika w zapytaniach SQL. Jedyną niezawodną metodą jest parametryzacja zapytań (prepared statements), w której kod SQL i dane są przesyłane oddzielnie. Wszystkie inne metody — escapowanie, walidacja, WAF — są dodatkowymi warstwami ochrony, ale nie zastępują parametryzacji. Według danych OWASP (2025), parametryzacja zapobiega 100% ataków SQL Injection.

Prepared Statements (zapytania sparametryzowane)

Podczas używania prepared statements zapytanie SQL jest najpierw kompilowane przez serwer BD bez danych, a następnie wartości parametrów są przesyłane osobno. Baza danych traktuje parametry jako dane, a nie jako wykonywalny kod. Nawet jeśli osoba atakująca przekaże ' OR '1'='1, BD interpretuje to jako wartość ciągu, a nie jako kod SQL. Prepared statements są obsługiwane przez wszystkie nowoczesne języki i frameworki: PDO w PHP, PreparedStatement w Javie, cursor.execute w Pythonie.

ORM-frameworki i Query Buildery

Nowoczesne ORM (Hibernate, Entity Framework, SQLAlchemy, Room) automatycznie używają parametryzacji podczas wykonywania zapytań, jeśli programista nie przechodzi na surowe zapytania. Jednak ORM nie chronią w pełni: konstrukcje takie jak @Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true) w JPA wymagają przekazywania parametrów przez nazwane parametry, a nie konkatenację. Query Buildery (Knex, jOOQ) również parametryzują zapytania domyślnie, jeśli nie używa się surowych metod.

Escapowanie ciągów (niezalecane jako główna metoda)

Escapowanie znaków specjalnych (mysql_real_escape_string) to przestarzała metoda, która nie chroni przed wszystkimi typami SQL Injection. Problem: escapowanie zależy od kodowania i może być ominięte przy użyciu wielobajtowych kodowań (np. GBK w systemach azjatyckich). Używaj escapowania tylko w legacy-kodzie, gdzie parametryzacja jest niemożliwa, i zawsze w połączeniu ze ścisłą walidacją typu danych wejściowych.

Zasada najmniejszych uprawnień dla BD

Konto aplikacji powinno mieć minimalnie niezbędne uprawnienia: SELECT, INSERT, UPDATE, DELETE — tylko do tych tabel, które są rzeczywiście potrzebne aplikacji. Zabroń używania DROP, TRUNCATE, CREATE dla konta aplikacyjnego. Ograniczy to szkody nawet w przypadku udanego SQL Injection: atakujący nie będzie mógł usunąć tabel ani wykonać operacji administracyjnych.

Narzędzia do wykrywania wstrzyknięć SQL

Regularne testowanie na SQL Injection powinno być częścią pipeline bezpiecznego rozwoju. Połączenie analizy statycznej, skanowania dynamicznego i ręcznego pentestu daje najlepsze wyniki. Według raportu Synopsys Cybersecurity Report (2025), automatyczne skanery znajdują do 70% podatności SQLi, jednak złożone ataki Blind wymagają ręcznego testowania.

• sqlmap — najpopularniejsze narzędzie do automatycznego wykrywania i wykorzystywania SQL Injection
• OWASP ZAP — darmowy skaner DAST z modułami aktywnego skanowania SQLi
• Burp Suite Scanner — profesjonalne narzędzie z automatycznym wykrywaniem SQL Injection
• SonarQube — statyczna analiza kodu pod kątem podatności, w tym wzorców SQLi
• CodeQL — semantyczna analiza kodu do wyszukiwania wstrzyknięć SQL w źródłach

Dla aplikacji mobilnych ważna jest również analiza lokalnego SQLite: sprawdź wszystkie wywołania rawQuery, zapytania ContentProvider i zapytania Room z rawQuery. Narzędzia: Android Studio Lint (wykrywa SQLi w SQLite), MobSF (Mobile Security Framework) do automatycznej statycznej i dynamicznej analizy APK/IPA. Zaleca się również testowanie endpointów API przez sqlmap z proxy przechwytującym ruch aplikacji mobilnej.