Weblabor

A fórumon többször kerülnek elő olyan kérdések, amelyeknek véleményem szerint nem szabadna előkerülniük, ha lenne egy jó leírás arról, hogyan is működik a web. Annak idején én Stefan Münz SelfHTML-jéből tanultam, ami nagyon alapos és módszeres magyarázattal vezeti be a tanulni vágyót a webfejlesztés világába. Egyetlen hibája van: csak németül érhető el. Ugyan ennyire részletes leírásra nem vállalkozhatom, de ezúttal megpróbálom összeszedni a leggyakrabban elkövetett kezdő bakikat.

A haladóbb felhasználók kedvéért elmondom, hogy az itt leírt probléma felvetések nem a teljesség igényével készültek, sok helyen nem írom le a kevésbé triviális példákat. A cél itt az, hogy a kezdők el tudják kerülni a legnagyobb aknákat.

Szerver oldal vs. kliens oldal

Az első, a fórumokon általában erős intoleranciát kiváltó probléma az szokott lenni, ha a kérdező nincs tisztában azzal, mi hol fut. Nézzük meg tehát, hogyan is történik egy weboldal kiszolgálása.

• Beütjük a böngészőnkbe, hogy example.com.
• A böngésző az operációs rendszer segítségével megnézi a domain név milyen IP címhez tartozik.
• A böngésző megnyit egy kapcsolatot a szerver felé (IP cím szerint, itt már nincs domain) és lekéri a kezdőlapot. (Ez a / cím.)
• A szerver megnézi, hogy a kezdőlapra milyen fájlt kell visszaadni (index.html, index.php stb.).
• Ha a fájl valamilyen szerver oldali programozási nyelvben készült (PHP, Perl, Python), a szerver lefuttatja a programot. A program futásának az eredményét adja oda a böngészőnek. (Ergó nem, hacsak nincs hiba a szerver oldali kódban, nem tudod megnézni a forrást!)
• A böngésző a kapott fájlt (pl. HTML) megjeleníti és betölti a hozzá szükséges képeket, egyéb fájlokat illetve elkezdi futtatni a kliens oldali scripteket (pl. JavaScript).
• Ha a felhasználó linkre kattint, vagy mondjuk a JavaScript új adatot kér le, a böngésző új lekérdezést indít.

Mint látható, ez egy oda-vissza adogató játék. Ennek az egyik legfontosabb következménye, hogy nem lehet a JavaScript és a PHP között közvetlenül adatokat átadni, ahhoz új lekérdezést kell intézni a szerverhez.

Munkamenet kezelés

A fentiekből következik, hogy két lekérdezés között nincs olyan adat, ami megmaradna. Ahhoz, hogy adatot tudjunk átadni, munkameneteket kell használnunk. Erről itt a Weblaboron is született már cikk.

A különbség a GET és a POST között

Sokszor képzavar van a GET és POST kérések között, leggyakrabban az űrlapokkal kapcsolatban. Egyszerűen mondva: a GET kérések paraméterei látszanak a címsorban, a POST kéréseké nem. Bónuszként csak POST-tal lehet fájlt feltölteni. Néhány alapszabály:

• Keresést és hasonló dolgokat mindig GET-tel intézünk, hogy lehessen bookmarkolni.
• Módosító, törlő lekérdezéseket kizárólag POST-tal intézünk, különben valakinek küldök egy linket és ha be van lépve, letörli a cikkét. (Ha valaki kekeckedne: előbb átküldöm egy URL rövidítőn keresztül, és akkor biztos megeszi az ismerős.)
• Ez utóbbi esetben kötelező ellenőrizni a szerver oldalon, hogy tényleg POST kérés jött. ($_REQUEST-ből olvasni = nem menő).

Működési logika és a kiírás szeparálása

A legtöbb kezdő örül, ha sikerül valahogy összekalapálni a programot, nem igazán gondol a kódszervezésre, viszont a hibakeresésnél létfontosságú lehet. Mit értek ez alatt? Ha például adatot kérünk le adatbázisból, először gyűjtsük össze egy tömbbe, majd utána külön irassuk ki. Ezáltal a kettő között a hibakeresés idejére ki tudjuk iradni az adatot és nem kell nézegetni, hogy vajon a HTML-ben van a hiba, vagy a PHP kódban, ezzel felezve a kódmennyiséget, amiben hiba lehet. Például:

