SQL injection — co to jest, jak działa i jak się chronić? Przykład w PHP i Pythonie

PawełInstruktor Cyberium Opublikowano 9 października 2026 12 min czytania Poziom: Początkujący

Co to jest SQL injection?

SQL injection (SQLi, po polsku: wstrzyknięcie SQL) to podatność aplikacji, w której dane od użytkownika zostają wklejone do zapytania SQL i baza danych wykonuje je jak fragment polecenia, a nie jak zwykłą wartość.

SQL to język, w którym aplikacje rozmawiają z bazami danych (MySQL, PostgreSQL, SQLite) — używa go sklep pytający o produkty, formularz logowania i panel z listą zamówień.

W katalogu słabości CWE ma ona numer CWE-89, a źródło problemu jest zawsze to samo: pomieszanie kodu (polecenia SQL) z danymi (tym, co wpisał użytkownik).

Jak działa atak SQL injection?

Atak SQL injection działa, bo aplikacja skleja stały tekst zapytania z danymi od użytkownika, a baza nie odróżnia, co pochodzi od programisty, a co od gościa strony.

Jeśli w kroku 2 aplikacja przekaże dane osobno od polecenia (zapytanie parametryzowane), krok 3 nie zachodzi.

SQL injection — przykład podatnego kodu i jego poprawki

Poniższy przykład SQL injection pochodzi z typowego scenariusza laboratoryjnego: prosta wyszukiwarka produktów w aplikacji testowej, uruchomionej we własnym środowisku do ćwiczeń. Pokazujemy, dlaczego kod jest podatny i jak go naprawić — w PHP i w Pythonie.

Podatny kod w PHP — sklejanie zapytania

<?php
// PODATNE — dane od użytkownika wklejone w tekst zapytania
$nazwa = $_GET['nazwa'] ?? '';
$sql = "SELECT id, nazwa, cena FROM produkty WHERE nazwa = '$nazwa'";
$wynik = $pdo->query($sql);

Gdy użytkownik wpisze rower, baza dostanie zapytanie ... WHERE nazwa = 'rower' i wszystko działa. Problem pojawia się, gdy w polu znajdzie się apostrof. Klasyczny, podręcznikowy przykład to wartość ' OR '1'='1 — po wklejeniu zapytanie wygląda tak:

SELECT id, nazwa, cena FROM produkty WHERE nazwa = '' OR '1'='1'

Warunek '1'='1' jest zawsze prawdziwy, więc baza zwraca wszystkie wiersze tabeli, a nie tylko szukany produkt. Ten sam błąd w formularzu logowania może oznaczać wejście na cudze konto.

Poprawiony kod w PHP — PDO i zapytanie parametryzowane

<?php
$pdo = new PDO('mysql:host=localhost;dbname=sklep;charset=utf8mb4', $uzytkownik, $haslo, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false, // natywne zapytania przygotowane
]);

// BEZPIECZNIE — treść zapytania jest stała, dane idą osobno jako parametr
$stmt = $pdo->prepare('SELECT id, nazwa, cena FROM produkty WHERE nazwa = :nazwa');
$stmt->execute(['nazwa' => $_GET['nazwa'] ?? '']);
$produkty = $stmt->fetchAll(PDO::FETCH_ASSOC);

Zapytanie parametryzowane (prepared statement) ma w miejscu wartości znacznik — tu :nazwa. Struktura zapytania jest ustalona, zanim trafi do niej wartość: sterownik przekazuje ją osobno do bazy albo — w trybie emulacji, domyślnym w PDO dla MySQL — sam ją bezpiecznie wstawia. W obu przypadkach wartość nie jest interpretowana jako kod SQL. Dokumentacja PHP mówi wprost: parametrów nie trzeba ujmować w cudzysłowy, bo zajmuje się tym sterownik, a aplikacja, która używa wyłącznie zapytań przygotowanych, jest chroniona przed tym atakiem — pod warunkiem, że żadnej innej części zapytania nie buduje z niezabezpieczonych danych.

