Je to urcite siroka tema, ktora sa asi neda popisat jednym postom, avsak zaujima ma, pred cim sa treba v dnesnej dobe chranit.

Ako chranite vlastne stranky pred ludmi, ktori sa snazia prelomit vstup do administracie?

nejake moje hinty:
- administratorske prostredie davat pod nejaku neobvyklu adresu (nie klasicke nieco.sk/admin a pod.) a bez moznosti prelinkovania z hlavnej stranky
- ak k administracii ma pristup zopar ludi, tak pri logine nacitat vsetkych userov z DB a potom uz len z inputov porovnavat nicky a hesla s datami v PREMENNYCH a nie priamo z DB. (samozrejme k tomu ochrana k brute force utokom)

Su to len nejake postrehy a rad si precitam, ze ci su to dobre riesenia alebo tiez sa daju jednoducho obist.(teda najst administracnu stranku resp. prihlasit sa na cudzie konto)

Bol by niekto ochotny popisat bezpecne uchovavanie 'lognuteho' usera v session? Je mozne aby niekto cudzi, bez toho aby bol jeho PC nalogovany v administracii, dokazal vytvorit taku session, ktora ho tam pusti (bez naburania DB)?

je toho strasne vela, no bud treba precitat hromadu webov ktore sa venuju bezpecnosti alebo pouzivat nejaky framework alebo rovno cms kde by mala byt bezpecnost na dostatocnej urovni pre take tie nase freelancerovske projekty

sharky-no napísal: - ak k administracii ma pristup zopar ludi, tak pri logine nacitat vsetkych userov z DB a potom uz len z inputov porovnavat nicky a hesla s datami v PREMENNYCH a nie priamo z DB. (samozrejme k tomu ochrana k brute force utokom)

toto je čo za kravinu? Keď nevieš ošetriť vstup, tak neprogramuj. Namiesto jedného riadku mám podľa teba načítavať celú tabuľku? Si sa zbláznil?

a inak dobre si povedal, nedá sa to obsiahnúť v jednom poste. Známich útokov je na stovky, pričom aj spôsobov prevedenia je neskutočne veľa. Z toho dôvodu je aj zaužívaných techník na tisíce. Väčšinu ich nabereš praxou, ostatné sa dajú naštudovať z rôznych kníh.

proti bruteforce je najlepšia ochrana captcha a časové limity medzi dvoma pokusmi o prihlásenie. Session sa ukradnúť dá, preto sa do neho okrem dát ktoré potrebuješ uchovávajú aj iné info (ip, prehliadač...) a porovnáva sa zhoda. Ak nesedí, išlo o krádež a sessien sa zruší.

odporúčam ti začať knihou zraniteľný kód od husebyho, je to rýchly prehľad pre začiatočníkov.

no tak jasne ze nebudem nacitavat stovky/tisice ludi.
myslel som skor take stranky, co maju pristup k administracii 2-3 ludia.. ale tak to je jedno.

a co sa tyka tych frameworkov, to je sice pekne, ze su lepsie zabezpecene nez klasicky kod, ale je mi to prd platne ked nebudem vediet ako a co mam kontrolovat, resp. nastavit. preto som chcel vediet tie zakladne techniky, popripade kde zacat.

no tie frameworky som ti dal prave ako jednoduchsiu alternativu =D (hlavne casovo) lebo byt zbehnuty v bezpecnosti znamena byt aj trochu zbehnuty v technologiach okolo, komunikacnych protokoloch, databa, webserver, samotne php a hlavne poznat a chapat zavislostiam medzi tym vsetkym, to sa do jedneho topicu zhrunut neda fakt to chce cas a treba sa o to aktivne zaujimat no a pri kodeni za pomoci tychto vedomosti rozmyslat nad tym ako by mohol byt kazdy kus kodu/funkcia zneuzitelna

no ale aj tak ti skusim dat nejake hinty, aby bolo jasno nepovazujem sa za nejakeho pro ohladne bezpecnosti ale snazim sa tomu venovat nech co nakodim neni uplne na smiach

alebo este lepsie skus napisat nejaky konkretny pripad ktory riesis, "zabespecenie pristupu" je taky trosku siroky pojem,

oddelovat login form pre userov od login formu do administracie a skryvat ho pod nejaky specialny link s bezpecnostou moc spolocne nema a vo vecsine typov webov (neviem co zrovna kodis ty) mi to pride dost user unfriendly, vzdy som nadaval ked som musel hladat v bookmarkoch link do administracie k nejakemu takto navrhnutemu webu, ovela dolezitejsie je si poriadne osetrit vstupne udaje (login,heslo) proti sql injection a nespravit v prihlasovacej logike nejaku kktinu

k tej session ako kolega napisal, da sa odchytit, ak je niekto medzi uzivatelom a servrom, asi najhorsi pripad pre usera a najlepsi pre utocnika je ked user je pripojeny cez nesifrovane wifi a utocnik je niekde nablizku, riesenie uz odznelo, znovu pisat sa mi to nechce

vvoody napísal:... asi najhorsi pripad pre usera a najlepsi pre utocnika je ked user je pripojeny cez nesifrovane wifi a utocnik je niekde nablizku, riesenie uz odznelo, znovu pisat sa mi to nechce

