ochrana $_POST

Čavte... chcem sa opýtať či na zabezpečenie $_POST stačí niečo takéto :

pokračuje to ďalšími napr. $gtim2,3, atď a potom

relativne áno.
Ale záleží čo s tým robíš, ak máš nejaký formulár a tak...tak je tu vysoké riziko útoku CSRF, hoci je dobre že používaš radšej POST ako GET, (dobre proti tomu druhu utoku) tak môže to byť aj o tom, že niekto si spraví formulár a pošle ti tam iné hodnoty.

takže v podstate môžeš to zabezpečiť proti napr. vloženiu script kodu (htmlspecialchars) ale tých rizík je nespočet.
ja som si tiež donedávna myslel ako dobre to mám zabezpečené,
dokial som nezistil že v pohode si to prepíšem iným formulárom.

teda ak si sa pýtal na toto, všeobecne. čo sa týka tej kontroly na čísla to je ok, aj tie htmlspecialchars atd.

B.A.X.O : ako myslíš, že prepísať iným formulárom ?

ja len ťa upozorňujem na CSRF, aby sa ti nestalo že máš takýto formulár s php ktorý ho spracúva:



no, súbor sa volá napr. lol.php, niekto si pozrie aha takže on takto posiela data hmm...
spraví si súbor napr. attack.html, a donho umiestni tento html form action formulár:



po odoslaní, tohto formuláru s cudzieho suboru ti prepíše hodnotu $_POST['hodnota'] a tým padom ti odošle na form nechcenú hodnotu:)
v prípade že to potom niekam ukladáš, dostaneš podvrhnuté hodnoty.
toť príklad na použitie CSRF.

ide o najbežnejší útok na webe, a snad aj najhorší lebo je kvalifikovany v podstate ako bežný request, a brániť sa proti tomu nie je zrovna lahké.

ako sa dá proti tomu zabrániť ?

bráni sa proti tomu veľmi ťažko, v podstate dve také najpriamejšie možnosti sú:

1. tokeny
2. overovanie

overovanie spočíva v tom, že pri odosielaní POST dát, sa spýtaš či skutočne chcete túto akciu vykonať, to nemá útočnik jak obísť, takže toto je prvá možnosť
ale to sa hodí skôr v administrácii a tak, lebo pýtať sa pri registrácii "chcete sa skutočne zaregistrovať?" by bolo asi trošku odveci...

tokeny sú známe, budeš generovať náhodné reťazce a čísla najlepšie pomocou troch funkcii, a to md5, uniqid, a rand. a potom overovať, či to súhlasí, zároveň je to aj o tom že token je na jedno použitie...potom stráca platnosť a viacej sa akcia pre ten token končí.

doporučujem prečítať články o Cross site request forgery(CSRF), je toho velmi vela...ako som povedal,
obrana proti tomuto 100% neexistuje. ide iba o to, čo najviac to útočníkovi sťažiť...

no ono to je celé v administrácií.... má potom zmysel overovať ešte aj takéto formuláre ?

no pozri...celé to závisi od toho, že takto ta nemôže napadnúť hocikto.
ak mas toto v administracii, co predpokladam ze mas osetrene admin pravami a loginom, tak takto ta nikto napadnúť zvonku, ani z user uctu nemôže.
pointa tohto utoku je v tom, že ta niekto napr. skontaktuje a ukaze ti nejaku stranku ked ty budes prihlaseny v administracii. ty tam prides, ale nebudes vediet ze to odkazuje do tvojej administracii aby to tam nieco napr. vymazalo takže - tam prides, a utočník skrz teba infiltroval tvoju administraciu.
o tomto tento utok je. to isté aj z usermi obycajnymi.

a taky link sa da skryt vážne dobre, iframe, obrazky atd..proste ta to hned nenapadne alebo na to vobec neprides. a ked tak uz je neskoro

ok.... inak ale robím fakt malý a veľmi úzko špecificý web, takže až do takej hĺbky to zas nemusím mať zabezpečené ) diki

Pri čítaní tejto témy ma napadla jedna moja skúsenost.