Ten sam przykład w Pythonie — sqlite3

import sqlite3

con = sqlite3.connect("sklep.db")
nazwa = input("Szukaj produktu: ")

# PODATNE — f-string wkleja dane w treść zapytania
cur = con.execute(f"SELECT id, nazwa, cena FROM produkty WHERE nazwa = '{nazwa}'")

# BEZPIECZNIE — znacznik ? i wartość przekazana osobno (krotka)
cur = con.execute("SELECT id, nazwa, cena FROM produkty WHERE nazwa = ?", (nazwa,))
print(cur.fetchall())

Dokumentacja Pythona 3.15 każe zamiast operacji na napisach używać znaczników ? lub nazwanych (:nazwa). Zasada jest ta sama w każdym języku: nigdy nie skleja się zapytania z danymi — dane przekazuje się osobno.

Czego nie da się sparametryzować? Sortowanie i nazwy kolumn

Znacznik parametru zastępuje tylko wartość. Nazwy tabel i kolumn czy kierunek sortowania (ORDER BY ... ASC/DESC) to część struktury zapytania — OWASP zauważa, że nazw tabel i kolumn nie da się escapować, a Cheat Sheet zaleca dla nich i dla kierunku sortowania listę dozwolonych wartości ustaloną w kodzie:

<?php
// Użytkownik wybiera klucz, a aplikacja podstawia własną, znaną wartość
$kolumny = ['nazwa' => 'nazwa', 'cena' => 'cena'];
$kolumna = is_string($_GET['sortuj'] ?? null) ? ($kolumny[$_GET['sortuj']] ?? 'nazwa') : 'nazwa';
$kierunek = (($_GET['kierunek'] ?? '') === 'malejaco') ? 'DESC' : 'ASC';

$stmt = $pdo->prepare(
    "SELECT id, nazwa, cena FROM produkty WHERE nazwa LIKE :fraza " .
    "ORDER BY $kolumna $kierunek"
);
$stmt->execute(['fraza' => '%' . ($_GET['q'] ?? '') . '%']);

Do zapytania nie trafia nic, czego programista wcześniej nie wpisał w kod — tekst od użytkownika służy tylko do wyboru z gotowej listy.

Jakie są rodzaje SQL injection?

Rodzaje SQLi dzieli się najczęściej według tego, jak atakujący dowiaduje się o wyniku zapytania: in-band (wynik widać w odpowiedzi aplikacji), blind (wynik trzeba wywnioskować) i out-of-band (wynik wychodzi innym kanałem).

In-band — wynik widać w odpowiedzi aplikacji

Najprostszy rodzaj: dane lub komunikat błędu bazy pojawiają się w tej samej odpowiedzi (warianty error-based i UNION-based, w którym operatorem UNION dokleja się drugie zapytanie).

Blind — ślepe wstrzyknięcie SQL

Aplikacja nie pokazuje wyników ani błędów, więc według PortSwigger atakujący wnioskuje z różnic w odpowiedzi (boolean-based) albo z jej opóźnienia (time-based) — wolniej, ale równie skutecznie.

Out-of-band — dane wychodzą innym kanałem

Zapytanie zmusza serwer bazy do połączenia sieciowego, najczęściej zapytania DNS, z serwerem atakującego. To rzadszy rodzaj, zależny od funkcji bazy i od tego, czy serwer może łączyć się z internetem.

Second-order — atak drugiego rzędu

Dane zapisane w bazie zostają później użyte w innym zapytaniu bez parametryzacji — dlatego dane z własnej bazy też traktuj jak niezaufane.

Jakie są skutki ataku SQLi?

Skutkiem udanego ataku SQLi jest najczęściej nieuprawniony dostęp do danych, a w gorszych przypadkach ich zmiana i przejęcie aplikacji lub serwera.

