Zadejte hledaný výraz...

SESSION bezpečnosť

Bokos
verified
rating uzivatele
29. 10. 2011 12:38:02
Ahojte, môžte mi poradiť ako dobre zabespečiť session? Ideálne nejakým príkladom to vysvetliť :-).
Čítal som, že nie sú až tak v bezpečí tak sa chcem opýtať ako to naozaj je a ako spraviť lepšiu bezpečnosť pre ne.
Ďakujem vopred :-).
29. 10. 2011 12:38:02
https://webtrh.cz/diskuse/session-bezpecnost/#reply692587
P-ierre
verified
rating uzivatele
(43 hodnocení)
29. 10. 2011 12:52:58
Pravděpodobně máš na mysli "session stealing." To se prostě může stát, že někdo tvému uživateli ukradne jeho session id (je uložené v počítači mezi cookies), a pak se za něj vydává. Server pak akorát kontroluje "jo, tuhle session id tu mám zaregistrovanou, má tady hodnotu true pro proměnnou admin, tak mu dám veškerý práva" a problém je na světě.
Ve chvíli, kdy ale nebudeš kontrolovat jen session id, zabráníš tomuhle způsobu útoku. Server: "Jo, tuhle session ID, tu mám zaregistrovanou, ale moment - přistupuje najednou z jinýho počítače, než předtím, takže dál nepokračuju." Co dalšího můžeš kontrolovat? Běžně se porovnává USER_AGENT (v něm jsou informace o prohlížeči a OS), IP adresa a někdy i třeba rozlišení obrazovky (potřeba načíst javascriptem a předat pak serveru třeba ajaxem).
29. 10. 2011 12:52:58
https://webtrh.cz/diskuse/session-bezpecnost/#reply692586
tm
verified
rating uzivatele
(5 hodnocení)
29. 10. 2011 13:49:08
Doporučuji si přečíst něco o XSS (Cross-Site Scripting).
Ale ve zkratce, jak se proti ukradení cookies, resp. session ID, bránit:
  • ošetřovat uživatelská data (guestbook, články, diskuze apod.), která vypisuješ na stránku, mohou obsahovat nebezpečné tagy, skripty (např. pomocí PHP funkce htmlspecialchars)
  • po každém přihlášení uživatele přegenerovat session ID (PHP funkce session_regenerate_id) - ze stejného důvodu jako je např. pravidelná změna přihlašovacího hesla do internetového bankovnictví
  • provozovat stránky přes HTTPS (zabránění sniffingu, tj. odposlouchávání paketů)
  • zabezpečit přístup ke svému počítači a webovému serveru
