2026.08.30.
Weboldal fejlesztés és SEO

Weboldal biztonság SQL injection ellen paraméterezett lekérdezéssel.

Temesvári László

SQL Injection: Mi az és hogyan védjük meg a weboldalunkat paraméterezett lekérdezésekkel?

Üdvözöllek mindenkit, akit érdekel a weboldala biztonsága! Legyen szó egy kisvállalkozói honlapról, egy e-kereskedelmi rendszerről vagy egy nagyvállalati portálról, az SQL injection maradt az egyik legveszélyesebb és legelterjedtebb webes biztonsági rések egyike. Ma arról fogok beszélni, hogy miért olyan ijesztő ez a támadási mód, és főleg arról, hogyan lehet hatékonyan kivédeni paraméterezett lekérdezésekkel (prepared statements) – még akkor is, ha nem vagy fejlesztő.

Mi az az SQL injection (SQLi) és miért rémisztő?

Képzeld el, hogy weboldalad egy űrlapja (pl. bejelentkezés vagy keresőmező) közvetlenül belefűzi a felhasználó által beírt szöveget egy adatbázis-lekérdezésbe. Egy támadó ehelyett nem jelszót vagy keresőkifejezést ír, hanem egy kis, rosszindulatú SQL kódrészletet. Ez a kód „megtéveszti” a rendszert, és lehetővé teszi, hogy a támadó: – Illegálisan jelentkezzen be admin jogokkal – Személyes adatokat (név, email, jelszóhashek) szivárogtasson ki – Módosítsa vagy törölje az adatbázis tartalmát

Egy egyszerű, védtelen PHP kódrészlet, ami sebezhetővé teszi az oldalt:

// VÉDELMETLEN, SEBEZHETŐ MEGKÖZELÍTÉS
$username = $_POST['username']; // Tegyük fel, a felhasználó ezt írja: ' OR '1'='1
$password = $_POST['password'];
$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
// Az eredményül kapott SQL parancs így néz ki:
// SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'bármi'
// A '1'='1' mindig igaz, így a támadó bejut!

Egy ilyen támadás képes teljesen tönkretenni egy vállalkozás hírnevét és anyagi helyzetét.

A hős: a paraméterezett lekérdezés (Prepared Statement)

A szerencsénkre létezik egy bevált, hatékony és viszonylag egyszerűen implementálható védekezési módszer: a paraméterezett lekérdezés. Ennek a lényege, hogy szétválasztjuk az SQL parancs szerkezetét és a benne szereplő adatokat.

1. Előkészítjük az SQL sablont: Megmondjuk az adatbázisnak, hogy milyen struktúrájú lekérdezést fogunk futtatni, és hol lesznek az „űrlapok” (paraméterek), amiket később töltünk ki. 2. Kötjük a paramétereket: A felhasználótól kapott adatokat „bekötjük” a sablon előre meghatározott helyére. 3. Lefuttatjuk a lekérdezést: Az adatbázis már tudja, hogy a beérkező adatokat ne parancsként értelmezze, hanem pusztán *értékként* kezelje – akármit is ír be a felhasználó.

Így néz ki ez PHP-ben (PDO használatával), ami az egyik legelterjedtebb és legbiztonságosabb módszer:

// BIZTONSÁGOS MEGKÖZELÍTÉS PARAMÉTEREZETT LEKÉRDEZÉSSEL
$username = $_POST['username'];
$password = $_POST['password'];

// 1. Sablon előkészítése helyőrzőkkel
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");

// 2. Paraméterek kötése (értékként kezeli az adatokat)
$stmt->bindParam(':username', $username);
$stmt->bindParam(':password', $password);

// 3. Lekérdezés végrehajtása
$stmt->execute();

// A $username változó most is tartalmazhatja a '" OR '1'='1" szöveget,
// de azt az adatbázis már nem SQL kódként, hanem egy érvénytelen felhasználónévként kezeli.

Gyakori buktatók és „de én WordPress-et használok”

1. „Az ORM vagy a keretrendszer megoldja.” Igaz, hogy a modern keretrendszerek (Laravel, Symfony) és ORM-ek (Eloquent) alapból használnak paraméterezett lekérdezéseket. De! Ha saját, egyedi SQL lekérdezést írsz, te vagy felelős azért, hogy prepared statement-et használj. A komponensek biztonsága nem ment felül a saját kódodén.

