Ebben a cikkben az olyan webhely URL-ekben és egyéb jellegű hivatkozásokban (pl. tartalomban szereplő) alkalmazott sorszámok rossz koncepciójára szeretném irányítani a figyelmet, amelyet rengeteg helyen megtalálunk a működő weben.
Az erőforrások, mint például felhasználók, oldalak, cikkek sorszámozása szükséges. Az adatbázis táblák általános és egyszerű koncepciójából adódik, hogy beszúrásonként automatikusan növekvő (autoincrement), egész (integer, INT) mezőket használunk az egyes sorok egyedi azonosításához. Ezzel nincs is semmi probléma. A sorokat szükséges egyszerűen és egyértelműen megjelölni. De…
Hibás koncepció
Szerintem, rossz gondolat az, hogy sorszámot a felhasználókkal is közölni kell. Még ha közvetetten is, gyakorlatilag átadjuk az információt. A legtöbb tartalomkezelő rendszer ezt a modellt alkalmazza. Ez veszélyes és fölösleges. Miért kell a felhasználónak tudnia, hogy az adott erőforrás sorszáma éppen 16 vagy 120 az adatbázisban? Úgy vélem, hogy a lehető legkevesebb a rendszer működésére utaló információt szabad megosztani.
Aki már kicsit tapasztaltabb, az valamilyen elfedési módszert alkalmaz. Például Drupal rendszereknél ilyen az URL alias lehetőség, amellyel felüldefiniálhatunk rendszerútvonalakat. Ez a módszer jó, de sajnos nem véd meg a rosszindulatú keresgéléstől. Sajnos, ez a módszer sem iktatja ki az eredeti útvonalat.
Ez a koncepció mit sem törődik egy halom – a gyakorlati életben nagyon fontos – problémával:
Biztonság
- Egyértelmű, hogy a 0-ás vagy az 1-es felhasználó a rendszergazda.
- Próbálkozásos keresgélés
Kémkedés
- Hány cikk van a konkurencia oldalán?
- Hányadik rendelésnél tartanak (kamu rendeléssel vagy a korábban említett próbálgatással is kipróbálható).
Néhány eset
Drupal
A Drupal minden erőforrást a sorszáma alapján jelenít meg alapértelmezésben. Ha a felhasználók vagy a tartalmak darabszámát akarjuk megtudni, akkor nincs más dolgunk, mint írni egy kis scriptet, ami például felezéses módszerrel megkeresi a legnagyobb sorszámú usert vagy node-ot (csomópont, így hívja a Drupal nyelvezete a tartalmakat).
Übercart
Az Übercart egy webáruház rendszer. Itt is minden sorszám szerint megy. Nem is gondolnak rá, hogy a gyakorlatban milyen gáz úgy kinyitni egy webáruházat, hogy a felhasználó ilyen üzeneteket kapjon: “Köszönjük a megrendelését! Az Ön rendelésének száma: 1”. Ezt a megrendelést könnyedén eléred az /admin/store/orders/1 útvonalon. Remek.
Google Adsense, Analyitics fiók
Egészen meglepő, hogy a Google sem törődik ezzel a problémával. Hihetetlen egyszerűen kideríthető, hogy egy egy website tulajdonosa még milyen siteokat birtokol. Megkönnyítik a támadó/kém dolgát a Google sorszámozott azonosítói, amelyeket adatbázisba gyűjtve könnyedén összekapcsolhat tulajdonosokat, feltérképezhet kapcsolati hálózatokat.
Mit tegyek…?
… ahogy a reklámban is kérdezi a szegény háziasszony, amikor a vízkővel kell megküzdenie… :) Bocs…
A megoldás egyszerű lenne, “csak” arra lenne szükség, hogy a tervezők elválasszák egymástól a nyilvántartásban használt azonosítást a publikusan használt azonosítástól. Erre azt gondolom többet kell várni, mint amennyi ideje van a egyszerű webes kódernek, ezért más módszerekhez kell folyamodnia…
Sorszám megnövelése
Igen egyszerű módszer, ha az első alkalommal megnöveljük a sorszámot. Ennek módja rendszerenként eltérő lehet. Mindenképpen vizsgálni szükséges, hogy nem avatkozunk-e be a rendszer működésébe túlzottan. Javaslom, hogy “hivatalos” módszert keressünk. Érdemes az adott technológia (CMS, adatbázis-kezelő) nevével és az valami “increment ID” vagy hasonló keresést kiadni.
Nem rossz megtévesztés az sem, ha az azonosítót periodikusan növeljük. Alkalmaztam már néhány esetben ilyen módszert. Webáruház implementálásakor a felhasználói konfigurációs felületre ki is vezettem az cronnal lefutó inkrementálás minimális és maximális mértékét. A rendszer egy véletlen számot generált az intervallumban és azzal növelte az autoincrement aktuális értékét. Nem minden rendszernél lehet ezt megcsinálni. Előfordulhat, hogy követelmény a sorfolytonosság, vagy egyéb technikai problémákba ütközünk.
URL-eknél aliasolás
Hasznos lehet, a rendszer működésének elrejtésében, ha használunk valamilyen álneves módszert. A legtöbb rendszer támogat ilyesmit. Apache alatt príma URL-rewrite motor van, illetve most már az IIS 7 alatt is elérünk “gyári” rewrite-ot. A CMS rendszerek magasabb szinten is képesek kezelni az álnevek problémáját, sőt automatizált formában is.
Egy példa: Drupal alatt a Path és a Pathauto modulra van szükségünk az automatikus útvonal álnevek generálásához. Beállíthatjuk, hogy az egyes tartalomtípusokhoz tartozó útvonalak milyen séma alapján legyen generálva. Alapértelmezésben a Drupal a node/id módszert használja. Például egy új cikk az alábbi útvonalon érhető el: node/33. A pathauto modul hozzáadja a például a következő álnevet: cikkek/cikk_cime. Ez jó.
Sajnos, az eredeti útvonalon is elérhető marad az erőforrás, így csak félig oldottuk meg a problémát. Szükséges az eredeti útvonalak hozzáférhetetlenné tétele. Ezt könnyen megoldhatjuk egy rewrite sor beszúrásával, ami a ^node/.*$ regex kifejezésnek megfelelő oldalakat egy 404-es oldalra irányítja.
Egyedi megoldás
A fenti ötletekkel csak a felszín kapargatom. Úgy vélem, hogy az a legjobb, ha az ember egyedi megoldásokat alkalmaz. Nem sok biztonságosabb dolog van annál, mint amikor a támadó nem tudja, hogy mivel áll szemben. Soha nem értettem, hogy miért írják rá az emberek az autójukra, hogy milyen riasztó van benne. Csak a tolvajnak jó, nem kell annyi szerszámot vinnie…
Gyakorlati példa: Drupal node-ok száma
Az alább kis alkalmazás egy példa arra, hogy milyen egyszerű készíteni egy programot, amely kideríti, hogy egy Drupal oldalon hány darab beküldés van. Itt szeretném megelőzni az olyan megjegyzéseket, hogy “de, hát a törölt node-ok is benne vannak”, vagy “ez nem ad pontos adatot”. Minden ilyen felvetés jogos, de nem is a teljesen pontos eredmény a cél, itt kémkedésről beszélünk. A programot csak a példa kedvéért dobtam össze, nem igazán használható. Nincs benne se hibakezelés, se komoly GUI. Forráskód letölthető innen.
Például, ha a kémkedő bizonyos gyakorisággal megvizsgálja a fenti program által generált adatot, akkor nagy valószínűséggel tudhatja, hogy a konkurens siteon milyen gyakorisággal keletkeznek új tartalmak. Persze ez csak egy “érdekes adat”. Ha még hozzárak százat és ezeket adatbázisban tárolja, ne adj’ Isten akár több siteról is, akkor bizony lehet sokkal relevánsabb konkurencia kutatást végezni.
