Komentáře k článku

Automatické zabezpečení

Nespoléhejte se na to, že do kódu nezapomenete na všechna místa připsat ošetření dat. Snažte se aplikaci navrhnout tak, aby se na nic zapomenout nedalo. Za cenu o něco složitějšího jádra bude veškerý kód, který ho používá, obvykle taky mnohem jednodušší.

Zpět na článek

10 komentářů k článku Automatické zabezpečení:

  1. mhlavac

    Frameworky

    Mezi námi je furt spousta vývojářů, kteří neví co je zabezpečování dat. Nejlepší radou pro ně je použít nějaký již hotový framework. Problém těchto vývojářů je ten, že se ho učit nechtějí a tak radši věnují svůj čas na věčnou implementaci stejných částí furt dokola a dokonce znova a znova špatně.

    Co se týče zabezpečení SQL dotazů tak celkem zajimavým nástrojem je QueryBuilder, který používá Doctrine 2. Bohužel jako každá abstraktní vrstva i tady to má menší vliv na výkon, ale ve výsledku za to použití to stojí.

    Pro dostatečné základy ohledně bezpečnosti stačí prolítnout Symfony 2 dokumentaci, která obsahuje údaje o tom jak zabezpečit stránku v jednoduché formě. Problém ale přetrvává, jedná se o další čtení o které velká část programátorů nemá zájem, protože jejich způsob jim dostačuje.

    1. Jakub VránaAutor příspěvku

      Re: Frameworky

      Prolítnout dokumentaci a držet se jí je přesně ten postup, od kterého článek odrazuje. Cílem by mělo být aplikaci (nebo framework) navrhnout tak, abych nemusel nic číst, abych mohl dělat cokoliv a stejně to bylo pořád bezpečné. I ti největší a nejpečlivější experti totiž můžou něco přehlídnout, na něco zapomenout nebo někde udělat chybu.

  2. okbob

    trochu jiný přístup

    nebylo by lepší programátory dokopat aby si něco málo o bezpečnosti přečetli a místo psaní „dokonalých“ neprůstřelných frameworků přidat kontroly s warningy na případné bezpečnostní chyby – třeba SQL injection by možná bylo kontrolovatelné poměrně snadno.

    1. Futrál

      Re: trochu jiný přístup

      Taky že je – viz třeba Findbugs, který najde SQL dotazy lepené z nekonstantních řetězců.

  3. Monty

    Jaké ošetření sloupce?

    >> Dotaz prepare(„WHERE name = ?“, „admin“) je lepší, pořád si ale musím dávat pozor na správné ošetření sloupce.
    To nechápu. Jaké ošetření sloupce mám v tomto dotazu provést?

    1. Jakub VránaAutor příspěvku

      Re: Jaké ošetření sloupce?

      Lepší je psát WHERE `name` = ? (v MySQL) pro případ, že by se z name v budoucnu stalo klíčové slovo. To je samozřejmě v tomto konkrétním případě nesmysl, ale v obecném případě to doufám smysl dává.

  4. bene

    Re: Automatické zabezpečení

    Osobně se mi řešení pro neautorizovaný přístup k datům přes WHERE id = ? AND user_id = ? moc nelíbí. Získání pouze přes id vetšinou už je hotové např. kvůli „superadminovi“ nebo nám to nabízí databázová vrstva. Psát další SQL dotazy ať už formou čístého SQL nebo „fluent“ nástroje by se mi nechtělo. Navíc taková věc lze někde zapomenout.

    Raději bych vytvořil nějakou UserFacade($u­serId), která by nabízela jen ty metody pro vracení dat, které daný uživatel skutečně získat může a ošetření na user_id bych udělal v ní. Pak budu v aplikaci používat skutečně bezpečnou vrstvu kde možnost udělat chybu je pouze nepoužít tuto vrstvu a to je pak už diletanství.

    Možná to vypadá jako totéž (udělám si DB vrstvu, která je jen pro uživatele), ale UserFacade by využívala hotovou DB vrstvu a jen by kontrolovala user_id (samozřejmě v některých případech by musela být DB vrstva dopněna o nějaké dotazy v případě, že je user_id k dispozici např. přes join).

    public fucntion getArticle($id) {
        $article = $this->repository->getArticle($id);
        if ($article->user_id != $this->userId) {
            throw new UnauthorizedException;
        }
        return $article;
    }

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3773