Zabezpečte si své stránky pomocí PHP!

...mam zopar malych pripomienok:
1. chyba v config.php mazanie expirovanych userov - tabulka by sa casom hrozne nafukla

2. posielanie mena usera, aj ked v zakodovanej forme je, slusne povedane, nerozumne. Mal by sa posielat nahodny retazec asociovany s danym userom

3. ten parameter v URL s nazvom "a"...sorry, ale taketo nazvoslovie sa nepouziva ani a alfa veriach

4. chyba asociacia s IPckou usera. Ak niekto zachyti dane URL, staci ho napisat do URL a je dnu. Viem ze aj IPcka sa da sfalsovat, ale nie je toho schopny kazdy puk.

Asi tolko - je to celkom slusny pokus, len ho treba dotiahnut.

Michal Ukropec

Nemohl by ty clanky o PHP psat nekdo, kdo PHPko umi a uz v nem nejakou dobu dela? Zajimal by me styl a finty takoveho cloveka v jeho kodu.

Protoze to co predvadite na Zive - nekdo se uci PHP a v clanich se chlubi svymi "uspechy" je podle mne na nic.

Misto nauceni se toho, jak se to ma delat se jenom replikuji pripadne chyby mezi dalsi zacatecniky! Blueeeeeeeeeee

tak mi pripada ze autor se uci nejenom PHPko, ale i praci s databazemi, ale este se nedostal moc daleko :). pouzivat typ text na uchovavani jmena a hesla je ponekud luxus (text muze obsahovat 64kb textu), ale jinak me clanek nicim neprekvapil, obvykla kvalita clanku na zive o neM$ technologii :o))

typ text pro uchovani uzivatelskeho jmena hesla je podle meho nazoru v poradku, protoze do db se zapise pouze pozadovany text a za nej se nezapise nic jineho, davam tim prostor pro jakkoliv dlouhou delku uz. jmena nebo hesla.

no, ono to neni tak pravda... sice se za nej nezapise nic jineho, ale pouziti typu text zpomaluje pracu s databazou, protoze pokud by byl rekneme pouzit typ CHAR (nikoli VARCHAR) tak server pri hledani dat vi, jak dlouhe polozky tam bude mit a muze si presnou polohu presne vypocitat... ovsem pokud se pouzije TEXT (nebo VARCHAR) tak server musi projit data aby vypocital, kde vlastne dana polozka konci a kde zacina dalsi...

ale jinak souhlasim s ostatnimi komentari, ze se jedna spise o praci nekoho, kdo se s PHPcky teprve uci a okoli inforumuje o tom, co vlastne se prave naucil ;)

Já bych byl spokojenej, kbyby tam byl alespoň VARCHAR !!!!!!!!!!!!!!!!!!!!!!!!!!!   Text (já) používám jen na dlouhej text. Navíc už vidím frajér a s loginem o velikosti 'text'. Hmmmmmmmm, ale jak chce. Chybama se člověk učí a tendle to potřebuje jako sůůůůůl. PS: Stále čekám na něco originálního...... :o(((

Ale nenech se rušit piš dál ten honorář je za to určitě slušnej, ale jsem si jist, že bych měl poctivěji vydělané peníze (jako programátor nebo redaktor).

1. Tento clanek pekny pro zacatecniky, akorat vidim nedostatky v tom ze autor asi moc neoptimalizuje dotazy, protoze si myslim ze sekvence
----------------------------------
$vysledek=mysql_query("select * from users where login='$a'");
if (MySQL_Num_Rows($vysledek)=="0") {
Die(Header("Location: index.php"));
}
--------------------------
je ponekud podivna, kdyz to lze optimalneji napsat select count(*)...

2. Druhy problemem je ze autor neuziva funkci mysql_free_result, ktera je bohuzel casto opomijena, ale ze zkusenosti vim ze vede ke zrychleni provadeni phpcka, protoze se pri kazdem dalsim dotazu neotviraji nove spojeni na SQL server. Samozrejmne tento problem je markantni u tech skriptu kde je vice dotazu najednou.

Vladimir Helesic

Ten clanek nestoji pro zacatecniky za nic, protoze pak budou vsichni programovat jako autor, to znamena neefektivne a bez uvahy nad bezpecnosti toho, co z nich vypadne, protoze to, cemu se tam rika zabezpeceni je spis k smichu.

asi taq - po precteni tohoto prispevku me popad zachvat. At uz z SQL (i z DML i z DDL), jak ho "autor" vytvari .. tak i ze zpusobu "ochrany". Kodovat hesla pomoci StrTr() ??!?! A co treba MD5 ? Jednosmerny sifrovani je mnohem securejsi. Sem zdesen, ale na druhou stranu se tesim na vsechny takto zabezpecene stranky.

jo a jeste neco - na autorovi obdivuju, ze pouziva komentare :)))
Jinak vzhledem k ucelu clanku (mel by NAUCIT) by tam asi mel byt komentar k vetsine radek ...