Hravam online hru travian a raz som si vytvoril HTML subor, ktory vyzeral asi takto:



...mal ma automaticky prihlasit...

a hned pri nacitani stranky som tento formular javascriptom odoslal...,
ale nefungoval mi...

Patral som a dopracoval som sa k zaujimavemu rieseniu ochrany dat. Cely system spocival v tom, ze nazov pola kam pisete meno a heslo sa pri kazdej navsteve stranky menil. Pravdepodobne to riesene pomocou session (relacií) a php. Potom som to použil aj na mojej stránke.

Kod vyzera asi takto:

...no a teraz nasleduje php skript, ktory ziska meno a heslo asi takto:

..a nasleduje pokracovanie skriptu, ktory vas prihlasi...

A bezpecne prihlasovanie je na svete...

Neviem ci ste to pochopili, mozno sa to zda tazke, ale kto ma nejake skusenosti s PHP urcite to zvladne...

Toto riešenie, nie je podľa mňa múdre.

Mozem vedet preco?

a aka nechcena hodnota by to mala byt? sak to je ten isty formular len na zaciatku bude v tom inpute hodnota 400 predsa nechapem co si tym chcel poukazat..
a ked sa niekde prihlasujes tak sa ti ma brat hodnota z ineho suboru alebo databazy a porovnavat so zadanym hadam

B.A.X.O poukazoval iba na to ze si hocikto moze vytvorit formular na svojej stranke a posielat to k tebe. V podstate je ten M1rcO_ov formular bezpecny pretoze nech formular odkazuje odkialkolvek vzdy prejdu autentifikaciou len cisla.

aspoň ako ja počúvam, tak sa to rieši obvykle tokenmi s platnosťou.
to znamená že to nezastaví útok na 100% ale napr, keď nastavíš platnosť desať sekúnd, a je tam token ktorý sa mení, tak útočník musí zakaždým token okopírovať, nemôže to nijak inak lebo je tam vždy iný, kym to nakopíruje do toho form actionu, uloží, tak čas vypršal...no ono to nie je 100% ochrana, ale ja mam niečo podobné...

inak juho, a registracny form ta nenapadol? tam budem odkial brat udaje? neviem čo sa ti nevidí...prečítaj si niečo o CSRF než ti niekto zloží web.
podstata toho je v tom, že keď dám všetko tak isto ako overuje PHP subor, aj meno submitu tak sa to kvalifikuje ako normalny request:)

a nemení to nič na tom, že ked už tam má ten is_numeric tak budem posielať len číselné hodnoty:) to dalej môže ošetriť povolenými miestami, na napr. dvojciferné číslo...

žiadna ochrana nie je 100%, proste je to jeden z najhorších útokov. to ja som raz vymýšlal, že by som po odoslaní presmeroval na jeden s petice suborov, a odtial zas na dalsiu peticu ktora uz by vykonala to co ma, pricom s tej prve petice by sa presuval vykonavaci kod do tej druhej...
to znamená že útočník by nevedel čo tam má prepísať, dostával by sa na súbory náhodne a velmi ťažko by sa na to prišlo...zvlast po tom co by som tam dal htacces s blokovanim tychto suborov.
(ale tento sposob bol spojeny s jednym ajax kodom, normalne by to bolo asi zbytocne)

neviem no, raz možno niekto príde s nejakým prevratným riešením.

tokeny s platnostou su riadne nechutna zalezitost Vzdy treba citlivo pristupovat k hranici medzi bezpecnym a pre uzivatela prijemnym webom. Tokeny s platnostou par sekund su hodne daleko za touto hranicou prijemneho pouzivania. Web bude bezpecnejsi, ale neustale hlasky o neplatnych tokenoch kazdeho otravia.

Kto nasiel sposob ako prelomit moje zabezpecenie nech sa ozve. Zagratulujem mu. Mne sa to nepodarilo ani raz...

Neruzumiem preco dynamickemu priradovaniu nazvu pre fieldy na stranke hovoris ochrana
A nerozumiem co na tom chces prelomit. S bezpecnostou to nema absolutne nic spolocne.