29. 10. 2011 13:49:08
https://webtrh.cz/diskuse/session-bezpecnost/#reply692585
Bokos
verified
rating uzivatele
29. 10. 2011 14:12:45
Ďakujem krásne, ale tak ako spraviť bezpečný login? Čo je dobré ukladať do SESSION? Ja som to dodnes robil veľmi jednoducho, vždy keď sa prihlásil tak len pozeralo meno či existuje v databáze. A pri načítavaní profilov(atď) som len použil
A podľa čo píšete je to veľmi slabé :-).
A môžte mi ešte prosím poradiť čo presne robí "session_regenerate_id" ako mi to pomôže?
29. 10. 2011 14:12:45
https://webtrh.cz/diskuse/session-bezpecnost/#reply692584
hm
verified
rating uzivatele
(20 hodnocení)
29. 10. 2011 14:21:42
napriklad pridej kontrolu user-agent (prohlizec se behem prihlaseni nemeni, jedinej moment kdy se to stane je kdyz nekdo ukradne sessionu a da ji do sveho prohlizece...)
nejak takto ... (mozna by se data nicit nemuseli, jen se nepovoli pristup, jde o to jak moc opatrnej chces byt - kdyz data pri podezrele aktivite uplne znicis, zabranis tak vicenasobnym pokusum)
if($_SESSION!=$_SERVER) {
// Unset all of the session variables.
$_SESSION = array();
// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (ini_get("session.use_cookies")) {
$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000,
$params, $params,
$params, $params
);
}
// Finally, destroy the session.
session_destroy();
}
samozrejme nastavit $_SESSION = $_SERVER; po prihlaseni :)
29. 10. 2011 14:21:42
https://webtrh.cz/diskuse/session-bezpecnost/#reply692583
Bokos
verified
rating uzivatele
29. 10. 2011 14:45:52
Ďakujem a čo tak IP?
Stačí vytvoriť tiež $_SESSION ($_SERVER ? Niekde som tu na fóre videl, že ten posledný kúsok z IP sa môže zmeniť.
29. 10. 2011 14:45:52
https://webtrh.cz/diskuse/session-bezpecnost/#reply692582
hm
verified
rating uzivatele
(20 hodnocení)
29. 10. 2011 14:55:14
pokud kontrolovat ip tak jen prvni tri segmenty, protoze ctvrte cislo muze byt v nekterych pripadech dynamicke ... ale jinak samozrejme - pridat to ke kontrole user-agent a sessiona je temer neukradnutelna :)
29. 10. 2011 14:55:14
https://webtrh.cz/diskuse/session-bezpecnost/#reply692581
Bokos
verified
rating uzivatele
29. 10. 2011 15:11:52
Aha. Tak som skúsil niečo :-). Stačí takto ? :-)
29. 10. 2011 15:11:52
https://webtrh.cz/diskuse/session-bezpecnost/#reply692580
hm
verified
rating uzivatele
(20 hodnocení)
29. 10. 2011 15:29:59
no nevim jestli to funguje nebo ne, ale teoreticky ok... jinak != "" ... od ceho mame isset, empty, is_null a dalsi komplexnejsi fce? :) vzdycky by me jeblo kdyz vidim != "" :)
29. 10. 2011 15:29:59
https://webtrh.cz/diskuse/session-bezpecnost/#reply692579
tm
verified
rating uzivatele
(5 hodnocení)
29. 10. 2011 15:34:09
Tady je potřeba si nejdříve ujasnit, jak fungují sessions.
Sessions jsou data uložená na straně serveru, nikoliv na straně klienta. Prohlížeč tudíž nemá k sessions přístup. Vše, co uložíš do session, zůstane pěkně uložené na serveru. Přístup k session je v PHP zprostředkován pomocí globálního pole $_SESSION:
$_SESSION = 'frantanovak';
Javascript se k těmto hodnotám nedostane. Protože je zpracováván na straně klienta.
Aby server věděl, které session patří klientovi, existuje session ID (náhodný textový řetězec). Tento identifikátor se předává pomocí cookies v HTTP hlavičce. Cookies jsou vlastně takové serialozované pole.
Práce se sessions vypadá např. následovně (zjednodušeně):
  • Klient pošle HTTP požadavek na zobrazení stránky webtrh.cz. Předpokládejme, že na těchto stránkách klient nikdy nebyl, proto se v HTTP hlavičce neposílají žádné cookies.
  • Server, protože HTTP požadavek neobsahuje informace o cookies, založí nové session a vygeneruje mu ID (sessions jsou většinou ukládána do souborů). Zpracuje požadavek, vygeneruje stránku a data zašle zpět klientovi. v HTTP hlavičce odpovědi je něco takového:
  • Klient přijme HTTP odpověď od serveru. Vytáhne z hlavičky informace o cookies a někam si je uloží (není teď podstatné kam). Uživatel vyplní přihlašovací formulář a odešle jej zpátky na server. Do HTTP požadavku přidá uložené informace o cookies:
  • Server přijme HTTP požadavek. Podívá se do HTTP hlavičky a zjistí, že obsahuje cookies se session ID. Načte tedy data session s odpovídajícím ID. Data z formuláře ověří např. oproti databázi a do session si poznačí např. toto:
    $_SESSION = true;
    Opět vygeneruje stránku a odešle data zpátky klientovi. V HTTP hlavičce se nachází zase něco takového:
  • Klient přijme HTTP odpověď od serveru. Opět projde HTTP hlavičku a hodnoty cookies si někam uloží. V dalším HTTP požadavku je opět uvede.
  • Server podle session ID, předané pomocí HTTP hlavičky požadavku, načte data. Zjistí, že je klient přihlášen a podle toho se může patřičně zachovat:
    if($_SESSION == true) ...
    Zpracuje požadavek, vygeneruje stránku a pošle odpoveď prohlížeči. Do HTTP hlavičky opět přidá informace o cookies a session ID.
  • Takto se to víceméně opakuje neustále dokola. Klient a server si neustále přeposílají informaci o session ID.
    Teď si představ, že někdo cizí zná tvoje session ID. Odešle HTTP požadavek, který obsahuje:
    Server načte data uložená v těchto session a zjistí, že je uživatel přihlášen a má např. administrátorská práva. Proto je session ID tak citlivý údaj. Protože ukazuje na data na serveru, která obsahují např. informace o uživatelských právech.
    Prohlížeče si uchovávají cookies pro každou doménu zvlášť. Proto, i když se např. na Webtrhu neodhlásíš, budeš při příští návštěvě opět přihlášen. Protože v HTTP požadavku na server prohlížeč uvede cookies, se kterýma pracoval naposled. A v těchto cookies je uložené session ID. A server už ví, že tento klient je přihlášený.
    Na straně klienta má k cookies, a tedy k session ID, přístup např. javascript. Proto je nutné si pohlídat, aby do HTML kódu tvojí stránky nedostal kód, který cookies přečte a odešle někam na útočníkův server (XSS útok).
    Krádež session můžeš zkomplikovat, jak již bylo několikrát řečeno, např. kontrolou IP adresy klienta, informací o prohlížeči, OS apod. Tyto údaje si stačí uložit na straně serveru do session a při každém požadavku kontrolovat oproti údajům v HTTP hlavičce požadavku od klienta. Pokud je např. IP adresa uložená v session jiná oproti IP adrese, ze které přišel HTTP požadavek, je tu velká pravděpodobnost krádeže session ID.
    Přegenerováním session ID, např. po přihlášení, můžeš zneplatnit ukradené session ID - protože server vygeneruje nové ID, to staré (a ukradnuté), najedou přestane na serveru existovat a jeho použití nebude mít žádný efekt.
    Zabezpečení komunikace pomocí HTTPS zase znemožníš tzv. packet sniffing. Funguje to tak, že mezi tebou a serverem sedí osoba, která čte vaši komunikaci a vidí, co si mezi sebou posíláte za data. A není nic jednoduššího, než si v HTTP hlavičce přečíst session ID. HTTPS protokol je šifrovaný, tj. nepřečte (skoro) vůbec nic, především HTTP hlavičky požadavků a odpovědí.
    To je snad ve zkratce všechno, spoustu dalšího materiálu o cookies a sessions najdeš na internetu ;)
  • 29. 10. 2011 15:34:09
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692578
    Tom
    verified
    rating uzivatele
    (6 hodnocení)
    29. 10. 2011 15:50:43
    Ještě bych doplnil, že se může použít HTTP cookie (http://en.wikipedia.org/wiki/HTTP_cookie) a k session ID bude mít přístup jenom prohlížeč a nedostane se k tomu ani javascript na dané stránce. Pokud se pletu tak mě opravte, jistě to nevím.
    29. 10. 2011 15:50:43
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692577
    Bokos
    verified
    rating uzivatele
    29. 10. 2011 17:25:27
    Aha tak to je celkom nových pojmov naraz. Ďakujem pekne, je mi to hneď jasnejšie... Ale vrtá mi hlavou prečo sa nepoužíva len HTTPS :-) + stačí mi teda také zabezpečenie aké mám hore(zničí session a potom vygeneruje ak tak nové ID nie? :P) ?
    29. 10. 2011 17:25:27
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692576
    hm
    verified
    rating uzivatele
    (20 hodnocení)
    29. 10. 2011 17:54:20
    https je komplikovanejsi protokol a v mnoha pripadech pro nej neni duvod, proto se pouziva jen pro pristupy do uzivatelskych sekci apod.
    29. 10. 2011 17:54:20
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692575
    tm
    verified
    rating uzivatele
    (5 hodnocení)
    30. 10. 2011 00:06:51
    Šifrování je poměrně náročné na výkon serveru (proto se někde nasazuje jenom na přihlašovací a administrační část webu). Navíc potřebuješ certifikát, který není zadarmo (pokud má být podepsaný důvěryhodnou certifikační autoritou).
    30. 10. 2011 00:06:51
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692574
    Bokos
    verified
    rating uzivatele
    30. 10. 2011 11:41:38
    Aha no tak ďakujem :-). Možno ešte keby ste mi skomentovali ten môj "user-check-agent" :-).
    $userdata = array();
    $_SESSION = (!isset($_SESSION))? "" : $_SESSION;
    $_SESSION = (!isset($_SESSION))? "" : $_SESSION;
    if (isset($_SESSION) AND !empty($_SESSION) AND isset($_SESSION) AND !empty($_SESSION)) {
    $sql = dbquery("SELECT * FROM ".USERS." WHERE user_name = '".mysql_real_escape_string($_SESSION)."' AND user_surname = '".mysql_real_escape_string($_SESSION)."'");
    if (dbrows($sql) == 0) {
    session_destroy();
    redirect(BASEDIR."index.php");
    } else {
    if($_SESSION != $_SERVER || $_SESSION != IP3segment(S_IP)) {
    session_destroy();
    redirect(BASEDIR."index.php");
    } else {
    $userdata = dbarray($sql);
    }
    }
    }
    define("iGUEST", $userdata == 0 ? 1 : 0);
    define("iMEMBER", $userdata >= 101 ? 1 : 0);
    define("iADMIN", $userdata >= 102 ? 1 : 0);
    define("iSUPERADMIN", $userdata == 103 ? 1 : 0);
    ?>
    30. 10. 2011 11:41:38
    https://webtrh.cz/diskuse/session-bezpecnost/#reply692573
    Pro odpověď se přihlašte.
    Přihlásit