SQL-injekciók elleni védelem létrehozása és fejlesztése

SQL-injekció védelem magánügyfeleknek

Az SQL-injekció védelem akkor fontos, ha egy weboldalon űrlap, belépés, kereső, rendelési felület vagy bármilyen adatbekérés működik, és ezek az adatok adatbázissal kerülnek kapcsolatba. A cél egyszerű. A felhasználó által beírt szöveg ne tudjon parancsként lefutni az adatbázisban. Egy magánügyfél általában nem technikai részleteket keres, hanem azt szeretné tudni, hogy biztonságban van-e az oldala, javítható-e a hiba, mennyibe kerül a munka, és hogyan lehet átadni a feladatot egy távolról dolgozó szakembernek.

Én azt látom, hogy sok weboldalnál a gond nem látványos hibával kezdődik. Az oldal működik, a kapcsolatfelvételi űrlap elküldi az üzenetet, a belépési oldal beenged, a kereső találatot ad. Mégis lehet mögötte olyan programozási hiba, amely miatt egy támadó megpróbálhat hozzáférni adatokhoz, módosíthat tartalmat, vagy túlterhelheti a rendszert. A védelem nem csak nagy webáruházaknál fontos. Egy kisebb bemutatkozó oldalnál is gondot okozhat, ha az adatbázisban ügyféladatok, ajánlatkérések vagy belépési adatok vannak.

A Qjob.hu felületén magánszemélyek is kereshetnek olyan fejlesztőt vagy webbiztonsággal foglalkozó szabadúszót, aki távolról átnézi a hibás részeket, javaslatot ad, majd javítja a kódot. Itt nem céges csomagokról van szó, hanem konkrét feladatokról. Ez sok esetben kényelmesebb, mert az ügyfél nem teljes rendszert akar átépíteni, hanem egy jól körülírt problémát szeretne megoldani.

SQL-injekció elleni védelem kockázatai

Az SQL-injekció elleni védelem hiánya azért veszélyes, mert a támadás gyakran normál beviteli mezőkön keresztül indul. Ilyen lehet a keresőmező, a kapcsolatfelvételi űrlap, a hírlevél feliratkozás, a bejelentkezés, a jelszó visszaállítás vagy a termékszűrő. A támadó nem feltétlenül tör be látványosan. Elég lehet egy rosszul kezelt adatmező, ahol a rendszer nem adatként, hanem parancsrészletként kezeli a beküldött tartalmat.

Szerintem a legnagyobb félreértés az, hogy sokan csak akkor kérnek segítséget, amikor már baj van. Pedig egy egyszerű sérülékenységi ellenőrzés olcsóbb és gyorsabb lehet, mint egy utólagos helyreállítás. Ha az adatbázisban személyes adatok vannak, a kockázat még komolyabb. Ilyenkor nem csak a weboldal működése számít, hanem az is, hogy az adatok ne kerüljenek illetéktelen kézbe.

Sokan ott hibáznak, hogy a fejlesztői feladatot csak kinézet vagy új funkció alapján adják ki. A biztonsági rész kimarad a megbeszélésből. A magánügyfél azt mondja, hogy kell egy űrlap vagy egy kereső, de nem kérdez rá arra, hogyan kezeli a rendszer a beírt adatokat. Tapasztalatom szerint ez később visszaüt. Egy olcsón vagy gyorsan összerakott megoldásnál gyakran nincs rendesen elkülönítve a felhasználói adat és az adatbázis lekérdezés.

SQL védelem árak és munkaidő

Az ár főleg attól függ, hogy csak ellenőrzésre van szükség, vagy tényleges javításra is. Egy kisebb oldalnál néhány űrlap átnézése gyors munka lehet. Egy régebbi egyedi rendszer, több adatbázis művelettel, már jóval több időt kér. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a szakember ilyenkor csak felszínesen nézi át a kódot, és nem ellenőrzi a javítás után a működést.

Az áraknál mindig érdemes pontosítani, hogy a szakember csak hibát keres, vagy javít is. Nem ugyanaz a feladat. Egy ellenőrzés után lehet kapni listát a problémákról, de ettől a weboldal még nem lesz biztonságosabb. A valódi érték akkor jön, amikor a hibás kódrészek módosulnak, a lekérdezések biztonságosabbá válnak, és a javítás után újra tesztelik a kritikus felületeket.

Megfelelő szakember kiválasztása

A megfelelő szakember kiválasztásánál nem elég azt nézni, hogy valaki tud weboldalt készíteni. Itt olyan fejlesztőre van szükség, aki érti az adatbázis kezelését, a szerveroldali kódot és a webes biztonság alapjait. Jó jel, ha a jelentkező nem azonnal árat mond, hanem előbb rákérdez a technológiára, az űrlapokra, a bejelentkezési részre, a használt adatbázisra és arra, hogy volt-e már támadásgyanú.

Én azt javaslom, hogy a magánügyfél kérjen rövid magyarázatot a tervezett javításról. Nem kell mély technikai választ várni. Elég, ha érthetően el tudja mondani, hogy miért veszélyes a jelenlegi működés, hogyan választja szét a felhasználói adatot az adatbázis parancstól, és hogyan ellenőrzi a javítás után az oldalt. Ha valaki csak annyit ír, hogy megoldom, az kevés.

Fontos a portfólió, de ezen a területen nem mindig látszik minden munka nyilvánosan. Biztonsági feladatoknál sok ügyfél nem akarja közzétenni, milyen hibát javítottak az oldalán. Ezért hasznosabb lehet egy rövid szakmai beszélgetés. A jó szabadúszó konkrét kérdéseket tesz fel. Például van-e hozzáférés a kódhoz, készül-e mentés, milyen adatbázis fut a háttérben, vannak-e naplók, és melyik felületnél merült fel a gyanú.