2. „WordPress plugin-ok biztonságosak.” A WordPress maga és a népszerű plugin-ok nagy része odafigyel a biztonságra. A probléma általában az egyedi fejlesztésekkel vagy a régi, nem karbantartott plugin-okkal jön. Egyedi WordPress fejlesztésnél (pl. saját téma vagy plugin) mindenképpen használd a $wpdb->prepare() funkciót, ami a WordPress saját, biztonságos paraméterezését valósítja meg.

// Biztonságos egyedi lekérdezés WordPress-ben a $wpdb segítségével
global $wpdb;
$user_input = $_GET['search'];
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}posts WHERE post_title LIKE %s",
        '%' . $wpdb->esc_like($user_input) . '%'
    )
);

3. „Csak a bejelentkezést kell védeni.” Tévhit! Az SQL injection bármely olyan ponton bejuthat, ahol felhasználói bemenet kerül az adatbázisba: keresőmezők, szűrők, URL paraméterek (pl. ?id=10), szerkesztési űrlapok – gyakorlatilag minden.

Miért fontos ez a döntéshozóknak és kisvállalkozóknak?

1. Jogi és pénzügyi kockázat: Az adatvédelmi törvények (pl. GDPR) kemeny szankciókat írnak elő adatszivárgás esetén. 2. Hírnévvesztés: Egy feltört, eltűnt adatokkal küzdő weboldal halálos lehet az online megítélésre. 3. Költséghatékonyság: Egy biztonsági incidens utáni helyreállítás (adat-helyreállítás, újrafejlesztés, PR-kampány) sokszorosa a megelőzés költségének. 4. Versenyelőny: Egy biztonságos weboldal alapvető felhasználói bizalommal jár, ami hűséges ügyfélkörrel és jobb konverzióval térül meg.

Frontend és a teljes kép: egy kis példa

Bár az SQL injection védelem a backend (szerveroldali) feladat, a frontend is járulhat a biztonságos élményhez. Például egy Bootstrap-alapú űrlap megfelelő validációval azonnal visszajelzést ad a felhasználónak, és csökkenti a felesleges, potenciálisan rosszindulatú kérések számát a szerver felé.

<!-- Egy Bootstrap űrlap, ami elővalidál JavaScript-tel -->

  <div class="mb-3">
    <label for="username" class="form-label">Felhasználónév</label>
    
    <div class="invalid-feedback">Kérjük, adjon meg 3-50 karakter hosszú felhasználónevet.</div>
  </div>
  <div class="mb-3">
    <label for="password" class="form-label">Jelszó</label>
    
    <div class="invalid-feedback">A jelszó megadása kötelező.</div>
  </div>
  <button type="submit" class="btn btn-primary">Bejelentkezés</button>




// Egyszerű jQuery validáció az űrlap elküldése előtt
$('#loginForm').on('submit', function(event) {
  const form = this;
  if (!form.checkValidity()) {
    event.preventDefault();
    event.stopPropagation();
  }
  $(form).addClass('was-validated');
  // Ha valid, a POST kérés a backendre kerül, ahol a paraméterezett lekérdezés véd.
});

Összegzés: a biztonság alapköve

Az SQL injection megelőzése nem egy opcionális extra, hanem az alapvető fejlesztési hibátlanság része. A paraméterezett lekérdezések használata a legfontosabb és leghatékonyabb egyetlen lépés, amivel megvédheted az adatbázisod.

Ha vállalkozóként új weboldalt vagy webshopot rendelsz, kérdezd meg a fejlesztődet vagy az agentúrát, hogy hogyan kezelik az SQL injection kockázatot. Egy professzionális válasz mindig tartalmazza a „paraméterezett lekérdezéseket” vagy „prepared statement-eket”. Ha a válasz homályos, vagy csak annyi, hogy „a mi rendszerünk biztonságos”, érdemes tovább kérdezni.

Egy biztonságos weboldal nem egy luxuscikk, hanem a digitális létezés alappillére. A megfelelő alapokkal – mint amilyen a paraméterezett lekérdezés – alvó szemet együtt alhatsz, tudván, hogy a vállalkozásod kapuja erősen zárva van a legáltalánosabb digitális fenyegetéssel szemben is.

A weboldalon megjelenő szöveges és vizuális tartalmak előállításához mesterséges intelligenciát (AI) használunk.

Kapcsolódó cikkek