Ťažké kombinované heslá ktoré sú v databázi samozrejme šifrované. Oboznámenie užívateľov so základnými prvkami bezpečnosti (nie, my naozaj nikdy nebudeme potrebovať Vaše heslo). Atď...
To všetko je zbytočné ak užívateľ klikne na podhodenú adresu a agent (prehliadač) nastaví referenčnú adresu (s celým SID v URL, ak nebolo uložené v cookies).
Útočník má 24 minút (pokiaľ nebolo nastavené inak) na dosiahnutie svojho zámeru. Práve začínajúci programátori by mali venovať problematike bezpečnosti svojich naskriptovaných projektov viac času a pozornosti.
V predchádzajúcich riadkoch bola jedna dôležitá fráza: pokiaľ nebolo nastavené inak...
Budem sa teda venovať nastaveniu sessions. Jednotlivé parametre stručne popíšem.
Prototyp fcie ini_set()
string ini_set ( string $varname , string $newvalue )
Nastavenie hodnôt:
ini_set('session.auto_start', FALSE);
ini_set('session.cache_limiter', 'nocache');
ini_set('session.use_only_cookies', TRUE);
ini_set('session.entropy_file', '/dev/urandom');
ini_set('session.entropy_length', 32);
ini_set('session.cookie_httponly', TRUE);
ini_set('session.hash_function', '1');
ini_set('session.name', 'BH_Posedenie');
ini_set('session.cookie_lifetime', 0);
'session.auto_start', FALSE
- automatický štart relácie vypnutý, začatie relácie sa vykoná funkciou session_start()
'session.cache_limiter', 'nocache'
- výsek z manuálu (najzrozumiteľnejšie vysvetlenie): "...Setting the cache limiter to nocache disallows any client/proxy caching..."
'session.use_only_cookies', TRUE
- pre uloženie SID u klienta budú použité výlučne cookies v prehliadači. V PHP6 už ako prednastavené.
'session.entropy_file', '/dev/urandom'
- dodatočné zariadenie (pre entropiu) použité pri tvorbe SID, (urandom, random - generátor náhodných znakov)
'session.entropy_length', 32
- dĺžka vygenerovaného reťazca použitého pre SID (zo zariadenia v predchádzajúcej voľbe)
'session.cookie_httponly', TRUE
- ku cookies sa bude dať pristupovať len cez HTTP, môže poslúžiť ako obrana pred XSS útokmi
'session.hash_function', '1'
- hash algoritmus pre generáciu SID, 0 pre md5 (128b), 1 pre sha-1 (160b)
'session.name', 'BH_Posedenie'
- názov relácie, pre bezpečnosť minimálny význam
'session.cookie_lifetime', 0
- "dátum spotreby sušienok", 0 - expirácia po zavretí okna prehliadača
Ďaľšie voľby:
'session.cookie_secure', TRUE
- cookies prenositeľné / poslateľné len cez zabezpečené spojenia (HTTPS)
'session.gc_maxlifetime', 1440
- čas (v sekundách) po ktorého uplynutí sú data označené ako "odpad" a následne vyčistené (upratané, odstránené), 1440 je prednastavená hodnota (24min)
Detailný zoznam volieb, možností a hodnôt:
http://php.net/manual/en/ref.session.php
(samozrejme že v referenčnej príručke, alebo v manuáli ;-) )
Toto bol taký mierny základ, hrátka. Ak by bol záujem môžem napísať i druhý diel so všeobecnými návrhmi implementácie rôznych prvkov použitých ako bezp. prvky a ich kombinovanie.
Ak by bol záujem môžem napísať i druhý diel so všeobecnými návrhmi implementácie rôznych prvkov použitých ako bezp. prvky a ich kombinovanie.
No bolo by vhodne, lebo takto je clanok iba nejaky zoznam, ktory zacinajuci PHP-ckari neupotrebia. Ale riesenie utoku s podvrhnutym PHPSESSID je jednoduche: session_regenerate_id()
----------------------
Ja len v dobrom.
Dôležité je to spomenúť, že niečo také existuje aby sa to dostalo do povedomia. Áno, regenerovať SID je tiež vhodné riešenie (v kombinácii s inými opatreniami), chcel som ho spomenúť ako jeden z prvkov v pokračovaní (ak by bol teda ten záujem :P ).
Ale SID môžeš regenerovať vždy pri spracovaní skriptu na serveri, teda napr. keď klient požiada o ďaľší dokument, alebo o obnovu stávajúceho.
Zober však do úvahy fakt, že napríklad píšeš článok, alebo vykonávaš inú pasívnu činnosť. Predpoklad je taktiež nastavenie dlhšieho času platnosti sedenia, aby sa nestalo že človek napíše napr. ten článok a keď sa ho bude snažiť odoslať, bude už odhlásený.
Preto pokiaľ píšeš ten článok (už je to modelová situácia) si zraniteľný po dobu po ktorú ho píšeš (ak už nevyprší spomínaná platnosť sedenia).
Toť všio, ale vďaka za námet na diskusiu :)
____________________________________________________
Something wrong happend there, our blood is everywhere...
priklanam sa k napisaniu pokracovania,
ak by sa dalo nieco rozpisat o tokenoch, ked sa to tu uz tak spomina ...
Dobre zacinajuci clanok. Napis aj prakticke veci, priklady, pomozu nielen obcasnym phpckarom.
Dik.
Ja mam session poriesenu tak, ze ju inicializujem cez session_start() + cez moje vlastne fcie, ktore sa staraju o zapis session do databazy.
Vygeneruje sa SID ulozena v cookies, samozrejme je nastavene ('session.cookie_httponly', TRUE); aby sa nedali odchytavat javascriptom. SID sa zapise aj do databazy, spolu s ID prihlaseneho usera, jeho IP adresou, user agentom a hlavickou X_FORWARDED_FOR (ak ma nejaku hodnotu).
Cize aj ked niekto ziska SID, musel by najprv vytvorit takyto cookie, a zaroven by musel mat rovnake hodnoty pre vsetky polozky v databaze - user id, user IP, user agent, ak je user za proxy tak aj X_FORWARDED_FOR (ak tuto hlavicku proxy preposiela), co logicky mat nebude (uz len koli tomu, ze nema ako ziskat user ID), preto aktualnu session hned vymaze.
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null
Na podobne. Tiez testujem/odkladam vsetko mozne z USER_AGENT + REMOTE_ADDRESS.
----------------------
Ja len v dobrom.
najjednoduchsi sposob ako ochranit aplikaciu a zaroven najlepsi je pouzitie tokenov, cize v pripade ze neprejde generatorom tokenu cize sa inicializacia nevykona a tak ta stranka vrati na zaciatok napriklad na login pass. session ta nezachrani. potom je este mozne samozrejme pouzivat mnozstvo identifikacnych udajov ako ip atd ale to je privela udajov a v pripade velkeho mnozstva navstevnikov by to zabilo celu db, kedze tokeny s db nic nemaju.
ved si vezmi, mam tisic ludi on, cize mam tisic zaznamov trebars 24 minut
ak mam kazdu minutu dalsich tisic tak o 24minut mam 24 tisic ludi co je 24 000 zaznamov. nie je to nijak extremne cislo, kazdopadne ak mam funkcnu velku aplikaciu tak mi to spomaluje cely system a teda mam vacsie naroky na box
na toto presne doplaca digg, privela sluzieb a nezvladaju udrziavat masiny v chode
Ked mam pravdu povedat o tokene pocujem mozno druhy krat, ale ked tak pozeram:
http://phpsecurity.org/code/ch02-5
http://phpsecurity.org/code/ch02-6
vyzera to celkom zaujimavo a hlavne bezpecne.
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null
tokeny su zarucene momentalne jedina moznost ako ochranit stranku pred csrf
http://blog.synopsi.com/2007-12-12/najpopularnejsie-utoky-xss-a-csrf-na-...
a zaroven su velmi lahko pouzitelne
odporucam ich nasadit na kazdy web ktory si ceni svoju bezpecnost. este zaujimavejsia je vsak inicializacia na clien-side spolu so server-side. je to nateraz najbezpecnejsie co je
TommyHot:
nejako stale nechapem ako kontrolujes to userID, ostatne je mi jasne
sessionID , IP, user agent, x forwarder for, ale to userID.
pri prihlaseni sa zapise do db userID a potom ked ide na dalsiu stranku
skontrluuje sa sessionID, IP , usergent - to su udaje co mi klinet posle, ale to userID? voci comu ho kontrolujes ?
prosim mozes mi to trocha rozpisat ?
Ospravedlnujem sa s tym userID som sa sekol.. :)
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null