• Wyciek danych — odczyt tabel z danymi klientów, skrótów haseł, tokenów i kluczy API.
• Ominięcie logowania — zmiana warunku w zapytaniu sprawdzającym login i hasło.
• Zmiana lub usunięcie danych — np. podmiana cen, uprawnień, numerów kont.
• Eskalacja uprawnień i wykonanie kodu — CISA w katalogu KEV opisuje podatność SQLi w Drupalu (CVE-2026-9082) jako taką, która może prowadzić do podniesienia uprawnień i zdalnego wykonania kodu.

Skala skutków zależy od uprawnień konta, którym aplikacja łączy się z bazą — stąd zasada minimalnych uprawnień.

Czy wstrzyknięcie SQL to nadal problem w 2026 roku?

Tak — to jedna z najstarszych podatności aplikacji webowych, a wciąż trafia do katalogów aktywnie wykorzystywanych luk.

Miejsce SQL injection w OWASP Top 10:2025

W OWASP Top 10:2025 wstrzyknięcie SQL należy do kategorii A05:2025 Injection, która spadła z 3. na 5. miejsce. OWASP opisuje SQLi jako podatność o niskiej częstotliwości i dużym wpływie, z ponad 14 tys. CVE (publicznych identyfikatorów podatności). Całą listę 2025 z przykładami omawiamy w artykule OWASP Top 10 po polsku.

Przypadki z 2026 roku: CISA KEV i CERT Polska

Do katalogu KEV amerykańskiej agencji CISA (Known Exploited Vulnerabilities — podatności aktywnie wykorzystywane) w 2026 roku, według stanu na 9 października, dodano 8 podatności tego typu. Wybrane przykłady:

Najbardziej pouczający jest LiteLLM — bramka do wywoływania modeli językowych. Według opisu w NVD w wersjach od 1.81.16 do wersji przed 1.83.7 zapytanie sprawdzające klucz API „mieszało wartość klucza przekazaną przez wywołującego z tekstem zapytania, zamiast przekazać ją jako osobny parametr”. To błąd z naszego przykładu, tylko w narzędziu, które pilnuje kluczy do modeli AI: nowa warstwa technologii stoi na starych fundamentach i dziedziczy ich słabości. Więcej w artykule czy warto uczyć się cyberbezpieczeństwa w czasach AI.

Polski przykład to Simple.ERP: CERT Polska opublikował 26 lutego 2026 roku informację o podatności typu SQLi, której przyczyną był brak walidacji danych wejściowych. Ujawnienie koordynował CERT Polska w procesie CVD — tą drogą może zgłosić lukę każdy, kto trafi na nią w polskim oprogramowaniu.

Jak się chronić przed SQL injection? Zasady OWASP

Najskuteczniejsza ochrona przed SQLi to zapytania parametryzowane — tak zaczyna listę obron OWASP SQL Injection Prevention Cheat Sheet (stan na 9 października 2026).

• ORM też pomaga — jeśli używasz go zgodnie z przeznaczeniem. OWASP Top 10:2025 jako preferowaną opcję wskazuje bezpieczne API — parametryzowany interfejs albo ORM (w praktyce np. Doctrine, Django ORM, SQLAlchemy). Surowe zapytania sklejane w ORM-ie są tak samo podatne.
• Walidacja danych wejściowych to dodatek. OWASP pisze, że pozytywna walidacja po stronie serwera „nie jest pełną obroną” — sprawdzaj format, ale nie traktuj tego jako ochrony przed SQLi.
• Minimalne uprawnienia ograniczają szkody, ale nie zapobiegają atakowi.
• Komunikaty błędów dla użytkownika — ogólne. Szczegóły błędu bazy zapisuj w logach, a nie wyświetlaj na stronie, bo ułatwiają wariant error-based.

Jak legalnie sprawdzić, czy aplikacja jest podatna?

Aplikację pod kątem wstrzyknięcia SQL sprawdzasz legalnie tylko wtedy, gdy jest twoja albo masz pisemną zgodę właściciela na test w ustalonym zakresie. Trzy drogi:

