Bezpečnosť

Tak to je najsirsia otazka aku som kedy na tomto fore videl. Ved je to rozdielne podla toho aky jazyk pouzivas, co v nom vyuzivas, ci pouzivas databazu... je to tolko moznych aspektov, ze si to ani nevies predstavit...

Mas tam nejaky upload (avatarov alebo tak)? Alebo ako odosielas nove prspevky do databazy? Mas to naisto zabezpecene? Alebo nepredavas cez nejaky GET id-cka z databazy? Ak ano, pouzivas v pripojeni k databaze intval()? Alebo vlastne kde mas podozrenie (ak nejake mas), ze by sa to dalo hacknut?

Ako mi najlepsie poradite ako si mam zabespecit stranku pred hackovanim?
Naučit se pořádně programovat a přečíst si něco o zabezpečení :-)

Základní poučka bezpečnosti: Data dělíme na důvěryhodná a nedůvěryhodná. Data "zvenku", hlavně uživatelské vstupy, jsou vždy nedůvěryhodná. U nedůvěryhodných dat automaticky předpokládáme, že mohou obsahovat cokoliv. Nikdy se nespoléháme na to, že nedůvěryhodná data něco budou nebo naopak nebudou obsahovat.

Příklad klasické chyby:
HTML:PHP:Hodnota $_POST["id"] pochází od uživatele, takže je nedůvěryhodná. Skript spoléhá na to, že nedůvěryhodná data budou obsahovat ID číslo z databáze -> porušení pravidla výše.
Lepší varianta: -> $id už jsou důvěryhodná data

funkce addslashes proti sql-injection
http://diskuse.jakpsatweb.cz/index.php?action=vthread&forum=17&topic=92681&page=-1#13

ukázka, jak může být zneužit neošetřený vstup od uživatele vypsaný na stránku (anglicky, bohužel):
http://www.virtualforge.de/vmovie/xss_lesson_1/xss_selling_platform_v1.0.html
http://www.virtualforge.de/vmovie/xss_lesson_2/xss_selling_platform_v2.0.html

---

imploder
Tie videeka su uzasne. Ihned putuju do zaloziek.

Tak to mas potom malu sancu byt hacknuty - aj ked nic nie je nemozne...

o
„ziadny upload avataru iba adresa obrazku http... prispevky normalne zapisujem do db ale predtim su prekontrolovane cez htmlspecialchars()“
Senky
„Tak to mas potom malu sancu byt hacknuty - aj ked nic nie je nemozne...“
Možnost zapsat do stránky prvek (obrázek, odkaz...) obsahující libovolnou URL může být nebezpečná tím, že umožní tzv. Request Forgery - tedy, že útočník připraví přihlášenému uživateli URL, která když se načte tak provede v systému nějakou akci - prostě odkaz na určitou funkci systému. Třetí video je o tom: http://www.virtualforge.de/vmovie/xsrf/xsrf_attacked.html
Zabrání se tomu tím, že pro provedení nějaké akce v aplikaci (která by mohla způsobit škodu) se kromě autentizace uživatele ještě ověřuje kód. Ten kód se pokaždé vytvoří nový ke stránce, ze které se ta akce ovládá (např. jako skryté pole formuláře). Není možné pak akci u přihlášeného uživatele spustit nějakou nastraženou URL.
Nastražit URL ti někdo může teoreticky i na nějaké jiné stránce, takže když vyhodíš možnost zadat libovolnou URL (obrázku, odkazu), tak si tím moc nepomůžeš.
Taky když používáš jako klíč přihlášeného uživatele (SID ap.) místo cookies proměnnou v URL, tak tohle nehrozí.
U nekritických funkcí, jako třeba odhlášení z téhle diskuze to asi není potřeba moc řešit. klikni na můj odkaz (když klikneš, odhlásí tě to)
A někde (např. hledání) je naopak možnost ovládání zvnějšku přes URL žádoucí.

Je tam ještě čtvrté video: http://www.virtualforge.de/vmovie/forceful_browsing/forceful_browsing.html
Je nazvané "Forceful Browsing" - jde o to, že by se nemělo zabezpečení spoléhat na to, že uživatel nezná URL. Útočník ji může uhodnout a může mít bota, co to zkouší. Tak tohle je asi obecně známé.

o
To bohuzial nestaci (vid. predposledny bod).

o
„a co keby som len pomocou nejakej funkcie ktoru nepoznam kontroloval ze if(pismenka za bodkou){ array("jpg","png","gif") avatar=spravne } else { avatar=nespravne };?“
Jestli myslíš proti request forgery, tak to samo o sobě není dostatečné. Obecně může být URL na akci v tvojí aplikaci nastražená kdekoliv, třeba na stránce někoho jiného, na kterou uživatel přihlášený u tebe přistoupí a neštěstí je na světě. I když je to přece jen menší problém než když je něco takového možné přímo u tebe. Taky je možné, že tímto způsobem u tebe nikdo napáchat škody nemůže. Pokud se ale nějaká kritická (potenciálně zneužitelná) funkce spouští pomocí cookies+URL, pak bys určitě měl ještě generovat ty kódy, jak jsem psal. Je o tom myslím něco na rootu.

srigi - článek
Ten článek je vlastně taková ukázka postupů, které se použít nemají a proč. :) Ale zdá se mi ten závěr dost pesimistický:
Zdá sa teda, že je koniec naším obavám o bezpečnosť aplikácie. Áno aj nie. V závislosti od konfigurácie servera, je možné že sa objaví server (hosting), ktorý je nastavený tak, aby súbory s príponami gif alebo jpg boli predávané PHP parseru. Táto situácia môže nastať vtedy, ak nejaká aplikácia na serveri dynamicky generuje obrázky (rôzne grafy a pod.). Aj keď je takáto konštelácia hviez veľmi nepravdepodobná, nie je tu istota, že sa situácia na vašom hostingu nemôže zmeniť (a o tom samozrejme nebudete informovaný).
Nechci se hádat, ale myslím, že kdo takhle server nastaví, je idiot, a to i v případě, že se na něm pomocí PHP generují obrázky - není problém nechat takovému skriptu příponu .php - ledaže by záměrně nemělo být poznat, že je obrázek generovaný skriptem. I v takovém případě, pokud server dovoluje .htaccess, tak v něm se dá provádění skriptů v daném adresáři zakázat, bez ohledu na přípony. Podobně se dá třeba uvažovat o tom, že správce dá heslo roota třeba "ahoj" a to už vůbec nemáš šanci zjistit (jen pokud se tam sám nabouráš).