Hogy lehet a legbiztonságosabban elvégezni egy belépést? Php

Kell egy users tábla amibe tárolod a felhasználó adatait.

(ID,user,pass,név,mail,tel,...)

Kell egy login tábla amibe a belépések adatati tárolod.

(ID,UserID,PHPSESSID,IP,Date,status[1/0])

Bejelentkezés kor megadja a felhasználónevét, jelszavát, ezt elküldi egy login funkciónak.

Funkció ellenörzi, hogy az adott IP -vel az elmúlt 15 percben volt -e, 3 hibás kísérlet (status=0).

Ha nem akkor tovább megy a felhasználónév, és jelszó páros ellenőrzésére. (természetesen a POST adatokból, előtte kiszűri speciális karaktereket)

Ha sikeres a hitelesítés akkor login táblába bejegyzi IP, PHPSESSID -t status=1 paraméterrel, dátum=now();

Ha hibás akkor szintén bejegyzést ír, csak most status=0.

Minden oldal betöltésnél lefuttatsz egy funkciót ami megnézi hogy az adott PHPSESSID -vel és IP -címmel van -e 20 percnél nem régebbi bejegyzés.

Ha igen, frissíti ennek a bejegyzésnek a date paraméterét now() -ra, majd kiolvassa az users adatokat UserID alapján, és egy globális változóba tárolja. pl. $_ENV['USER'] = Array(ID,user,pass,név,mail,tel,...);

Ha nincs akkor ezt a globális tömbött üresre állítod. $_ENV['USER'] = NULL;

Később a PHP folyamatokban a felhasználónak pl. a belépési státuszát, nevét, mailcímét... $_ENV['USER'] -ből tudod kiolvasni.

Bőven elég a beépített session kezelés, nem kell feltétlenül adatbázist használni erre. (Sok esetben csak pazarlás is minden oldalon lekérni a session adatokat.)

Egy valamit fontos szem előtt tartani inkább:

MINDEN input adatot szűrni kell a szerver oldalon is.

Sehol nem használsz pl. ilyen SQL lekérést:

mysql_query("select * from table where id = $id ");

Mert ha a $id -nek nem egy számot adunk meg, hanem SQL utasítások, akkor azt csinálunk az adatbázissal és úgy manipuláljuk ahogy kedvünk van.

Soha nem hajtunk végre közvetlen eval() funkciót GET/POST paraméterrel!

Fájlfeltöltésnél nem elég csak kiterjesztést vagy mime típust nézni!

A fájl tartalmát is meg kell vizsgálni!

Soha nem includulunk GET paraméterben megadott oldalt, csak az előre definiáltakból!

?oldal=valami => include($_GET['oldal'].'.php'); SOHA!!!

sok helyen láttam hogy oldal/page GET paramétert ellenőrizetlenül betölti.

pl. van egy hirek menüpotn ?page=hirek amihez tarzhat adminisztrációs felület, /admin mappán belül, így sokszor ellehet érni adminisztrációs lapokat: ?page=admin/hirek

De nem csak adminisztrációsat, ha a szervert is egy kezdő állította be akkor külső URL -ről is lehet includolni!

pl: ?page= [link]

Ezzel beinculdohatja a [link] .php -t.

Sokszor almappába van az includolt fájlok.

/pages/valami.php << file

?page=valami << URL

include('pages/'.$_GET['valami'].'.php'); << php

Ekkod is ugyan úgy sebezhető, mert a szerveren bármely php -t be tudja includolni még a /admin -on belülit is.

?page=../admin/valami

Tehát, mindig, minden adatot ellenőrizni kell!

Soha nem elég kliens oldalon pl. JS -el, szerver oldalon is elengedhetetlen!

Kényes biztonsági adatokat nem adunk át kliensoldalnak!

(láttam már olyat ahol külső oldalra egy 0px -es iframe -be elküldték a szerver root jelszavát is, hogy a módosításokat a játékszerveren megcsinálja)

"csak egy elmeleti kerdes: ha adatbazisban tarolod a session id-t, hogyan akadalyozod meg, hogy ellopjak a session id-t tarolo cookiet?"

Erre van egy ötletem amivel ezt meg lehet valósítani:

-a cookie titkosítottan tartalmazza

*az ip címet

*javascritből legyen lekérdezve: appcodename, appname, appversion,platform, useragent.esetleg ezek mellett a felbontás is, esetleg firefox esetén windows.navigator.connection osztály alkalmazásával lehetne azonosítani, hogy az illető milyen internet kapcsolatot használ

A cookie tartalmazhatja a username+password-ot, plusz ezeket a paramétereket de titkosítottan. Ezen kívül a cookie elküldése sha-256-al való hitelesítéssel legyen.

Így amikor lelopja a cookie-t:

- a cookie-ból az ip cím kicsomagolásával és a $_SERVER['REMOTE_ADDR'] összehasonlításából kiderülhet, hogy más gépről küldték el.

-ez még nem véd a belső hálóból történő cookie lopás ellen

-de a böngésző összes adatának kicsomagolása és a támadó adatainak lekérdezének összehasonlítása már mást tészta.

( kicsi az esély, hogy a támadó pont ezeket az adatokkal rendelkező böngészőt használja, illetve a hálózati kapcsolat típusának azonosságára is kicsi az esély.

Persze ez még nem 100%-os védelem, de az esetek 99%-ban tuti megvédené a jelszót. (de legjobb valóban az, hogy a cookie ne tartalmazzon ilyen adatot)

Persze az én megoldásom "tökéletesre" való fejlesztése is érdekes, itt még egy java applet is kell, amivel a belső ip-t meg lehet határozni:

if (java && java.net)

ip = ''+java.net.InetAddress.getLocalHost().getHostAddress();

else ip = 'unknown';

Ha a cookie ezt is tartalmazza, akkor viszont már nem tudja lelopni:)

Rossz!

Mi garantálja, hogy nem tudja módosítani a dolgokat?

A session ID-t le KELL tárolni sütiben és pont. Másképpen nem lehet azonosítani senkit.

A szerver oldalon pedig a hozzá tartozó adatokat lehet adatbázisban vagy a php alap SESSION tömbjében (ami fájllal dolgozik) tárolni.

User oldalon egy szám elég.

A SZERVER oldalon lehet mellé tárolni egy IP címet (sőt ajánlott), sőt tovább megyek még egy böngésző azonosító sem árt.

Így ha valaki el is lopja a sütit, annak a valószínűsége, hogy használni is tudja nagyon csekély, minimum egy LAN-ra kell kerülniük ÉS még minden böngésző adatot spoofolni kell. (Ez utóbbi annyira nem nehéz, de talán egy-két kiléptetésig eltart míg valaki rájön, hogy ezt is ellenőrzi a rendszer.)

Sajnos mivel LAN-on a legkönnyebb a sütiket lenyúlni, amikor utaznak a hálózaton ez is leginkább azt garantálja, hogy pillanatnyilag tudja csak a támadó felhasználni maximum az adott munkamenetet.

Ezek a bevett szokások, de 100%-os megoldás nem létezik.

Illetve de, ha a session-ös dologra egy HTTPS-el is rásegítesz, így szinte lehetetlenné téve a session ID lopást.