Vlastní systém – zabezpečení obecně

netbrana

(14 hodnocení)

12. 2. 2014 15:16:10

Dobrý den,

plánuji vytvořit vlastní systém který musí být extrémně bezpečný. V tuto chvíli mám pro přístup do backendu vyřešené:

- SQL injection

- XSS

- Brute force atack (captcha, omezený počet pokusů o přihlášení)

- Heslo je v databázi doplněno o bezpečností klíč (pepper) a hashováno v md5.

- Srovnávají se osolená hesla (sha1 nebo sha256)

- Systém vyžaduje aby heslo mělo velké písmeno, malé písmeno, číslo a minimální počet znaků aby byl 8.

- Omezení přístupu jen na IP z České republiky (je v plánu, nemám hotovo)

- Nemohu bohužel nasadit SSL certifikát (sdílený hosting)

navíc po přihlášení bude uživateli e-mailem odeslán unikátní ověřovací kód který bude muset zadat do dalšího formuláře jinak se do backendu uživatel nedostane (říkáme tomu druhý stupeň ochrany).

Celý backend poběží na jiné doméně než frontend a bude blokován přístup vyhledávacím robotů.

Všechny přístupy se budou ukládat do logu.

Myslíte si že takové zabezpečení je dostatečné pro oblast která bude obsahovat opravdu hodně důvěrné data?

Napadá Vás jaké další bezpečnostní rizika bych měl podchytit?

Děkuji všem :)

PZN: nechci žádný framework (veřejně přístupný otevřený kód), nejsem paranoidní :)

12. 2. 2014 15:16:10

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995749

(22 hodnocení)

12. 2. 2014 15:28:52

na duverna data je zakladem cislo jedna SSL

12. 2. 2014 15:28:52

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995748

netbrana

(14 hodnocení)

12. 2. 2014 15:30:59

Zrovna jsem chtěl doplnit: Abych to upřesnil, šifrované spojení zde bude ale certifikát není od uznávané certifikační autority. :)

12. 2. 2014 15:30:59

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995747

t-pack25

12. 2. 2014 15:33:08

Keď už pri hashovaní používať SHA, tak rovno SHA512. Zároveň bez SSL to nikdy nebude moc bezpečné, riziko odsledovania komunikácie tu vždy bude. Ja by som aspoň prihlasovanie zabezpečil týmto spôsobom

PHP triky - Bezpečné přihlašování uživatelů

http://php.vrana.cz/bezpecne-prihlasovani-uzivatelu.php

12. 2. 2014 15:33:08

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995746

netbrana

(14 hodnocení)

12. 2. 2014 15:41:27

Napsal t-pack25;1056177
Keď už pri hashovaní používať SHA, tak rovno SHA512. Zároveň bez SSL to nikdy nebude moc bezpečné, riziko odsledovania komunikácie tu vždy bude. Ja by som aspoň prihlasovanie zabezpečil týmto spôsobom
PHP triky - Bezpečné přihlašování uživatelů
http://php.vrana.cz/bezpecne-prihlasovani-uzivatelu.php

Díky za tip na článek ;)

Ještě jsem zapomněl doplnit, že mám i ochranu proti session hijack. do SESSION bude uložena mimo jiné i IP přihlášeného uživatele, uživatelův OS a to celé bude osolené. SESSION se bude neustále znovu kontrolovat.

Dostal jsem tip na Clickjacking - právě studuji možné způsoby ochrany :)

12. 2. 2014 15:41:27

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995745

t-pack25

12. 2. 2014 15:44:38

ano, všimol som si už na djpw :)

12. 2. 2014 15:44:38

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995744

David S.

(4 hodnocení)

12. 2. 2014 15:49:47

Pokud má být systém skutečně bezpečný, tak bych jej přesunul na hosting, který podporuje přiřazení vlastní IP (pro SSL), případně podporuje SNI (omezení u starších prohlížečů) - není nutnost vlastní IP pro SSL.

Můžu Vám nabídnout hosting u nás www.lethost.cz.

Podporujeme přidělení vlastní IP (za poplatek) nebo je k dispozici SNI (jak je uvedeno výše).

+ nabízíme SSL certifikáty - momentálně PositiveSSL (Comodo) za výhodných podmínek (individuální nabídka).

12. 2. 2014 15:49:47

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995743

Petr Soukup

(5 hodnocení)

12. 2. 2014 15:52:31

Napsal netbrana;1056185
Díky za tip na článek ;)
Ještě jsem zapomněl doplnit, že mám i ochranu proti session hijack. do SESSION bude uložena mimo jiné i IP přihlášeného uživatele, uživatelův OS a to celé bude osolené. SESSION se bude neustále znovu kontrolovat.

Omezovat session na IP není dobrý nápad. My například na prodejny dáváme routery s loadbalancerem, který spojuje třeba 2-3 providery. Důsledkem je, že se uživatelé připojují k webům přes 2-3 různé IP, takže by je to neustále odhlašovalo.

12. 2. 2014 15:52:31

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995742

saas

(2 hodnocení)

12. 2. 2014 16:48:09