$r = mysql_query("SELECT * FROM comments WHERE topic_id=5");
$comments = array();
while ($a = mysql_fetch_assoc($r)) {
	$comments[] = $a;
}
/* Itt irhatjuk ki hibakereses eseten
a tombot, pl igy: var_dump($comments); */
foreach ($comments as $comment) {
	echo("Név: " . $comment['name'] . "\n");
	echo("Hozzászólás: " . $comment['comment'] . "\n\n");
}

Mennyivel tisztább így. :)

Escape-elés, bemeneti adatok ellenőrzése

Hasonlóan az előzőhöz, a kezdő örül, ha működik, nem igazán gondol a biztonságra. Nézzük a következő kódot:

mysql_query("SELECT COUNT(*) FROM users WHERE username='" . $_POST['user'] . "' AND password='" . $_POST['pass'] . "'");

Mi történik vajon, ha én most azt írom be a password paraméterbe, hogy:

' OR '1'='1

Ez esetben a lekérdezés így fog kinézni:

SELECT COUNT(*) FROM users WHERE username='admin' AND password='' OR '1'='1'

Mi történik? Be tudok lépni adminként, noha nem is volt meg a jelszavam. (A működése szerver beállítástól függhet, de az elvet jól demonstrálja.) Ez esetben a bemeneti adatok ellenőrzésének hiánya egy úgy nevezett SQL injection sebezhetőséghez vezetett. Ennél még sokkal rosszabb is lehett volna, a támadó a nevünkben lefuttathatott volna egy DROP DATABASE parancsot is. Nézzük a leggyakrabban elkövetett sebezhetőségeket és a védelmi lehetőségeket:

SQL injection

Az SQL injection, mint a fenti demonstráció is mutatja, egy SQL parancs beszúrását jelenti. Ellene úgy kell védekezni, hogy az általunk használt adatbázis kezelő réteg escape függvényét használjuk. PHP MySQL extension esetén ez a mysql_real_escape_string(). A fenti query tehát helyesen:

mysql_query("SELECT COUNT(*) FROM users WHERE username='" . mysql_real_escape_string($_POST['user']) . "' AND password='" . mysql_real_escape_string($_POST['pass']) . "'");

Figyelem! Senkinek még véletlenül se jusson eszébe, hogy saját szűrő függvényt ír! Az adatbázis rétegek és implementációk változhatnak, valamint közre játszhat a felhasznált karakterkódolás is, így ezek ismerete nélkül szinte lehetetlen jó védelmet írni!

HTML injection, XSS

Ha a felhasználó bemenetet bárhol ki is írjuk (enélkül viszonylag céltalan a dolog), akkor védekeznünk kell a HTML injection és az XSS ellen is. Egy részről azért, hogy ne tudja bárki tetszőleges HTML-lel szétbarmolni az oldalt, másrészt hogy ne tudjon olyan JavaScriptet beszúrni, ami alkalmas a felhasználó belépési adatainak az ellopására. Ha semmilyen HTML-t nem szeretnénk megengedni, akkor PHP esetén elég a htmlspecialchars() használata.

Ha JavaScriptnek szeretnénk átadni adatot, akkor azt a json_encode() hívással kell escape-elni.

Tanács: az ilyen escape-elést a kiíráskor végezzük, ne az adatok mentésekor. Így ha esetleg módosításokra van szükség a szűrő algoritmuson, nem kell újra konvertálnunk a már meglevő adatokat. Ezen felül ha változtatunk a kimeneti formátumon (például HTML helyett JSON-t küldünk), akkor igen csak nagy gondban lehetünk.

URL injection

Ha a felhasználó által adott értékeket linkbe írjuk, ki kell védenünk azt, hogy tetszőleges GET paramétert tudjon manipulálni az által, hogy beír egy kérdőjelet vagy egyenlőség jelet. Az ilyen irányú védelemre az urlencode() függvényt kell használni. Például így:

echo('<a href="/kereses?q=' . urlencode($elozokereses) '">előző keresés</a>');

CSRF

A CSRF jóval trükkösebb jószág. Legegyszerűbb példaként azt lehetne fölhozni, hogy valaki egy idegen oldalon csinál egy láthatatlan űrlapot, ami a mi oldalunkra küldődik el. Ha a felhasználó be van lépve mondjuk az admin oldalra, azt is elérheti a preparált oldal, hogy töröljük valamelyik cikkünket. Védekezni ez ellen nem egyszerű, a munkamenetünkbe be kell helyeznünk egy munkamenetenként egyedi változót (cannary), amit a formok elküldésekor ellenőrzünk. Ha nem stimmel, hibát írunk ki. Mivel a felhasználónak kiosztott cannaryhoz a másik oldal nem fér hozzá, ezért nem fogja tudni elküldeni a formot.