no sak to vie predsa kazdy ze si moze vytvorit postovy formular a posielat ho kam chce, to neje ziadne tajomstvo takze neviem co sa natom tak vzrusujes
sak to aj je normalny request ocom ty pises ja ta nechapem sak to je normalne predsa nato su formulare aby si nemusel chodit na tu stranku a vsetko nacitavat spravis si vlastny a mas to rychlejsie. a ak chces aby to mohol zadavat len "na tvojej stranke"(pretoze html kod sa stahuje vzdy ku klientovi az si to nevedel) tak do toho php kodu pridaj este podmienku ze po submite bol presmerovany z tvojej url adresy ale aj tak ti to je nanic pretoze kludne po nacitani si mozes do navigatoru napisat nieco ako a mas ten isty formular(podla teba ten nepravy)a v hlavicke si presmerovany z toho tvojho formulara tak nechapem ze co teba natom vzrusuje... na tomto nieje nic nebezpecne

HTTP referer ti obídem za pár sekund addonom do firefoxu, konkretne RefControl




ale ja som to dal ako príklad:) môj token môže mať platnosť tak 30min, tak snáď keď už user na ten form príde, tak snáď ho aj odošle, a nebude čakať 30min dokial vyprší token...to je potom odveci, za to si môže sám.

sak ked prijmas udaje od usera tak isch treba poosetrovat..napr ked je tam policko tel cislo tak kontrolujes ci obsahuje iba tie znaky ktore ma obsahovat nie? tak to je asi najlepsie alebo sa mylim? ked mas udaje na meno tak po odoslani kontrolujem dlzk ua ci odoslany obsah obsahuje iba povolene znaky neviem zatial zeby niekto mal v mene znaky ako <>'!: atd..

nie to nieje to.
to ma byt nieco take ze ty si vytvoris web s prihlasovanim uzivatelov a s funkciami ze uzivatel si moze mazat nieco (napr: vlastne prispevky).
tento uzivatel sa prihlasi na tvoj web pomocou session napr. no a teraz ta hlavna vec ze z nejakeho dovodu ten prihlaseny uzivatel medzitym jak beha po tvojich strankach navstivi este ten utocny web, ktory je zamerany robit skody na tvojom(uz to je pravdepodobne jak styri svine) a na tom utocnom webe by mal byt nejaky skryty iframe aby ho ten "oklamany" uzivatel nevidel ktory by odkazoval na tvoju stranku pricom by mal vymazat nieco. a to si vyzaduje aby ten co robil ten utocny web poznal funkcie tvojho webu ako napr: mazanie prvkov co znamena ze ten co robil ten utocny web namiereny proti tvojmu musel sa uteba zaregistrovat a zistit ako to tam funguje.
a teraz spat k tomu iframeu:
ten by mal v sebe az mas to mazanie spravene cez potvrdzovaci formular form s action="wewewe.tvojweb.com/.../prvky.php?vymaz&id=5" a metodou post a tie prvky co sa postuju a este tam odoslanie formulara najskor cez js document.form["formular"].submit() a az to mas len cez odkaz alebo get tak ten iframe by odkazoval na wewewe.tvojweb.com/.../prvky.php?vymaz&id=5
pricom ten uzivatel by musel mat platne prihlasovacie session z tvojho webu.

gratulujem juho, niekto si tu prečítal článok Jakuba Vrány o CSRF...
ale hlavne že už si tomu pochopil

keby si cital prispevky co som napisal tak by si vedel ze ja som to chapal odzaciatkulenze ty si to asi neprecital...
to je viac teoreticka vec nez prakticka takze tak..
a IE teraz by to mal uz zablokovat pretoze IE teraz uz blokuje uplne vsetko.
a ine prehliadace by mali mat voci takemu niecomu tiez ochrany takze si uplne vedla podla mojho skromneho nazoru.

odmietam sa tu s tebou hádať juho. Ako môžu byť prehliadače voči tomuto odolné, ked je to v podstate normálny request? ty si asi slepý, neviem kto nečíta čo ja píšem...keby boli voči tomu browsre odolné, ani to tu nespomínam...