1. Przegląd własnego kodu — znajdź zapytania sklejane z tekstem (., f-stringi, +) i zamień je na parametry.
2. Testy we własnym środowisku — kopia aplikacji na twoim komputerze, nie produkcja.
3. Laboratoria do nauki — celowo podatne aplikacje stworzone do ćwiczeń.

Gdzie nauczyć się SQLi w praktyce?

SQLi najlepiej zrozumieć, przechodząc atak w laboratorium, a potem naprawiając kod. Do wyboru masz kilka dróg, które można łączyć.

Jak wygląda nauka SQLi w Cyberium?

W Cyberium — polskim kursie cyberbezpieczeństwa online — SQLi ma własny moduł w szkoleniu 7 „Atakowanie aplikacji webowych — Podstawy” (poziom „Średni”: 3 moduły, 26 lekcji, 15 laboratoriów praktycznych). Moduł „SQL Injection” obejmuje:

• wprowadzenie do SQL i baz danych (MySQL),
• różne techniki ataków — od technik Union po zaawansowane,
• SQLmap — narzędzie automatyzujące wstrzyknięcia SQL — gdy już rozumiesz, co narzędzie robi za ciebie.

Umiejętności sprawdzasz w laboratoriach i w misjach projektowych #03 i #04 do portfolio i CV. Wcześniej w tym szkoleniu poznajesz Burp Suite, IDOR i ataki na formularze logowania. Pozostałe ataki typu injection czekają w szkoleniu 8 „Atakowanie aplikacji webowych — techniki zaawansowane”: XSS, Command Injection (wstrzykiwanie poleceń systemowych) oraz LFI i RFI.

Lekcję o SQLmap możesz obejrzeć przed zakupem: to jedna z dwóch bezpłatnych lekcji DEMO na stronie kursu. Prowadzący pokazuje w niej, jak szybko narzędzie dociera do bazy danych w laboratorium — i dlaczego trzeba nim posługiwać się ostrożnie, bo może nieodwracalnie uszkodzić bazę. Pokazuje też zasadę pracy pentestera: podatność najpierw znajduje się ręcznie, a w raporcie dla klienta wystarczy kilka rekordów jako dowód — bez zrzucania całej bazy.

Co jeszcze daje taka droga nauki:

• Po polsku i w jednej kolejności — od pierwszego laboratorium i Linuksa (szkolenia 1–2), przez metodykę pentestów (szkolenie 3), do aplikacji webowych (szkolenia 7–8).
• Praktyka przede wszystkim — w programie podział 80/20 między praktyką a teorią; łącznie 57 laboratoriów i 5 misji projektowych.
• Laboratoria w przeglądarce — CyberBox, czyli Kali Linux w przeglądarce, bez instalacji.
• Raport jak w pracy pentestera — w szkoleniu 6 tworzysz raport z pentestu krok po kroku, a jako bonus dostajesz szablon raportu gotowy do wykorzystania.
• Wsparcie eksperta i aktualizacje przez cały dostęp.
• Dostęp od razu po zakupie, subskrypcja z rezygnacją w każdej chwili.
• Egzamin praktyczny C:CCE na końcu — test penetracyjny maszyny i raport; po zaliczeniu dostajesz certyfikat.

Na start przyda ci się plan z artykułu podstawy cyberbezpieczeństwa: jak zacząć w 30 dni, a szerszą ścieżkę rozpisaliśmy w planie nauki od podstaw w 8 krokach. Program wszystkich szkoleń znajdziesz w programie kursu cyberbezpieczeństwa.

Najczęstsze pytania (FAQ)

Podsumowanie

Wstrzyknięcie SQL to prosty błąd — dane od użytkownika mieszają się z poleceniem dla bazy — który w 2026 roku wciąż trafia do katalogu aktywnie wykorzystywanych podatności, także w narzędziach AI. Ochrona: zapytania parametryzowane, lista dozwolonych wartości i minimalne uprawnienia. Najlepiej zrozumiesz to w laboratorium — po polsku i ze wsparciem eksperta w kursie cyberbezpieczeństwa Cyberium.