Hlavní navigace

Názor k článku Testování verzí CMS: 50 000 zastaralých instalací systémů WordPress a Joomla od Filip Jirsák - A jak mohou autoři WP za to, že...

  • Článek je starý, nové názory již nelze přidávat.
  • 28. 9. 2017 17:09

    Filip Jirsák

    A jak mohou autoři WP za to, že si tam někdo hodí nějaký zmaštěný plugin? Resp. v souvislosti s tím textem, jak tomu mají autoři WP zabránit, když pak kdejaký neznalec přijde s "Chyba ve WP", což je titulková návnada ... ?
    Uživateli WP je celkem jedno, zda za to může Franta nebo Pepa – pro něj je problém to, že má děravou instalaci WordPressu. Ale když se na to ptáte – autoři WP za to mohou tím, že neposkytují autorům pluginů prostředí, které by je vedlo k psaní bezpečného kódu.

    Ostatně to samé se ti s pluginy třetích stran jde naprasit i v Javě, sice jsi hezky použil preparedStatement, ale i v Javě jde do databáze poslat i normální dotaz jako string do kterého vlepíš proměné přímo z GETu, žádný preparedStatement tam vynucený není .... jenom se to v Javě často používá - jo je to super, ale znova: vynucené jazykem to není
    Tak ještě jednou. Nejde o to, co jde nebo nejde, jde o to, co se používá, co je běžné, co najdete v dokumentaci a návodech. Nic o vynucení jazykem jsem nepsal.

    to že kdekdo zmastí tutoriály na nejjednodušší a v podstatě nebezpečný kód není chyba php
    Chyba PHP je, že takový zmaštěný tutoriál s v podstatě nebezpečným kódem je oficiální dokumentace PHP.

    když už jsme sklouzli k obvinění php
    No, obvinění PHP. Ono k tomuhle PHP původně nebylo určeno. Původní chyba byla na straně těch, kteří ho začali na takovýhle software používat. Na druhou stranu, PHP už se takhle používá dost dlouho, PHP na to reaguje přidáváním jazykových konstrukcí, ale z pohledu bezpečnosti toho dělá jen velmi málo. Takže viníků je několik – což možná bude součást problému, že je za to vlastně zodpovědný kde kdo, takže ve výsledku nikdo.

    Jenomže prepared statements skutečně mají nějakou režii navíc
    To je irelevantní! Tady jde o bezpečnost, tu není možné obětovat za jakési hypotetické minimální zvýšení výkonu. Zvlášť když řádově víc, než co ušetříte nepoužitím prepared statements, propálíte někde jinde (ať už ve vlastním programu, nebo tím, že používáte interpretovaný jazyk volaný přes CGI).

    S query není problém
    Je to problém, ani v té Javě by nemělo statement bez parametrů existovat. Ani to nemusí být implementované pomocí prepared statements, ale když už to někdo mermomocí chce implementovat pomocí escapování parametrů, má to být přímo součástí knihovny. Vždyť spouštět SQL příkaz s vloženými hodnotami bez jejich escapování nedává žádný smysl, pokud tedy nechcete záměrně vytvořit SQL injection, tak k čemu je taková funkce v knihovně?

    problém je ten, že většina lidí, resp. programátorů, ani netuší, že by měli nějaké vstupy ošetřovat
    Ne, problém je jazyk a knihovna, která nutí programátory dělat něco tak nesmyslného jako „ošetřovat vstupy“ kvůli bezpečnosti. Vstupy se ošetřují z hlediska logiky aplikace, např. že věk nemůže být záporný. Ale z hlediska bezpečnosti je to nesmysl – problém není v tom vstupu, ale v tom, že pro knihovnu existuje něco jako „nebezpečný vstup“. Když chci uložit nějaký text do databáze, mám ten text předat knihovní funkci a ta ho má tak jak je uložit do databáze – ne že se musím starat o to, jestli je pro tu knihovnu bezpečný.

    to je vyložená neznalost, která jednoznačně ukazuje že se tenčlověk neorientuje v totálních základech web. bezp.
    To nejsou základy webové bezpečnosti, to jsou základy nebezpečnosti jednoho konkrétního jazyka a jeho standardní knihovny.