tento príspevok konkretne:


značí že si to pochopil? neznačí, tak sa nediv že ti píšem čo ti píšem.
až teraz o dva prispevky vyššie si konečne vystihol podstatu CSRF.
inak ja sa ospravedlnujem ak som prehliadol niečo čo si napísal, ale ja som sa ti aspoň ospravedlnil a priznám si to.
kdezto ty klepes jedno cez druhe, ako rezne...a nepriznas si to.

ked tomu neveris a myslis si ze mas pravdu tak dokaz co tvrdis.
napriklad na pcforum: sprav stranku aby to zmenilo uzivatelovu emailovu adresu... na trebars xxx@xx.xx a aby to bolo funkcne aj ked nikomu nenahovoris aby si otvoril nejaku stranku(" tu co spravis ") co vobec nepozna a pritom aby mal aktivne session pre prihlasenie na pcforum.
a az to nedokazes tak potom je zbytocne tu strasit ludi niecim takym ako je tamta zalezitost.
az to dokazes tak potom mas pravdu ty a to uz nikto nebude moct vyvratit

juho
Pozri na http://djpw.cz/100283, phpBB ma proti tomu obranu (vyzaduje sid), niektore ine systemy nie. Ak si system nedokazes zabezpecit dostatocne (vyzadovanim http_referera alebo nejak inak), hocikto ti moze podvrhnut takyto formular a narobis si skodu.
To s tou odolnostou prehliadacov som tiez nepochopil.

ono toho ma aj viac a pre zmenu emailu vyzaduje dokonca aj hesloa take nieco ako vybrat hodnoty cez iframe nepozname ze .. no tak na nejakom inom webe teda mne natom nezalezi...

a este doplnim co som pisal uz predtym, ale teraz to nieje odomna .
: cross-site-request-forgery útok na webovou aplikaci je možný,jen pokud oběť navštíví útočníkovu stránku, která odešle předem připravený formulář (např. akce typu „smaž vše“).
: Útočník musí znát webovou aplikaci. Musí připravit formulář s akcí, která se provede, až oběť navštíví útočníkovu stránku.
: Útočník musí oběť nějak přesvědčit, aby navštívila jeho stránku. Asi nejjednodušším příkladem je e-mail s odkazem a textem: „už jsi viděl dnešní vtip na mém blogu?“
a este neviem preco to tam nieje zdoraznene pretoze to je ta najdolezitejsia cast
: Útok totiž proběhne z prohlížeče oběti (která je přihlášena do aplikace) a odeslání formuláře směřuje do aplikace oběti (do které je oběť přihlášena). (musi byt aktivne prihlasena a to tym emailom asi nedosiahne ze by poslal postou pozri si ten vtip ale najprv sa predtym este prihlas na tento web dakujem za dodrzanie instrukcii)

az sa toto niekomu podari tak obeť si priamo ziada aby bola oklamana. a aj tak to stale nieje utok ako taky na web. pravdaze az ta obet nieje administrator, ale aj tak by utocnik musel poznat jeho system. ale je to utok nanajvys na konto uzivatela.

Nepozname, neda sa to, nemozes sa rypat v strome dokumentu na cudzej domene.
Kazdopadne, nemas pravdu v tom, ze je to viac teoreticka ako prakticka zalezitost. Vacsina amaterskych aplikacii sa proti CSRF vobec nebrani a ozaj nie je tazke podvrhnut prihlasenemu uzivatelovi odkaz (kludne moze utocnik pouzit trebars tinyurl), staci vediet, ako ho donutit na to kliknut, a ver mi, nie je to tazke.

a ešte, čo sa týka ochrany, keby som povedzme spravil v DB tabulku s ID,HASH,TIME a vždy pri vstupe na formular by sa vygeneroval riadok a potom sa do formulara dali hodnoty

a potom následne by som overil že či hash zodpovedá ID a že či je ešte platný na základe času?
poprípade tu ID posielať v adrese