Tipikus Webshophibák Konstantinusz Kft. 2009
Tartalomjegyzék 1. Bevezetés...3 2. Tipikus webshop hibák forrásai...4 3. Tipikus hibák ismertetése...5 3.1. connection.inc...5 3.2. Tervezési hiba...5 3.3. Vásárlási folyamat...7 3.4. Kereső...8 3.5. Megfelelő szervert válasszunk...8 3.6. Adminisztrációs felület...9 3.7. Adatok tárolása...9 4. Követendő irányelvek...11
1. Bevezetés Senki sem kezdhet el egy szakmát úgy, hogy évtizedes tapasztalattal rendelkezik. Vannak hibák, amelyet a kezdők nagyobb valószínűséggel követnek el, mint a tapasztaltabb programozók. Az esettanulmányban nem részletezem, hogy milyen fontos a rendszerfejlesztés lépései szerint fejleszteni. Ezek nélkül készített webshop nem nevezhető rendszernek és rengeteg sebből fog vérezni. Az esettanulmányban kitérek nem csak a programozást érintő kérdésekre, hanem arra is, hogy milyen következményei lehetnek egy átgondolatlanul, és hanyagul megírt webshopnak. Valamint milyen plusz hibalehetőséget jelenthet az, hogy webes alkalmazást fejlesztünk, nem natív kódot. Az esettanulmányban webshopra fogok hivatkozni, de a hibák többsége nem csak webshopra, hanem bármilyen webes alkalmazásra igaz lehet. Az általam említett hibákat több opensource fejlesztésű webshopban megtaláltam, idővel ezeket javították, de általában pár hétig sebezhetőek voltak. Valamint ki fogok térni olyan kérdésekre, amelyek azt biztosítják, hogy az oldalunkat ne törjék fel az első pár napban.
2. Tipikus webshop hibák forrásai Amikor webshop készítést vállalunk fordítsunk sok időt tervezésre. A web miatt nem kerülhetjük el, hogy MCV (Model Controller View) szemléletben fejlesszünk. Ha ezeket elmulasztjuk, vagy spórolunk rajta, akkor az így létező hibákat közvetlenül mi okozzuk, ez később kamatostul megbosszulja magát. Egy webshop akkor webshop, ha weben elérhető. Találkoztam több diákkal, akik diploma munkának webshopot készítettek. Első kérdésünk az volt, hogy Hol lehet megnézni?. A válasz az esetek 90%-ában az volt, hogy otthon van Apache meg MySQL ott fut, máshol meg nem. Nos, ami nem elérhető az interneten az nem webshop. Amennyiben az előzetes felmérés szerint a webshopnak nem lesz nagy látogatottsága akkor shared hosting, tárhelyen elhelyezhetjük. Az, hogy mi a nagy látogatottság az az általunk megírt kódtól, és a tárhely szolgáltatótól függ, célszerű ennek előre utána járni, milyen korlátjai vannak a tárhelynek pl.:havi adat forgalom, CPU limit. A saját szervert nem ajánlom olyanok számára, akik nem ismerik a szerver beállítás minden lépését. Ha a szerver beállítást elrontjuk, akkor rosszakarók nélkül is problémáink lehetnek a webshoppal. Üzleti szempontból, ha áll a webshop az kiesés, hiszen nem rendelnek rajta keresztül. Nem kifejezetten technikai hiba, ha a webshopban a rendelés menete túl bonyolult, vagy túl sok lépésből áll, vagy a látogató számára nem egyértelmű, hogy hogyan kell rendelni. Találkoztam, olyan webshoppal, ahol amíg a látogató nem regisztrált nem tehetett a kosarába semmit. Regisztrációnál, nem kell feltétlenül ragaszkodni ahhoz, hogy kiküldjünk egy aktivációs emailt, amiben egy linkre kell kattintani. Ha olyan helyen van a levelezése, ahova lassan érkezik meg a levél (vagy netán a mi szerverünk túlterhelt) akkor, lehet, hogy elmegy a kedve a vásárlástól.
3. Tipikus hibák ismertetése Itt az általam leggyakrabban webfejlesztésre használt nyelvből a PHP-ból mutatok be kódokat. Ezek egy része csak a PHP-t érinti, és más nyelvekben ezen hibák egy részét nem lehet elkövetni. A legtöbben azonban mai napig PHP-t használnak webes fejlesztésre. 3.1. connection.inc Néhány szakkönyv is azt ajánlja, hogy így nevezzük el azt a kódot ami adatbázishoz csatlakozik. A probléma az, hogy nem írja oda, hogy csak akkor nevezzük el így, ha a szerver a php kiterjesztésű filekon kívül az inc kiterjesztésű filekat is lefuttatja, különben ha valaki pár próbából beírja a domain nevünk után, hogy /connection.inc akkor találkozni fog az adatbázis felhasználói nevével, és jelszavával, mivel a kód nem fut le, hanem a forrás kilistázódik. 3.2. Tervezési hiba Ide sorolok minen olyan hibát, amit megfelelő tervezéssel és átgondolással el lehet kerülni. Sokan nem fordítanak figyelmet arra, hogy MCV koncepció szerint építsék fel a webshopot. Ekkor fordulhat elő az, hogy a termék árát, vagy a kosár összegét, nem minden esetben adatbázisból töltik be, hanem hidden mezőben adogatja tovább, ez könnyedén átírható. Gondoljuk végig, ha egy drága terméket ilyen hiba miatt valaki fillérekért vesz meg, akkor az üzlet kire fogja terhelni a különbözetet? Ha valaki feladta a rendelést akkor azt ki kell szállítani különben a vevő panaszt tehet a fogyasztó védelemnél és megbüntetik a webshop üzemeltetőjét.
Erre tipikus példa ha ehhez hasonlóan néz ki a kosárgomb: <form action="kosar.php" method="post" > <input type="hidden" value="526" name="id"/> <input type="hidden" value="573000" name="ar"/> <input type= submit value= kosárba > </form> Ebbe a részbe sorolom a weboldalak általános hibáit is, mint amilyen az SQL injection. Ez a hiba arról szól, hogy egy megírt SQL parancsba egyszerűen beillesztjük a felhasználótól kapott adatokat, ami rossz indulatú felhasználás esetén további SQL parancsokat tartalmazhat, amit nem biztos, hogy szerencsés végrehajtani. Vagy annyira megmódosítják az SQL-t, hogy az nem azt csinálja, amit mi szeretnénk. Erre a példa a következő: $sql= SELECT id FROM user WHERE username=\.$_post[ user ]. \ AND password=\. $_POST[ password ]. ;... Itt ha jó adatokat kaptunk meg akkor kikeresi azt, ahol a felhasználói név és a jelszó egyezik a felhasználó által megadottakkal. Ha azonban user mezőben azt kapjuk, hogy or 1=1 -- akkor ez lesz a teljes lekérdezés: SELECT id FROM user WHERE username= or 1=1 -- ez esetben kiválasztja az adatbázisból a legelső felhasználót, és azt fogja beléptetni, és mivel ez általában a fejlesztő fiókja, így elég kellemetlen meglepetésben lehet részünk. (A -- a comment kezdete MySQL-ben utána bármi van azt már nem értelmezi) A saját oldalunkról beérkező adatokat is először szűrjük, hogy helyes-e mielőtt feldolgozzuk. Lehet, hogy olyan azonosítóra hivatkozik, ami nem létezik, ez hibához vezethet és ez alapján lehet, hogy feltörik az oldalunkat.
Valamint még egy tipikus hiba, hogy nem fordítanak elég figyelmet ténylegesen a vásárló által bevitt értékek helyességére. Erre azt a példát tudom, említeni, hogy -1 et vagy 0,5 darabot lehet rendelni egy termékből. pl.: Tv készülék esetén ennek nem sok értelme van. De ha a felhasználó sok mindent rendel és valamiből negatív értéket, amit a webshop levon az összes árból akkor lehet, hogy végül olcsóbban kapja meg mint amennyiért kéne. Nem biztos, hogy a rendelést feldolgozó személy a negatív előjelű tételt nem küldi el. 3.3. Vásárlási folyamat Találkoztam, olyan webshoppal, ami úgy működött, hogy a belépés eseménynél törölte a kosarat. Ez nagyon zavaró volt, hiszen a többség megnézi a webshopot, összeállítja a kosarát, majd bejelentkezik és megrendelné. Ha azonban ilyenkor úrjra össze kell állítania a kosár tartalmát lehet, hogy elmegy a kedve a vásárlástól. Másik ilyen példa, hogy sok adatot kérünk be, kötelező jelleggel, és a felhasználó megunja kitöltögetni. Erre egy tipikus példa, mikor egy webshop nem fogadja el a rendelést amíg két telefonszámot meg nem adunk. Ezen kívül fontos az, hogy ha a látogató már eljött az oldalunkra, és eldöntötte, hogy vásárol, akkor azt minél hamarabb meg tudja tenni. Ha már feladta a rendelést akkor valószínűleg át fogja venni a terméket. A fals rendelések száma általában nagyon alacsony. Itt fontos, hogy a felhasználónak ne kelljen regisztráció után arra várnia, hogy az e-mail címére megérkezzen egy levél, amivel aktiválhatja a fiókját. Hanem, ha regisztrál azonnal léptessük be, és folytathassa a vásárlást. Ha később kiderül, hogy elgépelte az e-mail címét azt később tudjuk javítani, hiszen minden bizonnyal több elérhetőséget is adott meg.
3.4. Kereső Ezt a témakört azért emelem ki, mert a rengeteg webshop hibás keresővel rendelkezik. Ez megnehezíti a vásárló számára, hogy meg találja a terméket, amit meg akar vásárolni. A jó keresővel ha csak egy szó töredékre keresünk, akkor is meg kell, hogy találjuk a terméket. 3.5. Megfelelő szervert válasszunk Ha shared hosting megoldáson indítjuk az oldalunkat akkor járjunk utána minden korlátozásnak, ismertetem azokat, amik miatt a legtöbbet állhat a webshop: Forgalom korlát: Ez azt jelenti, hogy ha valaki az oldalunkról letölt vagy oda feltölt azt számolják és ha elér egy szintet, akkor leállítják az oldalt. Ezen spórolhatunk, ha kisméretű képeket teszünk fel az oldalra. A tapasztalat szerint a termékek többségénél nem adja el jobban az, hogyha poszter méretű kép van feltöltve a termékről. CPU korlát: Ezt a korlátozást úgy valósítják meg, hogy mérik, hogy adott időegység alatt mennyit használtunk el a processzor idejéből és ha ez elér egy szintet, akkor leállítják az oldalt. Ez azért kellemetlen, mert ez pont a csúcsidőben fog leálláshoz vezetni. Ezen javíthatunk ha optimalizáljuk a kódunkat, hogy gyorsabban fusson le. Fájl darab szám korlátozás: Erre csak akkor kell oda figyelni, ha nagy webshopot üzemeltetünk. Egy 30000 terméket tartalmazó webshopot feltételezve, a fájlok száma kis képekkel könnyen elérheti a 60000 ezer darabot, és ez néhány szolgáltatónál problémát okozhat. SQL csatlakozás korlátozása: Többször találkoztam olyan oldallal, amely kiírta, hogy túl sok kapcsolat, nem lehet csatlakozni az adatbázishoz. Ez szintén kellemetlen korlátozás, mert ez is akkor fog előjönni, amikor sokan látogatják az oldalt. Ezt úgy akadályozhatjuk meg a legkönnyebben, hogy egy futás során nem tartunk fenn több MySQL kapcsolatot, hanem egy kapcsolaton keresztül intézünk minden lekérést. Részben a szerverhez tartozik, de a programozás is befolyásolja, hogy az oldal gyorsan betöltsön. Ha egy lapra 1-2 másodpercet kell várni az még nem probléma, de ha amikor a többen látogatják, akkor 10-12 másodpercet kell várni akkor sokaknak elmegy a kedve a vásárlástól.
3.6. Adminisztrációs felület Találkoztam jó pár olyan webshoppal, ahol /admin könyvtárban volt az adminisztrációs felület. Ez még önmagában nem okoz problémát, de ha mindezek utána olyan egyszerű felhasználóinevet és jelszót adunk meg, hogy admin és admin vagy admin és 12345, akkor számíthatunk arra, hogy az első rosszindulatú látogató ezeket ki fogja próbálni, és ha megtalálta, akkor vissza fog élni vele. Mindenképpen adjunk az adminisztrációs felületünknek valami egyedi nevet, ha lehet al domaint. pl.: enwebshopadminom.domain.hu Néhány oldalon találkoztam olyan megoldással, hogy az oldal főmenüjében volt egy adminisztráció feliratú gomb, ami azonnal az adminisztrációs felületre vitt, ezt nem javaslom mert tálcán kínálja, hogy a rosszindulatú látogatók próbálkozzanak vele. Valamint az adminisztrációs jelszó is legyen kellően bonyolult. 3.7. Adatok tárolása Csak egyetlen olyan megoldással találkoztam, ahol az admin felületi felhasználókat adatait nem adatbázisban tárolták, hanem XML fájlok segítségével. Mindezt ráadásul egy /admin könyvtárban, úgyhogy bárki elérhette. Annyira elővigyázatosak voltak, hogy a jelszó helyett csak annak md5 kivonatát tárolták. Viszont annyira nem, hogy a jelszó bonyolult és hosszú legyen. Így perceken belül vissza lehetett fejteni. Itt mindenre gondoljunk, hogy mit lehet elérni a webshopból, ami érzékeny információ lehet, ilyenek lehetnek: Rendelés kimenetek: Nem biztos, hogy a vásárlók örülnének, ha kiderülne, hogy mikor mit rendeltek milyen címre. Néhány olyan megoldásnál, ahol a webshop egy külső vállalat irányítási rendszerhez csatlakozik, találkoztam olyan megoldással, hogy egy rendelések mappába txt-be gyűjtötte a webshop a rendeléseket.
Statisztikák: A webshop tulajdonos biztosan nem örülne, ha a konkurencia rájönne, hogy mennyi a havi forgalma a webshopon keresztül. Szintén találkoztam olyan megoldással, amikor ez egyértelműen kiszámítható volt, mert a webshop egy txt fájlban gyűjtötte, hogy mikor mekkora rendelés érkezett. Log fájlok: Ez egy tipikus probléma, amikor /log vagy hasonló könyvtárban olvashatóak a webshop hibaüzenetei, ezzel nagyon megkönnyítjük bárkinek a dolgát, hiszen nem kell neki hibát produkálni az oldalon, csak átolvassa, hogy mik voltak már. Ha elég részletes a hiba naplózás akkor ez nagyon megkönnyíti a rosszindulatú látogató dolgát.
4. Követendő irányelvek Törekedjünk arra, hogy a webshopunk megfeleljen az alábbi követelményeknek: Hiba kezelés: Akármilyen bemenetet kap a felhasználóval a hibát mi kezeljük és ne a PHP vagy a MySQL hibaüzenetet jelenítsük meg. Adat és felület elrejtés: Csak olyan felületet lásson a felhasználó, amit látnia kell. És csak olyan adatokat, amihez hozzá kell férnie. Érvényesség: minden adatot vizsgáljunk meg mielőtt lementjük, nehogy érvénytelen adat kerüljön az adatbázisba. Mindent persze nem lehet ellenőrizni, de amit lehet az ellenőrizzük. Kapcsolatok: Mindenképpen rendszert írjunk és figyeljünk arra, hogy ne maradhassanak olyan objektumok, amiknek a kapcsolatai már kitörölt objektumokra hivatkoznak. Teszteljünk: Ültessünk le egy informatikában nem jártas embert a webshophoz és adassunk fel vele egy rendelést, meglepően sok hasznos tanácsot szerezhetünk ilyen módon. Biztonság: Fordítsunk figyelmet arra, hogy minden jelszó hosszú és megfelelően bonyolult legyen. Ha ezeket az irányelveket betartjuk nem valószínű, hogy komoly hiba lesz az általunk készített webshopban. Ahogy egyre több látogató látogatja az oldalt, előbb utóbb egyre többen próbálják meg majd feltörni. Elég hamar valószínűleg spam botok is meg fognak jelenni, amik megpróbálnak beregisztrálni, vagy csak e-mail címeket próbálnak megszerezni. Egy olyan oldal, ahol a termék vélemények rovat botok által tele van szemetelve, azt a benyomást kelti, hogy webshoppal nem foglalkoznak. Ezt a benyomást mindenképpen el kell kerülni. Az ellen, hogy be regisztráljanak, vagy automatizáltan hozzászólásokat helyezzenek el az oldalon védekezhetünk. Ennek legegyszerűbb módszere a CAPTCHA. Nem feltétlenül célszerű saját CAPTCHA motort írni több jól bevált modul létezik, amik könnyen integrálhatóak bármilyen oldalba. A saját magunk által fejlesztett lehet, hogy könnyen törhető lesz, vagy nem fogja tudni mindenki megfejteni.