Pokud bezpečnost chcete opravdu brát vážně, tak ji musíte řešit od A-Z. Tj. budete mít mega zabezpečenou aplikaci, ale celé to bude na sdíleném hostingu. To je stejné jako když byste měl skvěle zabezpečený kufřík, ale nechal ho v odemčeném autě. Někdo tam na hostingu nahraje blbě zabezpečenou aplikaci a útočník v klidu získá root práva na celý server a uvidí co se mu bude líbit. Chtělo by to tedy samostatný server na který budete mít root práva a šifrování disků.

Plus pomůže dvoufázová autentizace.

12. 2. 2014 16:48:09

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995741

Martin Schlemmer

(36 hodnocení)

12. 2. 2014 19:53:14

Napsal netbrana;1056166
- Heslo je v databázi doplněno o bezpečností klíč (pepper) a hashováno v md5.
- Srovnávají se osolená hesla (sha1 nebo sha256)

Co tím přesně myslíte? Hashujete heslo s globální hodnotou (pepper) pomocí MD5, pak ještě jednou s unikátní hodnotou (salt) pomocí SHA1? Co znamená "SHA1 nebo SHA256"? Hážete si v programu mincí?

Každopádně jak říkají moudré hlavy, používejte k hashování hesel bcrypt (nebo méně rozšířený scrypt), protože ho můžete nastavit tak, aby byl pomalý (což je v tomto případě vyžadovaná vlastnost).

12. 2. 2014 19:53:14

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995740

netbrana

(14 hodnocení)

12. 2. 2014 20:11:02

Napsal Martin Schlemmer;1056296
Co tím přesně myslíte? Hashujete heslo s globální hodnotou (pepper) pomocí MD5, pak ještě jednou s unikátní hodnotou (salt) pomocí SHA1? Co znamená "SHA1 nebo SHA256"? Hážete si v programu mincí?
Každopádně jak říkají moudré hlavy, používejte k hashování hesel bcrypt (nebo méně rozšířený scrypt), protože ho můžete nastavit tak, aby byl pomalý (což je v tomto případě vyžadovaná vlastnost).

- Prozatím používáme na vývojové verzi sha1 ale chtěl jsem nasadit sha256, špatně jsem se vyjádřil :)

- Hesla do databáze ukládáme o globální hodnotu nastavenou v konfiguračním souboru a to celé hashujeme pomocí md5.

Zadané heslo s formuláře se také doplní o globální hodnotu, hashuje se pomocí md5. Zadané heslo a heslo s databáze se osolí přes sha1 a tyto osolené hesla se po-té porovnávají.

12. 2. 2014 20:11:02

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995739

petrrr

12. 2. 2014 20:41:58

@netbrana: Dnes již rozhodně používat blowfish. Odpadne nějaké pochybné generování a ukládání saltu někde vedle.

Pokud je aplikace v PHP 5.5 tak všechno kolem hesel ti obstarají dvě metody:

password_hash() + password_verify() přičemž chce zvolit alespoň "cost" parametr více jak 12 (čím větší číslo, tím déle se heslo generuje)

password_hash($password, PASSWORD_BCRYPT, );

//V manuálu najdeš i jakýsi benchmark na zjištění tohoto čísla.

Pokud není k dispozici SSL tak bych alespoň JavaScriptem před odesláním dat na server heslo zahashoval. Existuje pak ještě tzv. dvoufázové ověření, ale to vzhledem k tomu, že nemáš ani SSL asi nemá pro tebe význam.

edit: v podstatě to ale nejlépe vystihnul @saas

12. 2. 2014 20:41:58

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995738

Vladimír Smitka

(4 hodnocení)

13. 2. 2014 10:00:55

Vřele doporučuji zkouknout

Přednáška X-Wow-Security-Header (DevFest Praha 2013) | Michal Špaček

http://www.michalspacek.cz/prednasky/x-wow-security-header-devfest, přináší takový základní přehled, jak zvýšit bezpečnost pomocí HTTP hlaviček + možná pro vás zajímavý tip na "knocking" do administrace - kde zdánlivě nic není, není co hackovat (zdánlivě) :-)

13. 2. 2014 10:00:55

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995737

Martin Schlemmer

(36 hodnocení)

13. 2. 2014 12:16:32

Akorát pozor, hlavička Content-Security-Policy zakáže vykonávání inline Javascriptu, což se někdy jen těžko obchází.

Zakázáním zobrazování stránky ve framu pomocí X-FRAME-OPTIONS zrušíte také benevolentní aplikace typu čtečka RSS.

Viz taky dobrá diskuse na Hacker News.

13. 2. 2014 12:16:32

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995736

netbrana

(14 hodnocení)

13. 2. 2014 14:56:48

Děkuji všem za odpovědi a odkazy na užitečné zdroje informací :)

Nakonec přesunu celý projekt na VPS se startSSL certifikátem.

Zvažuji i nasazení php5 protože password_hash() + password_verify() se mi hodně líbí.

Ještě jednou děkuji, už v tom mám trochu jasno :)

---------- Příspěvek doplněn 14.02.2014 v 01:01 ----------

Ještě se zeptám, jak podle Vás řeší správu obsahu služby jako heureka.cz, aaapoptavky.cz a služby jim podobné (nebo pokud je tu někdo kdo to ví tak ještě lépe :) ?

Nepředpokládám že mají CMS přístupný z internetu.

děkuji :)

13. 2. 2014 14:56:48

https://webtrh.cz/diskuse/vlastni-system-zabezpeceni-obecne#reply995735