Jsem rad, ze mate dobrou naladu z meho clanku, ale musim se Vas zeptat, jak jste obesel ochranu meho skriptu, ktery jsem uvadel v clanku, protoze mne se to opravdu nepovedlo. Ano, jde to i pomoci MD5, ale to je pouze vec nazoru, jak chcete sifrovat. Pochybuji, ze dotycny nejak zjisti, ze prikazovou radkou predavam zmenena pismena uzivatelskeho jmena a i kdyz je pripadne zmeni, tak ho to hodi na dalsi stranku

... ono zavisi na konkretni aplikaci. Zpusob obejiti StrTr a nekterych jednodussich zpusobu kodovani samozrejme existuje; Stejne tak se Vam samozrejme dostanu do stranek chranenych MD5 (mam-li cas a technicke prostredky); Je treba vyuzivat nahodnou redundanci (ok, samozrejme, tam, kde jest to treba

konkretne ve Vasi aplikaci existuji take zadni vratka (ale musite myslet trochu jinak

Kódování přes StrTr není kódováním. Kdokoliv vám takto předávané parametry jednoduše rozkóduje. Stačí si s tím trošku pohrát. Tento kódovací mechanismus postrádá základní bezpečnostní prvek - nesnižuje redundanci původního hesla. Tj. když v hesle změním jedno písmeno, změní se mi také jedno písmeno ve výsledku. A přesně vím, které za které.

ja sem asi uplnej magor , ale vzdy zasifruju MD5 a provedu zamenu znaku (proti slovnikovejm metodam), pak vsechny predavane parametry zabalim base64 (abych neukazoval co posilam za promenne) a pak tenhle retezec znovu zprehazim zamenou znaku (pak je slozite ho rozkodovat i kdyz znam casti retezce - treba svuj login ci jiny ptakoviny...) a snazim se ho poslat (pokud mozno) nejak co nejmin viditelne . Aby toho nebylo dost, tak pred rozkodovanim tohoto desnyho retezce jeste smazu vsechny (pokud mozno) promenne, ktere v tom retezci cekam
S oblibou pouzivam platnost retezce -> zabalim tam informaci o aktualnim case a pri rozkodovani akceptuju vyhradne povolene rozmezi casu (5 az 10 minut dopredu i dozadu).
Ve formulari pro login si jeste hlidam, kolikkrat bylo heslo zapsano spatne -> kdyz uz na desaty pokus neproslo, tak zablokuju ucet (opet ochrana proti slovnikovym metodam) a odesilam uzivateli odblokovaci odkaz, ktery ma jedinecne (nahodne vygenerovane) cislo, ktere souvisi jen s timto uctem (s tim zablokovanym) a nelze jej pouzit znovu (hlidam si to v databazi). Muze mit taky omezenou platnost, ale to se obcas hodi a obcas ne...

Zcela zasadne nezasilam hesla do mailu, ale jen (podobne zamuchlane) odkazy na nove zadani hesla - zde povazuju za nevyhnutelne (!!!!) aby takovy odkaz mel omezeni na jedno jedine pouziti (opet nese cislo, ktere se po provedeni akce zmeni a zapise do databaze - tim se nemuze pouzit znovu). Omezena doba platnosti tu (podle me) vyznam ma (..? nicmene to casove omezuju).

Taky hlidam heslo, ktere user zadava, aby to nebylo stejne jako jmeno, nebo otocene jmeno, nebo prazdne heslo atd... Ale po pravde receno... i kdyz jsem presne a do detailu napsal co je na prave zadavanem heslu spatne, tak se mi stavalo, ze jsem usery otravil a nedoslo k dokonceni registrace... takze smele muzeme rici, ze "kdo chce kam, pomozme mu tam..." tedy asi usery nebudu nadale obtezovat tim, ze jejich heslo je prilis ___ (misto podtrzitek doplnte prislusny duvod).

Mimochodem pohled do logu apache je fakt roztomiley )

Mam na to vzdy predpripravenej kod, kterej includuju na zacatek scriptu, takze staci si stim pohrat jednou (pro konkretni aplikaci pak to jen includovat).

Na druhou stranu, i kdyz pouzivam vsechny tyhle prvky soucasne, tak vzhledem k tomu, ze pro FBI nepracuju, tak to asi nema moc smysl...? To sem jeste zvazoval, ze bych mohl kodovat obsahy databaze, ale nejak jsem na to hodil bobek, paac bych musel moc premejslet pri sestavovani vhodnych SQL dotazu abych nemusel pretezovat databazi zbytecnymy vubery vsech dat...(pochopitelne ). Koduju jen obsahy tam kde to je "nutny" a kde neublizim rychlosti...

Uff!

Po cigarku a nekolika pracovnich ukonech mi doslo, ze bych mohl jeste doplnit duvod k omezovani casove platnosti nekterych odkazu:
   pokud se nam user prilogoval a my jsme mu dovolili pristup, ale z nejakeho duvodu je nevyhnutelne, abychom zasilali nami zamuchlany retezec (obsahujici rozlicne informace pro cilovy script - tedy vcetne pristupu), pak hrozi riziko, ze userovi nekdo odchyti jim zadavane url dotazy na stranky. Tim padem jsme nekomu cizimu umoznili pristup ke scriptu obeti (neboheho usera) aniz by vterka rozumel tem predavanym hodnotam. Toto riziko je tim vyssi, ze existuji pristupy pres rozlicne proxy servery, ktere loguji. Existuji i systemy pro analyzu webu, kde muzeme z referrerů tyto pristupy ziskavat. Pokud se jedna o system, kde je mozno zasilat odkazy na prvky umistene mimo server, kde se osoba nachazi (napr. webmail - pred casem objevila nejaka takova aferka na jednom z nasich verejnych webmailu), tak zlotrily root prislusneho serveru, kde lezi ten odkazovany objekt (napr. obrazek) opet muze sledovat referrer a ziskat pristup...

Pokud tak neucini do 5 az 10 minut, tak pristup jiz neziska! Pokud se ale na nekoho preci jen zameri, aby prstup ziskal, pak je vhodne, aby tento server rozlisoval hesla pro zapis a pro cteni. Pokud nam nekdo cizi neco precte, pak to fakt neni dobry! Ale pokud nam nekdo neco zmodifikuje, pak to muze byt prusvih!! Pochopitelne tim naznacuju, ze odesilani odkazu, dovolujicich zapis, je neco naprosto nepripustneho!!! Je treba to za kazdou cenu obejit...(za kazdou..?)

Pokud tedy dojde k (bezne) situaci, kdy potrebujeme prenaset heslo pro zapis, pak povazuju za vhodne, pouzivat "per session cookies" - tedy radeji ne cookies s trvalou platnosti. Nemam do vsech detailu probadano jak pracuji session promenne (za coz se stydim, ale prisly mnohem pozdeji nez moje navyky v PHP, takze je teprve mam na musce... ), ale pokud se jejich obsah bezpecne vytrati po uzavreni konkretni instance browseru (user muze necekane prerusit tok drive nez sessions sami bezpecne vyprazdnime), pak samozrejme mohou splnovat vyse popsane (me soukrome) pozadavky.

Pokud nekomu jdu po krku, tak si obvykle predpripravim disketu, ktera obsahuje ruzne zlocinnosti, ktere v nestrezenem okamziku provedu na pocitaci obeti a vycucnu co me napadne (vcetne cookies - kazdopadne ale ne "per session cookies" - to snad ani nejde..?) a to podstatne drive nez se vycura

Kdyz nekoho napadne doplneni poznatku, ktere jeste v teto diskuzi nezaznely, tak je prosim zaznamenejte, paac se nam vsem skutecne mohou (ve vhodnou chvili) hodit.

a co mysql_pconnect(); ?

je fakt, že je to jak vystřižený s knížky od Kostka.
Problémy s napsáním nejbezpečnější autentifikace řeším poměrně často, myslím, pokud nechci nebo nemohu používat zabezpečený protokol (třeba SSH), je stejně každé takovéto zabezpečení prolomitelné. Ovšem, autorovi doporučuji naštudovat sessions, s nimi to jde mnohem lépe a jednodušeji. Viz. třeba má autentifikace pro on-line aukci http://malujeme.astone.cz.

COSTRA neumi pravopis a uci se radeji od druhych a ma rad WEBZDARMA

ja bych se autentifikaci zrovna nechlubil - to si vzdy koleduje o prusvih (a krom toho samochvala vzdy hrozne smrdi

sorry, ale tohle musel napsat naprosty debil !!!!

sice se ted php zacinam ucit ale to co vyplodil autor je fakt sila. kdyz sem trochu studoval bezpecnost php skriptu tak se mi zalibily sessions a myslim ze sou fakt super (PHP4), logovani provadim pres heslo zasifrovane pres md5 ale ssl sem zatim nezkousel.

O otázce výběru správné metody zabezpečení zde bylo napsáno dost, mě spíše zarazila jiná věc - pokud je stěžejní téma zabezpečení stránek a pro začátečníky, proč je kód zasviněn takovou zbytečnou spoustou tagů pro formátování textu? Vždyť to má být základní kód a každý si to upraví dle svého. Navíc nejsem profík, ale použití tagů font mi přijde již hodně zastaralé a navíc rvát tam ještě tabulku pro dvě řádky textu - no každého věc, ale divím se že tam ještě autor nepřidal nějakou flash .

Moc se mi líbí, že autor tento článek vystřihl z netu a pak přeložil "některé části" skriptu. Jen tak dál, jde to dolůůů.