SQL injectálás elleni védelem?
Tudom, hogy ez mire jó, mit tud károsítani stb...
Készítettem egy weboldalt, ami nagyon összetett (RENGETEG php van benne, mivel iszonyatosan sok adatbázis lekérdezést használ).
Mindenhol, ahol csak kellett (ahol észrevettem) használtam 2 dolgot ellene:
1. valami2 = mysql_real_escape_string($valami1)
2. if (preg_match("/^[a-zA-Z0-9]*$/i", $valami2))
Első kérdésem: Ezeken kívül még lehet valamivel védekezni ellene? (Egyáltalán kell-e?)
Második kérdésem: Van-e olyan free program, ami át tudja nekem nézni az összes weboldal részt, és ha talál benne "biztonsági rést", akkor kiírja, hogy "be tudjam foltozni"?
Azért kell a program hozzá, mert közel 120 php fileból áll, aminek a darabja legalább 20-30kb-s. Így rengeteg időbe telne átnéznem egyesével, pontról pontra.
Mit értesz tervezési hiba alatt?
Igyekeztem úgy megoldani mindent, hogy a lehető legkevesebb lehetőség maradjon a támadásra. Ahol felhasználó által küldött érték van, az többnyire általam megadott érték közül van kiválasztva.
Tehát egy PÉLDA: Hány éves vagy?, akkor itt nem beírja, hogy 11, hanem legördíti és kiválasztja, majd ennek az értéke 11, ezután: vannak a feltételek, pl:
if($_post['kor']= '11'){
$kor = 11;
}elseif...stb
és a mysql parancsban pedig a $kor kerül, amit nem tud ő saját maga megadni, hanem az általam megadott értékek közül lesz egy, ami az elküldött érték tartalmának felel meg.
Ez csak egy példa még egyszer kihangsúlyoznám. Ilyenek miatt lehet nagy méretű egy-egy php file, mivel include/require parancsokkal rakom be egy-egy főbb oldalba a megfelelőket, hogy könnyebben átlátható és persze ne végtelenségig tartó legyen.
Nem iskolában, vagy tanfolyamokon tanultam meg a php-t, hanem önerőből interneten, olvasgatva, így nem zárom ki a "tervezési hibát" sem. Viszont sokat segítenél, ha elmondanád, hogy mit értesz ez alatt. Az oldal közel 80%-a teljesen kész, tesztelve, hibátlanul működik. Egyetlen félelmet a támadás jelenti, ezért igyekszem mindennek utána járni éles indítás előtt.
válasza:Az a baj, hogy sok hiba lehet, amit te nem is tartasz annak, vagy nem tekintesz veszélyesnek.
Érdemes lenne inkább valamilyen keretrendszerre építeni, azt egyrészt sokkal hozzáértőbbek fejlesztik, másrészt a saját kódodat is jobban karban tudod tartani.
Pl.: CodeIgniter
Így pár mondatban erről nem tudok írni neked most többet, hogy hol és mi lehet a hiba, de azt meg tudom mondani, hogy ha egy weboldalnál 100+ fájl van, ott valami tuti el van rontva.
válasza:Alapvetően valóban igaz, hogy a túl sok file nem szerencsés. Ugyanis ez azt jelenti, hogy nincs megfelelően optimalizálva a kód, és ez túl sok hibalehetőséget jelent. A túl sok és sokféle lekérdezés lassíthatja az oldal, az adatbázis szerver leterhelése előbb-utóbb hibákhoz vezethet.
Mint írtad ez amolyan közösségi oldal is, ami nagy látogatottságot jelent, és minél többen böngészik az oldalt annál több az egyidejű lekérdezés, ez pedig nem elsősorban a sávszélességet, hanem a szerver processzorainak sebességét teszi próbára. Ezért aztán érdemes a lekérdezéseket és a műveleteket egyszerűsíteni/összevonni vagyis optimalizálni.
Pl.: - a kor letárolásánál ne használj feltételes szerkezeteket, alakítsd automatikusan megfelelő formátumra a beérkező adatot.
- Az űrlapok ellenőrzését ahol lehet bízd javascriptre, ezzel leveszed a webszerver válláról a fölösleges oldalhívások terhét.
- egységesítsd a gyakori műveleteket, ne kelljen minden fájlban újra és újra megírni ugyanazt a lekérdezést ha csak pár paraméterben térnek el egymástól
- ha lehet használj valamilyen adatbázis-class-t, amivel egyszerűsítheted a lekérdezéseket
- bár én nem támogatom a php keretrendszereket (igyekszem a sajátomat csiszolni), ez esetben lehet hogy érdemes lenne megismerkedned eggyel, ami könnyebbé teszi egy ilyen nagy projekt használatát/működtetését.
Egyébként szerintem jó úton haladsz, mert a legjobb mindent a magad módján kiismerni, megérteni, és megtanulni. Csak így tovább, fejlődj tovább, és sok sikert!
válasza:Egy apró kiegészítés ezekhez, ami félre vezető lehet:
"- Az űrlapok ellenőrzését ahol lehet bízd javascriptre, ezzel leveszed a webszerver válláról a fölösleges oldalhívások terhét."
De ez nem azt jelenti, hogy szerver oldalon nem kell ugyan azt az ellenőrzést elvégezni!
Ugye a js miatt az alapvetően hibás adatok nem kerülnek elküldésre, ami jó a szervernek, de védelmi szempontból elkerülhetetlen a szerver oldali ellenőrzés.
válasza:Tervezés:
Oké fő a biztonság:
De nem csak sql injekció van a világon:
xss injekció, azzal is bele tud nyúlni az adatbázisba, bár nem közvetlenül.
Ennyi fájl nagyon leterheli a szervert, főleg ha sok játékosod lesz.
Próbáld meg kliens oldalon is figyelni az injekciókat.
Próbáld meg csökkenteni a redirecting-ek számát.
Ezt pedig tervezéssel tudod csökkenteni.
válasza:if($_post['kor']= '11'){
$kor = 11;
}elseif...stb
juj........... ez nagyon csunyan hangzik...
válasza: válasza: válasza:mivel include/require parancsokkal rakom be egy-egy főbb oldalba
nem tudom, hogy spl_autoloadrol hallottal-e mar? remelem azert legalabb objektumorientalt :)
válasza:Tehát egy PÉLDA: Hány éves vagy?, akkor itt nem beírja, hogy 11, hanem legördíti és kiválasztja,
nincs az a bongeszo, amelynek nincs olyan extensionje, hogy atirhatod vele a form adatait. bar legalabb php oldalon is ellenorzod
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!