Távoli munka menete SQL javításnál

A távoli munka menete akkor biztonságos, ha a hozzáférések, a mentések és a kommunikáció előre tisztázva vannak. A szakembernek nem feltétlenül kell teljes hozzáférés mindenhez. Sokszor elég egy tesztkörnyezet, kódrészlet vagy ideiglenes hozzáférés. Ha éles oldalon kell dolgozni, előtte mentést kell készíteni. Ez nem formalitás. Egy rosszul módosított adatbázis lekérdezés működési hibát okozhat.

A munka általában rövid felméréssel indul. Az ügyfél leírja, milyen rendszerben készült az oldal, hol vannak űrlapok, milyen hibát észlelt, és van-e gyanús tevékenység. Ezután a fejlesztő átnézi a kódot, megkeresi a kockázatos lekérdezéseket, majd javaslatot ad. A javításnál gyakori megoldás az előkészített lekérdezések használata, a bemeneti adatok ellenőrzése, a jogosultságok csökkentése és a hibaüzenetek óvatosabb kezelése.

Volt olyan eset, amikor egy ügyfél csak annyit vett észre, hogy furcsa üzenetek jelennek meg a kereső használatakor. Nem tűnt nagy hibának. A vizsgálat közben kiderült, hogy a keresés közvetlenül összefűzte a beírt szöveget az adatbázis lekérdezéssel. A javítás nem volt hosszú, de fontos volt. A szakember átírta a lekérdezést, ellenőrizte a beviteli mezőt, és röviden leírta, mi változott. Az ügyfél ezután már azt is értette, miért nem elég csak eltüntetni a hibaüzenetet.

SQL-injekció védelem minőségi szempontjai

Az SQL-injekció védelem minősége nem abból látszik, hogy a weboldal kívülről ugyanúgy működik. Pont az a jó, ha a felhasználó nem vesz észre semmit, de a háttérben a rendszer már nem enged veszélyes adatkezelést. A minőségi javítás nem csak egyetlen sor átírása. Ide tartozik a bemenetek kezelése, a lekérdezések biztonságos felépítése, a hibák naplózása, a jogosultságok ellenőrzése és a tesztelés is.

Szerintem külön figyelni kell arra, hogy a szakember ne csak a látványos hibát javítsa. Ha egy űrlap sérülékeny volt, lehet, hogy más hasonló űrlap is ugyanazzal a mintával készült. Ilyenkor érdemes nem darabonként foltozni, hanem megnézni a közös kódrészeket. Ez néha drágábbnak tűnik, de hosszabb távon olcsóbb. Kevesebb ismétlődő hiba marad az oldalon.

A minőséghez hozzátartozik az átadás is. A magánügyfél kérjen rövid összefoglalót arról, hogy mely részek változtak. Nem kell hosszú szakmai dokumentáció. De legyen érthető, hogy a belépés, a keresés, az űrlap vagy a rendelési folyamat mely pontján történt javítás. Ez később hasznos, ha másik fejlesztő dolgozik az oldalon, vagy ha új funkció kerül be.

Gyakori hibák online megbízásnál

Az online megbízásnál az egyik gyakori hiba a túl rövid feladatleírás. Az, hogy javítani kell az SQL hibát, önmagában kevés. Jobb leírni, milyen oldalon van a probléma, melyik felületen jelentkezik, milyen technológia ismert, van-e tárhely vagy rendszergazdai hozzáférés, és készült-e már mentés. Minél pontosabb a leírás, annál kisebb az esélye a félreértésnek.

Másik hiba, hogy az ügyfél csak az árat nézi. Érthető, mert egy magánügyfél nem akar feleslegesen sokat fizetni. De biztonsági feladatnál az olcsó megoldás néha csak tüneti kezelés. Eltűnik a hibaüzenet, de a sérülékenység marad. Tapasztalatom szerint jobb egy közepes árú, ellenőrizhető javítás, mint egy nagyon olcsó beavatkozás, amely után senki nem tudja, mi változott.

Gondot okozhat az is, ha nincs próbakörnyezet. Ilyenkor minden javítás az éles oldalt érinti. Ez nem mindig kerülhető el, de legalább mentés kell. A hozzáféréseket is érdemes időben korlátozni. Ideiglenes jelszó, külön felhasználó és munka után visszavonható hozzáférés biztonságosabb, mint egy régi fő adminisztrátori belépés elküldése.

Biztonságos átadás és utóellenőrzés

A biztonságos átadás akkor jó, ha az ügyfél nem marad bizonytalanságban. A szakember jelezze, milyen módosítások történtek, mely felületek lettek tesztelve, és maradt-e olyan rész, amely külön fejlesztést igényel. Az utóellenőrzés nem luxus. Egy weboldalnál a javítás után is meg kell nézni, hogy a belépés, az űrlapok, a keresés és az adatmentés rendben működik-e.

A SQL-injekció védelem nem egyszeri varázsmegoldás, hanem a weboldal biztonságos működésének része. Ha később új űrlap, új kereső vagy új felhasználói felület készül, ott is ugyanazokat az elveket kell követni. Ezért hasznos, ha az ügyfél nem csak javítást kér, hanem rövid iránymutatást is a jövőbeni fejlesztésekhez.

A végeredmény akkor tekinthető elfogadhatónak, ha a weboldal továbbra is rendesen működik, a veszélyes adatbevitel nem tudja eltéríteni a lekérdezéseket, és az ügyfél érti, milyen munka készült el. Nem kell minden technikai részletet ismerni. De azt tudni kell, hogy a javítás valóban a kockázatot csökkentette, nem csak a látható tünetet.