MITM ale nie je problém chybnej aplikácie. Ja ako programátor totiž nenesiem zodpovednosť za to, že nejaký servisák z orangu nevie klientovi nastaviť router. Ale nesiem napríklad zodpovednosť za krádež session cez XSS

no ono prave nejde o to kto nesie zodpovednost ale o to ci sa mozes alebo nemozes spolahnut na to ze tu session ide zachytit, kedze prakticky sa na to spolahnut nemozes nikdy tak treba zabranit tomu aby ta ukradnuta session isla pouzit

btw inak pekna vyhovorka ze servisak zle nastavil router, potom daj vediet ako si pochodil v orindži ked sa takyto problem stane a uniknu nejake citlive data alebo co ja viem co... ale zasa na druhu stranu niekde som cital ze v tomto state je vsetko mozne =D tak mozno aj ty uspejes a nakoniec zobere na seba zodpovednost ten servisak

aha, čiže ja ako programátor musím chodiť pravidelne pozerať aj server či niekto nevykradol serverovňu a nezkopíroval si session z disku, musím sa starať o sieť každého klienta ktorí pristupuje na moju stránku, musím.. sa spamätaj trošku. Ak niekto odchytí komunikáciu, je to problém obete že má zlé pripojenie, nie mojej stránky čo som naprogramoval. Moja aplikácia komunikuje podľa obecne uznávaných štandartov. A útočnik odchytením session napadol obeť, nie moju stránku a ostatných registrovaných a prihlásených. Takže áno, je to jeho chyba že sa pripája na stránku nezabezpečenou formou niekde v kaviarni alebo si nevie nastaviť router. Ja ako programátor s tým absolútne nič nemám. V kode chyba nie je. A okrem toho, MITM útoky nespočívajú v krádeži session. Keď sa ti už niekto dostane na sieť, tak to stránka alebo aplikácia vôbec nedokáže detekovať. Čiže proti tomu ani nie je možná sw ochrana na strane mojej aplikácie. Jediná možnosť je zabezpečenie siete

okej tak nenaimplementuj zopar bezpecnostnych prvkov naviac, usetris cas a mozno ten cas zasa stratis dohadovanim sa s hormadou napadnutych uzivatelov o tom kto mal aku zodpovednost a mozno nebude napadnuty ziadny ked budes mat stastie

keby ebanka komunikovala pomocou tych tvojich "obecne uznávaných štandartov" tak by si narobila pekne vela problemov a ta za taketo veci teda rucit musi

pozri ja ta nenutim robit nieco naviac, ak uzivatelia tvojho webu poznaju rozdiel medzi sifrovanou a nesifrovanou wifi, alebo ak ich mas uplne na haku tak budiz, je to len tvoja vec aku uroven bezpecnosti budes uzivatelom garantovat, o tom kto nakoniec spravil chybu sa mozes ist hadat s uzivatelom a ked si neda povedat tak ta dotiahne aj na sud...

tak prosimta nechaj nas sa tu bavit o bezpecnosti a jej implementacii a nechaj zodpovednost stranou, to s programovanim nema nic spolocne

jo a MITM ked sa nepletiem je ten pripad ked utocnik moze modifikovat komunikaciu, pri tej nezabespecenej wifine v kaviarni moze utocnik komunikaciu len odpocuvat (uvazujeme ze pristup k routeru nema), nemoze zabranit doruceniu povodneho paketu aby mohol podstrcit uzivatelovy jeho nakazenu modifikaciu, no MITM a odchytenie session o ktorom sme sa povodne bavili neni jedno a to iste

Ja davam za pravdu audiotrack-ovy, naco by robil zabezpecenie ako ma banka na forum kde su recepty na varenie.

A vsoubecne plati pravidlo sw inzinierstva:
Preniknutie do systému by malo byť drahšie ako informácie v ňom. ( Respektíve zabezpečenie nemalo by byť drahšie ako informácie v ňom.)

znovu to napisem, debata bola o bezpecnosti, nie o urceni zodpovednosti a ani tu nepadlo jedine slovo hodnote informacii pod takym ci onakym zabespecenim...

ano, mas jednoznacne pravdu, je uplne kontraproduktivne vytvarat zabezpecenie na urovni ebanky pre "online kuchařku", tam sa s takymi vecami netreba babrat, kto by mal zaujem napriklad na odcudzenie alebo zmazanie databaze takehoto webu, ale druha vec je zase kto by sa dnes preboha babral s kodenim takeho radoveho obycajneho webu? Rozbehanie a upravenie nejakeho cmska (ktore zvykne byt po bezpecnostnej stranke dobre nakodene) do podoby "online kuchařky" zabere ovela menej casu ako to kodit riadok po riadku aj ked uplne bez riesenia nejakej bezpecnosti

celkom pekny sposob pre admine je zabezpecenie cez HTTPS a login http://php.net/manual/en/features.http-auth.php s osetrenim vstupov na sql injection + niaky ban list

sorien: HTTP autentifikacia je sice jednoducha ale velmi sa nepouziva, pretoze prehlaidac si pamäta prihlasovacie udaje pokedy ho nevypnes a je dost tazke tomu zabranit (zmazat ich), navyse tie udaje odosiela pri kazdom refreshy stranky a s tymto typom prilasenia sa neda pouzit AJAX (rozumne).
Bez SSL HTTP Autentifikaciu nikdy nepouzivaj !!!