URL manipulation

Ha valamilyen paraméterek vannak az URL-ben, akkor nézzük meg, mi történik, ha manipuláljuk őket. Ha nem ellenőrizzük őket, könnyen lehet, hogy a felhasználó hozzá tud férni olyan dolgokhoz, amikhez nem kellene neki. Soha, de soha ne feltételezzük, hogy a felhasználó nem tudja, mit kell beírni a címsorba! A gyakorlat azt mutatja, hogy de, tudja. Megtalálja.

Remote code execution

Ez minden sebezhetőség lerondábbika. Hál' istennek nem gyakran fordul elő, de ha előfordul, akkor a támadó a szó legszorosabb értelmében bármit megtehet a weboldalunkon.

Leginkább akkor vagyunk veszélyben, ha a felhasználó által feltöltött adatot fájlba tesszük, majd include vagy require paranccsal olvassuk fel, illetve ha a rendszerünkben shell (shell_exec(), exec stb.) vagy eval() hívások vannak.

A védekezés egyszerű: ne használjunk ilyen hívásokat. Az esetek 99%-ában ezekre semmi szükség, pusztán a programozó volt lusta rendesen megírni a kódot.

Gyakorlati példa: Az egyik ilyen díszpinty az e107 rendszer volt, ahol a contact.php-ba szültek egy sebezhetőséget, aminek következtében a támadó a rendszeren elindíthatott egy programot a háttérben, ami elkezdte önmagát tovább terjeszteni és a helyi szervert zúzni. Hogy hogy sikerült ezt elkövetniük, foglamam sincs, de úgy általában jellemzi az e107 biztonságát és úgy általában kezet foghat a PHPFusion nevű haverjával. Persze szigorúan a személyes magánvéleményem szerint.

Karakterkódolás

Amin szinte minden kezdő elvérzik, ha nem előbb, akkor utóbb egy oldal költöztetésnél, az a karakterkódolás. Ez azért problémás, mert ha egyszer rosszul van bent az adatbázisban az adat, közel lehetetlen helyre rakni, főleg a szolgáltatás teljes leállítása nélkül

Az átlag weboldalnak három pontja van, ahol el lehet ezzel csúszni:

• A böngésző. A HTML karakterkódolását a Content-Type HTTP fejlécben vagy <meta> tagben tudjuk megadni. Az előbbi erősebb, mint az utóbbi, tehát ha a szerver gazdája beállított valamit, akkor a <meta> nem segít.
• A MySQL kapcsolat. Akármilyen furán hangzik, a MySQL kapcsolat és az eltárolt adat karakterkódolása nem feltétlenül azonos. A szerver automatikusan konvertál. Ha ezt nem jól állítjuk be, akkor az adatbázisban az ő szemszögéből értelmezhetetlen bináris szemét lesz, ami exportáláskor arcon is csapja az ember amolyan péklapát-stílusban.
• A MySQL adatbázis. Ha a táblák karakterkódolását nem jól állítjuk be, könnyen lehet, hogy a magyar ékezetes karaktereink elvesznek.

Best practice elven javaslom, hogy mindhárom karakterkódolás legyen azonos! Ha valahol inkonzisztencia lép fel, végeláthatatlan karakterkonverziós szívások lépnek fel! Mivel ma már minden weben haszált program támogatja az UTF-8-at, érdemes azt használni.

Gyorstalpaló a megfelelő lépések betartására:

• PHP-ból küldjük ki a megfelelő fejléceket: header("Content-Type: text/html; charset=UTF-8");
• A MySQL-hez való kapcsolódás után állítsuk be a kapcsolat karakterkódolását: mysql_query("SET NAMES utf8");
• MySQL tábla létrehozáskor biggyesszük oda a karakterkódolást: CREATE TABLE t1 (…) CHARACTER SET utf8 COLLATE utf8_general_ci;

Fórum tippek

Ha a fórumban kérdezel (nem csak itt, máshol is), érdemes úgy megszerkeszteni a kérdést, hogy a közösség az értelmezés helyett a probléma megoldására fordíthassa az agykapacitását. Erről külön blogbejegyzésben értekezem.