Mennyire biztonságos ez a munkamenet kezelés?
Sziasztok, a 'Php-ban saját függvény írása, meghívása' topic is hasonló témát feszeget, de talán külön jobb helye lesz... Szóval próbálnám kitalálni, hogy miként kezeljem egy többfelhasználós rendszerben a munkameneteket és az alábbi ELVI módra gondoltam.
A lényege, hogy belépés után minden egyes user kapna egy kulcsot $_SESSION["user"]["key"] aminek értékét folyamatosan, minden oldalbetöltésnél vizsgálnám és újradefiniálnám, a $_SESSION["user"]["logged"] és a $_SESSION["user"]["id"] megléte mellett.
A belépés során a user rekordjának ellenőrzése a minta kedvéért egy egyszerű feltétellel ellenőrződik (test##kukac##test.hu / test) illetve a $_SESSION["user"]["key"] most szándékosan csak egy fájlba íródik és nem adatbazásba.
Nagyon megköszönném ha véleményeznétek a kódot és segítenétek jóbbá tenni...
■ A lényege, hogy belépés után minden egyes user kapna egy kulcsot $_SESSION["user"]["key"] aminek értékét folyamatosan, minden oldalbetöltésnél vizsgálnám és újradefiniálnám, a $_SESSION["user"]["logged"] és a $_SESSION["user"]["id"] megléte mellett.
A belépés során a user rekordjának ellenőrzése a minta kedvéért egy egyszerű feltétellel ellenőrződik (test##kukac##test.hu / test) illetve a $_SESSION["user"]["key"] most szándékosan csak egy fájlba íródik és nem adatbazásba.
Nagyon megköszönném ha véleményeznétek a kódot és segítenétek jóbbá tenni...
<?php
session_start();
ob_start();
if(isset($_GET["logout"])){
session_destroy();
session_regenerate_id(true);
header("Location: ./login.php");
die();
}
if($_SESSION["user"]["logged"] && is_numeric($_SESSION["user"]["id"])){
$id = $_SESSION["user"]["id"];
$sid = file_get_contents($id);
if($sid == $_SESSION["user"]["key"]){
echo "<p><a href='?logout'>logout</a></p>";
echo "<p><a href='/login.php'>refresh</a></p>";
session_destroy();
session_start();
session_regenerate_id(true);
$_SESSION["user"]["logged"] = true;
$_SESSION["user"]["id"] = $id;
$_SESSION["user"]["key"] = md5($_SESSION["user"]["id"].$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"].microtime());
file_put_contents($_SESSION["user"]["id"], $_SESSION["user"]["key"]);
}
else header("Location: ./login.php?logout");
}
else{
if(isset($_POST["login"]) && $_POST["login"] == $_SESSION["login"] && filter_var($_POST["liam"], FILTER_VALIDATE_EMAIL) && !empty($_POST["pass"])){
if($_POST["liam"] == "test##kukac##test.hu" && $_POST["pass"] == "test"){
session_regenerate_id(true);
$_SESSION["user"]["id"] = 1;
$_SESSION["user"]["logged"] = true;
$_SESSION["user"]["key"] = md5($_SESSION["user"]["id"].$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"].microtime());
file_put_contents($_SESSION["user"]["id"], $_SESSION["user"]["key"]);
header("Location: ./login.php");
}
}
session_regenerate_id(true);
$_SESSION["login"] = md5(rand(1,10000000));
echo "
<form method='post'>
E-mail: <input type='text' name='liam'>
Password: <input type='text' name='pass'>
<input type='submit'>
<input type='hidden' name='login' value='{$_SESSION["login"]}'>
</form>";
}
ob_end_flush();
?>
nagyon
Név
session_name('egyedi_nev');függvénnyel asession_start();előtt, hogy ha ugyanazon domain-en van a website és az adminisztrációs felület (de mondjuk másik könyvtárban), és nincs jól beállítva a cookie, akkor se keveredjenek össze a változók.Törlöd?
Végre gép előtt... köszönöm a
A session_name-t, jó hogy említeted, mert igen, ua-on a domainen vannak, köszönöm!
Poetro: Arra gondoltam, hogy ha mindig törlöm, újragenerálom a session-t és ellenörzőm azt akkor nehezebb ellopni... de ezért kértem ki a véleményeteket, hogy ha ez így nem jó, akkor mi tanácsoltok/tanácsolsz.
Azt szeretném hogy biztonságos legyen. De ha rossz úton járok, vagy Ti máshogy csináljátok akkor kérem osszátok meg velem.
Nem kell minden kérésnél új
Köszönöm a hozzászólásod...
A formoknál az egyedi kulcsot használom, ez tényleg nagyon fontos.
Egyébként, ha az összes $_GET, $_POST, $_SESSION változóra globálisan alkalmazom a strip_tags-et és utána a mysql_real_escape_string-et - csak sima szöveget kell mentenem - akkor kell-e tartanom sql injection-től?
PDO-t használj adatbázis
2 észrevételem van: - a
- a "key"-t a felhasználó IP-je alapján generálod, ez nagy általánosságban jó eredményt ad, de vannak olyan extrém esetek, amikor a user 2 vagy több IP címről látogatja az oldaladat, ilyen eset lehet pl. ha több internet kapcsolattal rendelkezik és terhelés megosztás van beállítva a routeren.
- minden oldal újratöltéskor újra generálod a session id-t, ez felesleges
Használj egy framework-öt, ott a felhasználó kezelés (és sok más egyéb) meg van oldva.
1. igen, erre nagy esély van,
2. megmondom őszintén, hogy a 'session fixation' ellen védekeznék. persze az angol leírások szerint akkor generáld újra a session-t, ha "user's privilege level changes". Tehát akkor tényleg feleslegesnek látszik.
3. tudom, framework-kel jobban járnék, csak próbálgatok, tanulgatok...
Kicsit jobban meg néztem a
Lehet, hogy elbeszélünk
Nekem az elképzelésem az volt, hogy belépés után minden oldal betöltéskor újragenerálódjanak az adatok, amit az alabbi kódrészlet végez:
Vagy szerinted nem jól gondolom?
Válaszd szét a dolgokat
Ezzel egyenértékű a
Egyébként ezt használja a session id előállítására a PHP, tehát ezzel nem növeled a biztonságot, csak bonyolítod az életed.
Első körben én azt javaslom, hogy logikailag válaszd szét azt a pár dolgot amit most összekeversz:
Munkamenet kezelés
Két kérdéssel kell foglalkoznod itt:
Hol és hogyan tárolod a munkamenet adatait?
A PHP alapértelmezetten a /tmp könyvtárban tárolja, ami osztott rendszeren nem túl szerencsés, ezért nem javasolják, hogy érzékeny adatokat tárolj benne. Ezt egyébként könnyedén tudod orvosolni, csak meg kell változtatnod ezt az alapbeállítást. Persze a teljes adattárolás felett átveheted az uralmat.
Hogyan követed a munkamenetet?
Itt gondolkodhatsz a PHP beépített megoldásának lecserélésén, de én nem javasolnám.
Felhasználó kezelés
Itt kezeled, hogy a felhasználó kilép, belép, létrejön, módosul, törölődik, sikertelenül próbálkozik, jelszót igényel stb.
Hozzáférés szabályozás
Itt kezeled, hogy ki milyen funkcióhoz, adathoz fér hozzá.
Űrlap kezelés
Ezt azért érdemes leválasztanod, mert lehetséges, hogy programozottan akarsz belépni, kilépni, esetleg írsz valami API felületet, vagy Mobilra váltasz, vagy nem tudjuk mért, de akkor problémát fog jelenteni, hogy ezt ennyire összehuzaloztad.
PP, nagyon hálás vagyok az
u.i.: nagyon jó lenne, ha sok hasonló válasz érkezne az egyéb itt feltett kérdésekre
Mahoo a te kódodban, a
A te kódod logikája:
- kiolvasom a "key"-t userid alapján
- ha a key egyenlő a sessionben tároltal
- session-t törlöm
- újra generálom a kulcsot
- mentem a kulcsot fájlba, session-be
- ha nem egyenlő , kiléptetem
- ha nincs belépve
- ha név/jelszó, token megfelelő
- user loggedIn
- legenerálom a kulcsot
- mentem a kulcsot fájlba, sessin-be
A probléma ott van, hogy kulcs amit elmentesz a szerveren, a szerveren sessin-be mentett kulcsal veted össze, ez a két érték mindig ugyanaz lesz.
Szerintem a következő logikát építsd fel:
- user állandó (fix) adatai alapján generálok egy kulcsot (legyen függvény!),
erre kb csak a user_agent alkalmas, gondolom ez már nem változhat
két lekérés között, megkötésekkel az ip
(változhat, Thor hálózat pl.)
- ha a key egyenlő a sessionben tároltal
- nem teszek semmit futhat az oldal
- ha nem egyenlő , kiléptetem, hibaüzenet
- ha nincs belépve
- ha név/jelszó, token megfelelő
- user loggedIn
- legenerálom a kulcsot, session-be beállítom
A kulcsot nem kell fájlba, db-be menteni, csak szession-be.
Tanulási célból dícséretes, hogy ezzel próbálkozol, de ha már sikerült meg ismerkedned az alapokkal, symfony vagy zend fw-öt ajánlom, doctrine orm-el.
A fw, nem fw-be nem mászok bele, döntse el mindenki magának, aztán majd talál magának munkahelyet, vagy nem.
Kubi, csak ismételni tudnám
Nagyon köszönöm a segítséget, még jó hogy valaki figyel és próbál segíteni!
Ez nem biztos
A magam részéről inkább a saját Júzerkezelés híve vagyok, ekkor is csak egyszer fejleszted ki a rendszert és sokszor hasznosítod, ámde van egy nagy előnyöd a "gyáriakkal" szemben: csak te ismered...
Persze nem kötelező mindenkinek így gondolkodni, de manapság érdemes a biztonsági dolgokat teljes rálátással kezelni.
Pepita, véleményed szerint mi
És nagy "előnye", hogy egy
Egy dolog, hogy én is magamnak írnék login rendszert, de ezt csak addig a pontig használnám, amíg saját oldalt készítek. Megbízónak nem adnék oda olyan rendszert, amiről még kevésbé tudom, hány sec.hole van benne, mint amennyire egy már bejáratott fw-ről lehet tudni.
Az oldal amit próbálok
Egyébként ismeri valaki ezt a FW-ot? Válemény esetleg: link
Ez ugye csak vicc volt?
Jaja, a nyilvános kulcsú titkosítás, elméletét, algoritmusát mindenki ismeri, ezért senki sem bízik meg benne. Ugyan úgy, ahogyan az ssh, vagy https protokollok is használhatatlanok, hisz számos open source megvalósításuk van, ami miatt azokat bárki megfejtheti. (Matek, ugyan már, az csak egy humbug, mindig is untam a suliban...)
Szemben a mindenfajta szakértelem, hozzáértés, tapasztalat, gyakorlat és tesztelés nélkül pár nap alatt összebarkácsolt kódokkal, mert az biztonságos lesz.
Könyörgöm, egy picit gondolkodjatok már el.
Ha biztonságot akarsz, akkor használj https kapcsolatot, ne pedig összebarkácsolt izzadságszagú borzadályokat, amik kizárólag a felhasználói élményt csorbítják.
pp
Jaja, a nyilvános kulcsú
Itt alighanem arra gondolt, hogy a közkézen forgó népszerű rendszereknek a biztonsági hibái eléggé ismertek, és azt könnyebben kihasználhatják, mint egy olyan megoldásét, ami nem ismert, és kívülről kell megfejteni a működését. És ebben azért van valami... Robotok próbálnak rá ezekre az exploitokra, és ha nem jó cuccból nem jó verzió van fent, akkor ott tudnak izgalmas dolgok történni. Volt, hogy ismerősöm megkért, hogy nézzek már rá egy oscommerce alapú oldalra, mert valami nem stimmel, és találtam mögötte egy php shellt. Nyilván többrétű dolog ez, https, session védelem, input ellenőrzés, db, fs jogosultság, rewrite rule stb. De az biztos, hogy egy nyílt forrású, "felteszemésmegy" típusú rendszer általánosságban nagyobb biztonsági kockázat, mint egy szakértő által jól megírt saját framework. Már csak azért is, mert a felhasználóinak kb 10%-a tudja, hogy mit is csinál belül az általa használt framework.
"Itt alighanem arra gondolt,
Szóval az igaz, hogy a sok ismert rendszernél írhatsz biztonságosabb kódot, csak az nem igaz, hogy ha más kódot írsz akkor az biztonságosabb lesz. És ez azért nagy különbség. Pepita pedig ez utóbbit állítja, ami miatt írtam ami írtam.
pp
Hűha!
Egy szóval sem állítottam, hogy attól jobb (biztonságosabb) lesz egy felhasználókezelés, mert én írom. Viszont (helyenként igen nagy) előnyt jelent, hogy nem ismerik azok, akik támadni akarják.
Úgy tűnik, itt Blaze és Mahoo pontosan értették, hogy mit mondok - te viszont nagyon nem. Tudom, hogy nagy Drupal-os vagy (úgy értem: nagyon értesz hozzá), úgyhogy itt végtelenbe-veszően vitatkozhatnánk erről, de én nem tenném. Ez mindössze nézőpont kérdése:
- A Drupal-t (de lehetne más népszerű fw / cms is) többezren fejlesztik -> valószínűleg (biztosan) jobb, mint amit 1-2 fejlesztő;
- Nagyságrendekkel több helyen használják fel -> többen is akarják feltörni.
- Ha biztonsági szempontból megfelelő felhasználókezelést írok egymagam (vagy páran), akkor ez egy kevésbé "mindentudó" cucc lesz, de
- Kevesebben akarják (tudják) megtörni.
Természetes, hogy itt nem egy összegányolt sz***ra gondolok, ha te ennyit nézel ki belőlem - hát az a te bajod, nem az enyém. Máskülönben nem ez az első eset, hogy ebben (saját fejl. <> nyílt forrás) összekülönbözik a véleményünk, ha egyszer meg tudnál győzni (ezt kétlem), akkor én is valószínűleg Drupal-t használnék.
Ja, és BUÉK, most látom, milyen régire válaszoltam!
Idéztem amire reagáltam,
"ámde van egy nagy előnyöd a "gyáriakkal" szemben: csak te ismered..."
Ez hol előny már???? De tényleg. Mitől lesz ez előny??? Ez egy zárt forrású propaganda bullshit. Nem a kódot olvasgatva fogják feltörni az oldaladat, hanem egész máshogy.
Nem az a baj, hogy vannak sebezhetőségek, esetleg a sebezhetőségeket kihasználó kártékony kódok, hanem az, hogy nem frissítik a rendszereket, amikre már rég kijött a javítás. De ez nem a rendszer sajátja, hanem az üzemeltetésé. És kapaszkodj meg, mindegy, hogy a forrás nyílt vagy zárt. Lényegtelen. Erről szól a bejegyzésem.
Olvasd Blaze bejegyzését (ha már ő érti Te mit írtál)
"Robotok próbálnak rá ezekre az exploitokra, és ha nem jó cuccból nem jó verzió van fent, akkor ott tudnak izgalmas dolgok történni."
Látod, látod, ő is rossz verzióról ír, elavult, nem karbantartott rendszerről, a hanyag üzemeltetésről.
Ez a sugalmazás, hogy ha nem ismerik a kódot akkor kevésbé fogják tudni megtörni a rendszered, szerintem gáz. Gáz mert olyan példákkal támaszthatnád csak alá (Blaze írja, hogy Te mire gondoltál, Te azt írtad, ő érti mire gondoltál, de mivel nem írtad nem adom a szádba, ezen ne pörögjünk, ezért a feltételes mód), amik nem igazolják a tézisedet, hisz nem rendszer hibái miatt törik fel az oldalt, hanem a hanyag üzemeltetés miatt.
Te:
"Természetes, hogy itt nem egy összegányolt sz***ra gondolok, ha te ennyit nézel ki belőlem - hát az a te bajod, nem az enyém."
Én rólad nem írtam semmit, elnézést, ha így lehetett érteni amit írtam. Messze álljon tőlem, hogy bárkit is minősítsek.
Én arról írtam, hogy létezik a https mint titkosított csatorna (aminek a kódja, nyílt, algoritmusa régóta ismert, számos implementációja van amit bankok, kormányzati szervek és a biztonsággal foglalkozó szakemberek használnak) ezen kéne kommunikálni és nem a titkosítatlan csatornán. Attól lesz biztonságosabb, nem attól, ha nem ismerik a kódját az alkalmazásomnak. Ez utóbbi biztonsági szempontból semmilyen "előnyt" nem jelent.(se hátrányt, se a nyílt forrás nem jelent előnyt, se hátrányt. Mindegyik pro és kontra állítás nélkülöz mindenféle alapot)
Ha van király módszered, amely segítségével titkosítatlan csatornán úgy lehet kommunikálni, hogy lehallgatás segítségével nem lehet megtörni egy fél óra (inkább 1-2 perc) alatt, akkor megtisztelnél azzal, ha megmutatnád.
"Máskülönben nem ez az első eset, hogy ebben (saját fejl. <> nyílt forrás) összekülönbözik a véleményünk"
Én úgy gondolom, egy nyílt forrású fejlesztésben részt venni azt jelenti, hogy több ezer(tízezer) emberrel közösen fejleszteni. Tehát én is a saját kód híve vagyok, kapaszkodj meg, csak nem gondolom, hogy egyedül, vagy pár barátommal kéne csak dolgoznom, ha megtehetem azt, hogy a világ számos pontján élő, nagyszerű fejlesztővel együtt dolgozhassak.
Nekem személy szerint nagyon sokat segített, és segít minden nap, hogy nem egyedül, hanem egy csapatban dolgozom, ahol rendszeresen átnézzük egymás kódját, és ha olyan akkor distributáljuk a Drupal közösség felé, ahol még többen átnézik ezeket a kódokat és tovább csiszolják. Én nem tudnék jobb kódot írni egyedül, mint csapatban. Én másnak nem javasolnám, hogy egyedül álljon neki saját rendszert írni.
Ez alól egy kivétel van a tanulás, de ott az elkészült produktumok helye a kuka, nem éles bevetés, hisz ott nem a produktum, hanem az alkotás folyamata során létrejövő mentális struktúra az érték, ami keletkezik
pp
Csak te ismered: szakértő
Ugyanakkor könnyen előfordulhat, hogy egy hozzáértő embernek jóval kevesebb dolga lesz a feltöréssel, mint egy ismert, de jól megírt kódú rendszerrel.
Pl. pont az authentikáció és session kezelés egy olyan téma, ahol nehezen tudom elképzelni, hogy egy egyszemélyes team jobb munkát végezhet, mint egy már kiforrott rendszer, összeszokott és javarészt biztonsági témákkal foglalkozó fejlesztői.
Kimerítő válasz
Bocs a Drupal példáért, de a nyílt CMS-ek közül talán a legjobb példa (szerintem), de az, hogy megemlítettem, nem jelenti, hogy rossznak tartanám, sőt.
Ami cuccost viszont csak néhány oldalon használsz (használok) és különbözik az elterjedtektől, azt kevesebben is fogják (sikerrel) támadni, ugyanolyan (nem)frissítés / javítás mellett. De ne lovagoljunk ezen tovább, az is igaz, hogy többen jobbat lehet fejleszteni, "a kettő összegét" meg nem lehet kiszámítani.
A https-t nem keverném ebbe a témába, hisz munkamenetkezelésről szól elsősorban, nem csatornákról-protokollról.
egy nyílt forrású,
Az eddigi több, mint 8 éves weblaboros pályafutásom után, a Weblaboron feltett kérdéseket és megoldásokat alapul véve, azt mondom, még mindig jobb egy kitesztelt keretrendszert használni, mint sajátot fejleszteni, ha azok olyan minőségűek, mint amikből itt általában példákat látunk.
Ebben teljesen egyetértünk,
Kerestem valamit, amibe még beleköthetek ;-)
Azért annyira nem kötekedés: mi jelentősége van biztonsági szempontból, hogy a frameworköt használó programozó mennyire ismeri a fw belső működését?
Ismerje az interface-t, a többihez valójában semmi köze! (szerintem - de lehet, hogy túl sok OOP témájú írást olvastam az elmúlt évben ;-) )
Azért annyira nem kötekedés:
Ha nem tudja hogyan működik, honnan tudja, hogy mennyire biztonságos, hogy rábízhat-e érzékeny adatokat? Alapvetően igaz, hogy elég az api ismerete egy frameworknél, de azzal azért jó tisztában lenni, hogy pl mik történnek a bejövő adatokkal, mire eljutnak hozzánk és mely pontokon tudnak problémát okozni.
Pl. onnan, hogy utánanéz a
Biztonsági audit elég macerás, sok ismeretet igénylő téma...
Pl. onnan, hogy utánanéz a
Amit vagy felkészült programozók írnak, vagy nem. A neten fellelhető információk helyessége, aktualitása sokszor megkérdőjelezhető. Tudom, a komolyabb rendszereknek van biztonsági levlistája, hírlevele stb. De egy kezdő ezt se feltétlenül tudja értelmezni. (pl ha tudja mi az az sql injection, védekezni is tud ellene)
Szerintem is. És ez volt a kiindulópont, ezért írta Pepita is, hogy innentől már jobb sajátot használni áttekinthetőségi és biztonsági megfontolásból is. Kezdőnek nyilván nem, bár ez se feltétlenül egyértelmű, mert mindenki kezdőként kezdi, és valahogy tisztába kell kerülni a dolgokkal. Aki csak kész dobozokat pakolgat egymásra leírás alapján, az sose lesz jó programozó. És akkor jön a sok keresünk ilyen CMS, olyan CMS, meg ilyen FW, olyan FW programozókat álláshirdetés... Aztán ha elkerül egy olyan helyre, ahol nem csak blackboxok összehegesztését jelenti a programozás, akkor csak néz. Ilyen szempontból szerintem üdvözítő ez a szál, mert a kolléga meg akarja ismerni a dolgokat, ez azért átjön a hozzászólásaiból. És erre nem jó válasz azt mondani, hogy használj frameworkot, abban már megcsinálta valaki jól (vagy nem).
Az a baj, hogy akinek Pepita
Ami a fórumos véleményeket illeti: annyira értek hozzá, hogy kb. a neten talált információkból eldöntsem, a kiválasztott fw-re rábízhatok-e egy kisebb oldalt, arra viszont nem vállalkoznék, hogy ugyanehhez az oldalhoz magam barkácsoljak beléptető rendszert. Lényegesen kevesebb ismeret kell ahhoz, hogy a netről viszonylag megbízható (100%-os megbízhatóság ugye csak elméletben) infókat gyűjtsek egy rendszerről.
Az a baj, hogy akinek Pepita
Szerintem olvasd vissza, hogy Pepita mit írt és mire, mert ez így kicsit népmesés :)
Kubi írta a kérdezőnek, hogy
én már hozzá sem szólok :) A
Érdemes böngészni a logokat,
És ezzel nem azt mondom, hogy tilos külső fw-t, cms-t használni, szerintem Pepita sem erre célzott. Hanem itt is érteni kell hozzá mit raksz fel, minek milyen r/w jogokat stb adsz, milyen frissítéseket végzel stb. Különben a kitesztelt biztonságos rendszer csak elméleti biztonságot ad, és könnyen lehet, hogy átjáróház. Analógia: használj linuxot, és akkor nem törik fel a szervered, mert az biztonságos. Ez azért nem egészen így megy :)
Arról tényleg nem is beszélve, hogy a kérdező le is írta, hogy tanulási céllal csinál sajátot...
Tényleg azon vagyok/voltam,
De köszönöm a segítő jellegű hozzászólásokat!!!
Félreérted: amíg tanulási
Tudod pl. mi az az SQL injection, session fixáció, hányféleképp lehet ellopni egy már authentikált munkamenetet a felhasználótól?
(csak ami így hirtelen eszembe jutott - és nagyon nem értek hozzá!)
Szóval amíg nincs tétje a dolognak és van időd, türelmed utánaolvasni a dolgoknak, addig csináld, sokat lehet tanulni belőle!
De ha valami olyan oldalt készítesz, ahol necces a dolog - pl. személyes adatokat akarsz tárolni a hozzád regisztráló felhasználókról - akkor háromszor gondold meg, hogy belevágsz-e saját rendszerrel vagy megtanulod valamelyik népszerű frameworköt!
(fw-t azért nem tudok javasolni, mert az egyetlen, amit legalább felszínesen ismerek, az pythonos... :-) )
Persze, értem én, de... de
Kerestem én már FW-öt, valami kisebb, könnyen elsajátíthatót. Rain FW nekem nagyon szimpatikus, de kevesen használják és ezáltal - meg egyébként is - nem tudom eldönteni, hogy ez most biztonságos-e vagy sem.
Rá kell keresni, hogy pl "PHP
Ha esetleg olyan oldal, amin kötelező javascript használatot keresztül tudod verni, akkor a slim és egy rest service, amit javasolni tudok.
Ez (is) túlzás
A fw-re sem mondtam egyértelmű NEM-et, csak azt mondtam, hogy általában, bármilyen fw-t ne ajánljunk! Attól még bárki ajánlhat fw-t, csak írja oda, hogy konkrétan melyiket és miért!
Mellesleg más témákban én (is) ajánlottam már a CodeIgnitert, mert kicsi, gyors, könnyen tanulható, most nem sorolom, de nincs "benne" felhasználókezelés, tehát írd meg a magadét. Hátránya: ne hidd el (ha "necces" az oldal), hogy biztonságos egy szolgáltatása, amíg nem győződtél meg róla - de ez kb. minden fw-re igaz.
Blaze, ezúton is köszönöm a védelmet!
Nem becsülném azért alá a
Biztonság a weben
Nem tudom, ki mennyire ismeri ezeket a folyamatokat, de lenne egy "lehet hogy buta" kérdésem!
Extrém esetben, ha egy hacker figyeli a kapcsolatot, a munkamenet ellopása után előbb futtat egy új kérést, mint a ténylegesen belépett felhasználó, az létezhet?
Amiért viszont konkrétan írok, hogy írnék egy biztonságos felhasználókezelési rendszert, aminek a működési elvét igyekszem kitalálni és érdekelne a véleményetek!
A használjak fw-öt megoldás nem érdekel, mert azzal nem tanulok semmi újat és nem látok benne akkora kihívást sem.
Alapvetően a dolgot így képzelném el:
Ha a felhasználó nincs belépve, akkor nem figyelek semmit.
Ha a felhasználó belép, akkor törlöm az előző munkamenetet és létrehozok egy teljesen újat, majd adatbázisban tárolom a felhasználót, a session-t, az ip-t, a böngésző-t, az utolsó lekérés idejét és egy cookie értéket.
Ez után beállítok egy cookie-t, ami oldal lekérésenként változni fog, hossza 18 karakter lesz és az adatbázisban is tárolódik.
Ameddig a felhasználó munkamenete meg nem szűnik, addig minden oldal lekérés alkalmával elvégzem az alábbi ellenőrzéseket:
- Ellenőrzi a cookie értékét az adatbázisba mentett értékkel, ha nem egyik, akkor valószínűleg valaki próbálkozik valamivel, ezért a munkamenet hibával megszűnik.
- Ellenőrzi, hogy az adatbázisban tárolt böngésző megegyezik-e a kérést küldő böngészővel. Ha nem, akkor és a munkamenet változó ugyan az mindkét esetben, akkor session lopás volt, ezért a munkamenet hibával megszűnik.
- Ha az IP nem egyezik a munkamenethez tartozóval és X másodpercen belül jött az új kérés a másik IP-ről, akkor gyanús valami van!
Ebben az esetben az új IP-t is rögzítjük az adatbázisban és ha a régi IP-ről jön egy új kérés, akkor már tuti valami nem oké, ezért a munkamenet hibával megszűnik.
Ezt az IP-s dolgot, azzal indokolom, hogy egy szolgálató pár percenként nem ad ki új IP-t a felhasználóinak, de ha mégis megtörténne ez, akkor sem a régit adná neki vissza.
Olvastam még a session.referer_check-ről is, de nem sikerült megértenem pontosan hogyan működik.
Ha valaki leírja nekem, azt nagyon szépen köszönöm!
Előre is köszönöm az építő jellegű hozzászólásokat! :)
IP váltáshoz csak annyit (nem
Ilyen esetben, a proxy IP
Viszont az írásodról eszembe jutott a Thor hálózat, ahol emlékeim szerint gyakran cserélődik az IP, viszont ott sem adja ki rövid időn belül 2x ugyan azt az útvonalat!
A hidemyass.com-ot azért
Köszi, ez nekem nem tűnt fel
Többszöri tesztelés után úgy látom, hogy a random IP, amit mondtál a listában levők közül választ ki 1-et és utána végig azt használja a munkamenet folyamán.
Minden esetre a felvetés jó volt, köszi!
Ha nem banki oldalt
Egyébként is, tipikusan azokban a helyzetekben, ahol a támadó hozzáfér a sessionhöz (XSS, kódolatlan wireless, malware), az IP-címet, sütiket és a böngészőt is könnyen tudja utánozni, úgyhogy nem jelentenek komoly védelmet.
Nem banki oldal, ahhoz még
Ha kíváncsi vagy a