Hlavní navigace

Názory k článku Testování verzí CMS: 50 000 zastaralých instalací systémů WordPress a Joomla

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

    Muj nazor (neregistrovaný)

    akce rozhodne neuskodila - alespon jsem u dvou zakazniku kteri provozuji vetsinu webu na wp zjistil kde je vsude maji a mohl aktualizovat :-)

  • 27. 9. 2017 10:17

    to_je_jedno

    Proc neni nikde v clanku zminen Drupal? Osobne bych si tipl, ze jeste obcas nekde nejaky neaktualizovany drupalgedon positive weby budou.

  • 27. 9. 2017 12:17

    tomas (neregistrovaný)

    Pekna prace.
    Pocitate taky s tim, ze CMS je sice deravy jak reseto, ale je pred nim mod_security ?

  • 27. 9. 2017 19:26

    NN (neregistrovaný)

    *Příprava celé akce se protáhla, především kvůli počátečnímu zhodnocování některých právních aspektů a následné přípravě právní analýzy, abychom si byli jisti, že vše provedeme v souladu se zákonem."

    Dalo by se to nejak strucne popsat? Pochopim, ze nabizite sluzbu dobrovolneho skenovani webu, ale kde je legalni hranice pri takovemto vetsim " samozvanem" plosnem skenu ? Role ochrance internetu je usmevna, ale z meho pohledu nedostatecne oduvodneni. No offence.

  • 27. 9. 2017 22:38

    karel (neregistrovaný)

    Co je vlastně příčinou těchto problémů s populárními CMS? Jsou špatně navržené a napsané nebo je to spíše chyba správců a webhostingů, kteří to nedokáží správně nakonfigurovat a udržovat?

  • 27. 9. 2017 23:46

    Vláďa Smitka

    Ilustrovaná příčina problému: https://www.slideshare.net/vsmitka/bezpenost-wordpress-pro-zatenky/6

    WordPress zpřístupnil tvorbu webových stránek širokým masám - blog si na něm může rozjet úplně každý, bez znalosti programování. Bohužel se to trochu zvrtnulo a lidé se znalostmi dostatečnými k provozování jednoduchého blogu se začali snažit o vytváření komplexních webů a mnoho z nich to začalo dělat komerčně. U většího webu se už dost hodí vědět co děláte...

    Vzniká tak velká spousta webů, kde se šetřilo na tvůrci i na následném provozu - do webu nejsou funkce programovány, ale naklikávány pomocí pluginů velmi různé kvality a v mnoha případech, kdy daná funkcionalita není zadarmo, jsou pluginy/šablony získávány různě pokoutně, vždyť WP je zdarma... Mnoho "tvůrců" webů jednoduše koupí za pár $ šablonu a provede přímo v ní úpravy (typicky přeložení do CZ) a tím znemožní její aktualizovatelnost a majiteli řekne "hlavně nic neaktualizujte, jinak přijdete o úpravy". Majitelé webů také nejsou často ochotni někomu platit za to, aby se o web staral - vždyť WP je zdarma.

    Problém je tedy především na straně majitelů webů, že za ně nechtějí platit a na straně tvůrců, kteří prodávají něco, na co nemají dostatek zkušeností a jsou dost líní se v oboru dále vzdělávat. A to mám ověřeno prakticky, děláme každoročně mnoho akcí zaměřených na WordPress, včetně oficiální konference WordCamp Praha, takže vidím to nízké procento lidí, kteří komerčně dělají WP a zároveň na tyto akce chodí. Například na předloňský WordCamp jsem dělal akci, kdy jsem nalezl zhruba tisíc kriticky zranitelných WP webů, nad kterými jsem mohl velmi jednoduše získat plnou kontrolu, nalezl kontakty na jejich tvůrce, či majitele a všechny obepsal s informacemi, co je na webu špatně, jak to opravit a pozvánkou na naší akci k rozšíření obzorů a naučení správných postupů - přišli 2...

  • 28. 9. 2017 3:43

    Filip Jirsák

    To jste ovšem popsal, proč nejsou pluginy nebo jádro aktualizované, nikoli proč v nich jsou díry. Což je sice také problém, ale primární problém je, že tam vůbec je tolik bezpečnostních chyb. A to je dané architekturou WP i architekturou PHP, které jsou zaměřené na co nejsnazší spuštění kódu, naopak na bezpečnost je potřeba tam pořád myslet a aktivně se o ni starat.

  • 28. 9. 2017 9:30

    Vláďa Smitka

    Odpověď na otázku proč jsou v nich díry je jednoduchá - píšou je lidé a lidé dělají chyby. Podobné chyby vídám v aplikacích psaných .NET, Javě a všech možných dalších jazycích. Jen ostatní aplikace nejsou tak rozšířené, aby dané chyby byly tak viditelné. Nicméně v principu ale máte pravdu - architektura samotná tomu moc nepomáhá a předpokládá, že ten, kdo dané rozšíření píše ví co dělá a používá prostředky, které mu WP nabízí například pro ošetřování vstupů - https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data (a zde je další problém - mnoho tvůrců ani neví, že existuje Codex, kde jsou popsány zásadní best practices)

    Bohužel si s sebou WP nese zátěž z let dlouho dozadu a to ohromnou snahu o zpětnou kompatibilitu. Jádro může být tak stěží označováno za moderní aplikaci. Problém kompatibility si my, kteří jsme zatím nenapsali systém, na kterém běží produkčně několik desítek milionů webů, nedokážeme ani představit. Profi vývojáři se pak WP vysmívají, že nemá pořádný šablonovací systém (který třeba zařídí ošetření výpisu uživatelských vstupů), že není MVC, nepoužívá composer, ..., ale kdo z nich tyto technologie před 6 lety používal?

  • 28. 9. 2017 10:33

    null null (neregistrovaný)

    @bez_přezdívky

    Několik let jsem komerčně dělal, a hlavně opravoval, Wordpressy a je to naprosto přesně tak jak píšeš. Měl bych ale, s dovolením, námitku. To že má něco šablonovací systém ještě neznamená, že to někdo nezmastí - např.: najde si přes google v tutorialu jak z POSTu rychle udělat v PHP dotaz
    <?php "SELECT * FROM xyz WHERE name = ".$_GET['search']; ?> a je vymalováno šablony nešablony ...

    Víš, za ty roky jsem nepřestal WP nenávidět :-) ale zjistil jsem, že na to, jaká je to v podstatě taková totálně velká API pro Themes a Plugins to ještě není tak hrozné ... přece jenom funguje "out fo the box", což je ale paradoxně, jak ostatně píšeš, zároveň jeho nevýhoda.

  • 28. 9. 2017 10:35

    null null (neregistrovaný)

    Pardon, text je adresován pro @Vladimír Smitka

    S "V pripade WP spatny navrh a ekosystem. Ne tak uplne free a open fungujici prodavani pluginu/sablon." od @bez_přezdívky nesouhlasím.

  • 28. 9. 2017 11:07

    to_je_jedno

    Kdyz tohle je prave ten ekosystem a zaroven distribuce kodu. Viz nedavna zprava o tom, ze byl prodavan primo malware plugin pro WP. Nebo dokonce zprava par mesicu zpet o tom kolik pluginu ma zasadni diry(XSS/SQL-I).

    Tohle v modulu/sablone pro Drupal na drupal.org proste nenajdes. Uz protoze drtiva vetsina tech pouzivanych prochazi pri kazdem release auditem security teamu.

  • 28. 9. 2017 12:15

    Vláďa Smitka

    I moduly pro Drupal mají dost svých problémů: https://www.drupal.org/security/contrib

    To že někdo prodá své rozšíření někomu dalšímu a ten do něj dá malware bohužel není příliš šokující věc a děje se běžně - u rozšíření do prohlížečů, mobilních aplikací. To že určitá část pluginů v repozitáři obsahuje chyby je sice smutné, ale normální - povětšinou se jedná o staré pluginy, které téměř nikdo nepoužívá - pokud si někdo jen tak nainstaluje plugin, který nebyl 3 roky aktualizován (a takové ani nejde jednoduše běžným způsobem vyhledat v repozitáři) a používá ho 5 uživatelů, tak se samozřejmě vystavuje určitému riziku (které bohužel běžný uživatel nedokáže vyhodnotit). Také by bylo fér podotknout, že většina chyb jsou authenticated XSS, kdy admin může zaútočit sám na sebe - netvrdím, že to není problém, ale tento chyb nalezneme ve spoustě custom made administracích mnoha systémů, vývojáři jsou často jednoduše líní.

  • 28. 9. 2017 13:14

    null null (neregistrovaný)

    @Vladimír Smitka (bez_přezdívky 10)

    +1

    @bez_přezdívky 55

    Zajímavé. Takže Drupal je dokončená technologie bez security issues? A nebo tak trošku kecáš?

  • 28. 9. 2017 17:16

    to_je_jedno

    Tohle urcite nikdo netvrdi. Jen jde o mnozstvi kritickych chyb. Za 10 let u drupalu jsem potkal weby hacknute jen dvema zpusoby utoku - drupalgeddon(zdra­vime na Panamu :-) ) a pak neco co bylo v CKEDitoru.

    Naproti tomu mame clanek u ktereho debatujeme.
    Naproti tomu mame logy webovych serveru - zkuste se tam mrknout co boty laka :-)
    Naprosti tomu mame zkusenosti kdy u me stacilo jednou se nechat ukecat a dat ten WP na server. Za tyden sel do hajzlu protoze jsem na to nemel nervy. Oproti tomu desitky Drupal webu v zasade neudrzovanych a krom vyse zmineneho drupalgedonu (a drive utoky pres nesifrovana ulozena hesla v totalcmd zakaznika) nikdy nic.

  • 28. 9. 2017 17:51

    Vláďa Smitka

    Boty samozřejmě láká systém, který je více rozšířený. Vzhledem k tomu, že WP webů je mnohonásobně více než Drupalů (https://trends.builtwith.com/cms), tak samozřejmě budou více zkoušet WP a budou rovnou zkoušet desítky známých zranitelností, které jsou většinou už dávno opravené.

  • 28. 9. 2017 17:11

    to_je_jedno

    Ano, moduly Drupalu problemy maji, ale mrkni jake problemy. Drtiva vetsina tech "problemu" je limitovana podminkou ve smyslu "uzivatel ma pravo administrovat XY". To je dost rozdil oproti vetsine chyb v pluginech/sablonach WP kde je to spis dane navrhem aplikace a ekosystemem kolem.

    Bylo by to jaksi na dlouhou debatu, ale myslim, ze to je prave ten "ekosystem".

  • 28. 9. 2017 11:11

    to_je_jedno

    Je potreba do toho proste riznout. Drupal to verzi 8 udelal, ma v nem nulovou BC a k tomu byt moderni aplikaci razne nakrocil (zdaleka to neni dokonale). Spousta lidi z Drupal komunity by hodne ocenila kdyby sly nektere veci z WP jednoduse pouzit v jinem SW diky PSR standardum apod.

  • 28. 9. 2017 12:27

    Filip Jirsák

    Odpověď na otázku proč jsou v nich díry je jednoduchá - píšou je lidé a lidé dělají chyby.
    Jenže otázka nezněla, proč jsou v nich díry, ale proč jich je tolik – mnohem více, než v jiných aplikacích.

    Podobné chyby vídám v aplikacích psaných .NET, Javě a všech možných dalších jazycích.
    Ale kdepak. V .NET nebo Java aplikaci se musíte mnohem víc snažit, abyste vyrobil třeba SQL injection, v PHP to jde skoro samo (s tím, co se běžně používá) a naopak se musíte snažit, abyste SQL injection nevyrobil.

    Těch problémů s architekturou PHP je víc, jeden z nich je například to, že aplikace jsou soubory interpretované webovým serverem, které jsou pohromadě se soubory, které webový server jenom servíruje uživatelům (statický obsah). Přičemž tohle není nějaké nedopatření, tohle je záměr, jedna z vlastností, proč PHP vůbec vzniklo. No a takový CMS potřebuje umět na server nahrávat nový obsah, který pak ten webový server poskytuje ostatním. To je samozřejmě obrovská bezpečností díra, protože to umožňuje útočníkovi nahrát na server svůj vlastní kód. Jediný způsob, jak tuhle díru zalepit, je ten, že musíte ošetřit každé místo v aplikaci, které by něco takového mohlo umožnit. To je velmi pracné a velmi obtížně se to uhlídá. V Javě nebo .NET takovou chybu vyrobíte jen velmi obtížně a musíte se dost snažit.

    Jen ostatní aplikace nejsou tak rozšířené, aby dané chyby byly tak viditelné.
    Třeba Linux (jádro) je taky celkem rozšířený, dalo by se říct, že tam, kde běží WP, běží i Linux – a pak ještě na spoustě dalších míst. A tolik stále se opakujících chyb, jako WP, opravdu Linux nemá.

    používá prostředky, které mu WP nabízí například pro ošetřování vstupů
    To je právě jeden z problémů, že potřebujete speciální prostředky na ošetřování vstupů. Ona ta beztypovost PHP a to, že se snaží si s daty vždy nějak poradit, je výhodná, když si píšete něco pro sebe, když není potřeba bezpečnost řešit. Ale jakmile to chcete zabezpečit, naopak vám to neustále přidělává práci. PHP bohužel vzniklo v době, kdy se bezpečnost neřešila a vzniklo právě proto, aby byl vývoj snadný – a obě tyhle vlastnosti si logicky podrželo do dneška.

    Profi vývojáři se pak WP vysmívají, že nemá pořádný šablonovací systém (který třeba zařídí ošetření výpisu uživatelských vstupů), že není MVC, nepoužívá composer, ..., ale kdo z nich tyto technologie před 6 lety používal?
    No, upřímně řečeno, vývojáři, kteří nepíšou v PHP, tyto technologie běžně používali mnohem dřív, než před šesti lety. Ale to je přesně to, co jsem psal na začátku – PHP svou architekturou a pojetím není pro takhle velké aplikace vhodné. Sice se tam přidávají vlastnosti, které tohle usnadňují, ale pořád tam zůstává ten základ, podvozek toho všeho, který k tomuhle určený není. Který funguje jako vylepšené SSI a který mi umožní do HTML stránky rychle přidat nějaký dynamický prvek, výpis něčeho, zpracování jednoduchého formuláře apod. V tom je PHP výborné a vlastně dodnes nedostižné. Bohužel se dnes často používá pro něco úplně jiného.

    Aby bylo jasno, to mé tvrzení, že je to problém architektury PHP, neznamenalo, že problém je v PHP – problém je v tom, kdo si PHP vybere pro aplikaci, pro kterou je nevhodné. Ale zároveň chápu, že si vývojáři WordPressu, Joomla nebo Drupalu vybrali právě PHP – aplikace pak běží téměř na jakémkoli webhostingu. java nebo .NET (nebo něco exotičtějšího) by z pohledu architektury sice byly vhodnější, ale pro provozovatele to znamená nejspíš provozovat vlastní VPS (a v tom jsou zase jiná bezpečnostní rizika).

  • 28. 9. 2017 13:00

    Vláďa Smitka

    Především je třeba rozlišovat chyby v jádře WP a chyby v doplňcích, které dělá kde kdo. Linuxový kernel má také spousty svých chyb, které se stále opakují a jejich dopady jsou mnohem závažnější:

    http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
    - pro srovnání http://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337

    To že někdo udělá XSS nebo SQLi není podle mě záležitost jazyka - poslat formulářové políčko rovnou do DB lze všude. SQLi ASP.NET aplikaci jsem naposledy nalezl minulý týden, XSS v Java EE web aplikaci taktéž.

    Pro pořádek, nerad bych se pouštěl do nějakých brutálních hádek - na všech vašich argumentech je trocha pravdy, snažím se jen názory zkreslené do negativna dorovnávat svými názory zkreslenými do pozitivna.

  • 28. 9. 2017 14:22

    Filip Jirsák

    Především je třeba rozlišovat chyby v jádře WP a chyby v doplňcích, které dělá kde kdo.
    Oni to snad útočníci rozlišují? To, že je to chyba „jen“ v doplňku vám nějak pomůže, když ten doplněk máte nainstalovaný? Vždyť kvůli tomu množství doplňků se právě WordPress používá. Zároveň když vybíráte doplněk, nemáte moc šanci zjistit, zda bude bezpečný. Je pravda, že chyba v doplňku neohrožuje každou instalaci WP, ale je víceméně věcí náhody, zda ta chyb ovlivní i vaši instalaci.

    Linuxový kernel má také spousty svých chyb, které se stále opakují a jejich dopady jsou mnohem závažnější
    Kolik měl Linuxový kernel v roce 2017 vzdáleně zneužitelných chyb? Chyby, které se v linuxovém kernelu opakují, jsou typické pro C aplikace – a většinu z nich byste v PHP aplikaci vyrobil velmi těžko. To je ten vliv programovacího jazyka a prostředí, o kterém jsem psal.

    To že někdo udělá XSS nebo SQLi není podle mě záležitost jazyka - poslat formulářové políčko rovnou do DB lze všude.
    Samozřejmě, že to jde všude, to ale není podstatné. Podstatné je, jak se to dělá typicky, co najdete v návodech atd. Typický příklad dotazu do databáze, který najdete prakticky v každém návodu k PHP, je tohle:

    $mysqli->query("SELECT actor_id, first_name, last_name FROM actor WHERE actor_id = $aid");

    nebo případně:

    mysql_query("SELECT actor_id, first_name, last_name FROM actor WHERE actor_id = $aid")

    Takže začnete s kódem náchylným na SQL injection, a pak, pokud vůbec zjistíte, že něco takového existuje a že je potřeba se tím zabývat, to můžete začít zalepovat.

    V Pythonu ten samý případ vypadá takhle:

    select_stmt = "SELECT * FROM employees WHERE emp_no = %(emp_no)s"
    cursor.execute(select_stmt, { 'emp_no': 2 })

    Ano, programátorovi to nebrání poskládat SELECT rovnou s vloženou hodnotou, ale v dokumentaci to vidí rovnou takhle, rovnou vidí ten druhý parametr funkce execute() – a poskládat ten SQL dotaz jako řetězec by vlastně bylo komplikovanější.

    To samé v Javě:

    PreparedStatement ps = con.prepareStatement("SELECT * FROM employees WHERE emp_no = ?");
    ps.setInt(1, 2);
    ResultSet rs = ps.executeQuery();

    PHP také umí prepared statements a bindování proměnných, ale rozhodně to není mainstream a když to zmíníte před nějakým PHPčkařem, pokud o tom vůbec ví, začne vyjmenovávat, že to může být pomalejší a kdesi cosi.

    Nemyslím si, že by mé argumenty byly zkreslené do negativna – to, že je PHP zaměřené na rychlé prototypování (dnešní terminologií) je základní vlastnost toho jazyka, je dobře, že takový jazyk existuje, ale je potřeba vědět, že to je dvousečná zbraň.

    Zrovna to nepoužívání bindovaných proměnných v MySQL dotazech přitom jde jednoznačně za týmem kolem PHP – dalo by se to pochopit před deseti roky, ale ne v roce 2017. V oficiální dokumentaci PHP v příkladu použití pořád najdete jen query() a žádné prepare(), v Quick start guide jsou prepared statements stále až jako další kapitola po executing statements s query(), a ještě je to označené jako speciální varianta pro efektivní provádění opakovaných dotazů. Kolik let ještě bude trvat, než se změní přístup autorů, než se to změní v oficiální dokumentaci, a pak než to postupně probublá do různých návodů,příruček, učebnic a blogů? Mimochodem, i ten WordPress stále používá query()

  • 28. 9. 2017 16:09

    null null (neregistrovaný)

    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 ... ?

    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í: třeba že bys musel všechno hrnout přes nějaké Query Buildery ....

    Ostatně PHP je variabilní jazyk (když už jsme sklouzli k obvinění php) a to že kdekdo zmastí tutoriály na nejjednodušší a v podstatě nebezpečný kód není chyba php. Když vezmeš do ruky nůž s kterým neumíš a řízneš se, bude ostrost nože jeho nevýhoda?

    "V oficiální dokumentaci PHP v příkladu použití pořád najdete jen query() a žádné prepare()"

    Jenomže prepared statements skutečně mají nějakou režii navíc a dřívější verze ho plně nepodporují. S query není problém, problém je ten, že většina lidí, resp. programátorů, ani netuší, že by měli nějaké vstupy ošetřovat. Stejný evergreen asi jako "Na co je mi HTTPS když mám statický obsah webu" - to je vyložená neznalost, která jednoznačně ukazuje že se tenčlověk neorientuje v totálních základech web. bezp., že i když programuje tak si to neobtěžoval zjistit a je to pak chyba html? Nebo TCP? Nebo ISP?

  • 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.

  • 28. 9. 2017 20:34

    null null (neregistrovaný)

    @Filip Jirsák

    Asi bude trvat dlouho než ti dojde, že autoři nemohou udělat takový systém, aby tam nešlo napráskat chyby když někdo přidá vlastní kód. Kdybys o WP a pluginech skutečně něco věděl, tak by ti bylo známo, že kompletní API od WP existuje, ale hromada pluginů jej nepoužívá a implementuje své po svém. Ostatně o tom psal i @Vladimír Smitka (bez_přezdívky 10).

    Ten tvůj návod je k mysqli a s mysqli se prostě jinak nepracuje. Ostatně v tom návodu není chyba. Já toto tak jak to je v tom návodu třeba používám když dělám interně nějaké prototypování které se pak smaže nebo přepíše výsledek/výkon .... Nic závadného na tom není. Problém nastává, když si to někdo vygooglí a vůbec ne nezamyslí nad nějakou bezpečností nebo se neobtěžuje nastudovat API systému, pro který dělá. Uznávám že WP API je rozsáhlá a místy složitá.

    Výkon prepared statements není irelevantní. Když nemáš uživatelské vstupy a jenom přelíváš data, nota bene ještě jako třeba jenom prototyp, tak tě nějaký prepared statement vůbec nezajímá ... nebo nemusí. Ale může. To je variabilita php. Někdo to holt nezkousne a v rukách amatéra to může být pohroma.

    Ano, možná by to v Javě ani v php být nemělo, ale je. A ne každý zažívá ten komfort moct všechno typovat na integery, jak tam někde píšeš. Ano, mohou to dělat knihovny a moderní trendy takové jsou, super, ale někdy se prostě píše aplikace custom na míru, ne z fw. Ne všechno co manipuluje s webem je Drupal nebo WP. Ostatně WP API má všechny funkce k dotazům na data přes API ošetřené. Jenomže často se tam v pluginech leze přímo a tam to často bývá zfušované.

    No jasně knihovní funkce a o nic se nestarat, ale napadlo tě že i ta knihovní funkce musí být v něčem napsaná? A tam už tě to zajímá . . .
    A ani není pravda že tě vstup nezajímá a má to řešit knihovna, protože neexistuje jenom SQLInjection a ukládání do databáze.

    No, mám z tvého výkonu pocit, že tam kde se použijí knihovny a java, tak není problém. Ono to tak ale ve skutečnosti není, že?

  • 28. 9. 2017 21:09

    Filip Jirsák

    Asi bude trvat dlouho než ti dojde, že autoři nemohou udělat takový systém, aby tam nešlo napráskat chyby když někdo přidá vlastní kód.
    Nechápu, proč oslovujete mne, a pak polemizujete s vlastním výmyslem, který já jsme nikdy nenapsal. Opakovaně jsem výslovně napsal, že nejde o to, co je teoreticky možné, ale o to, k čemu daný jazyk a platforma spíš navádí a čemu spíš brání. Z vašeho komentáře plyne, že podle vás jsou všechny programovací jazyky a platformy stejné a liší se jenom syntaxí. Jenomže tak to není. Třeba běžný kód v C bude podstatně náchylnější k buffer overflow chybám než běžný kód v PHP. Což neznamená, že nejde vyrobit buffer overflow i v PHP, ani to neznamená, že se má všude používat PHP místo C.

    A mimochodem, udělat systém, ve kterém bude obtížné ve vlastním kódu udělat některé chyby, je možné – příkladem takového systému je např. PHP, ve kterém je obtížné udělat některé chyby, které byste mohl udělat ve stejném kódu napsaném v C.

    Kdybys o WP a pluginech skutečně něco věděl, tak by ti bylo známo, že kompletní API od WP existuje
    To je v rozporu s něčím, co jsem napsal?

    ale hromada pluginů jej nepoužívá a implementuje své po svém
    To provozovatelům těch napadených webů nějak pomůže?

    Ten tvůj návod je k mysqli a s mysqli se prostě jinak nepracuje.
    Což je právě chyba.

    používám když dělám interně nějaké prototypování které se pak smaže nebo přepíše
    Jak jsem psal, tohle je vhodný způsob použití. Bohužel ale jiní toto často používají v produkčních systémech.

    Problém nastává, když si to někdo vygooglí a vůbec ne nezamyslí nad nějakou bezpečností nebo se neobtěžuje nastudovat API systému, pro který dělá.
    Takoví lidé ale evidentně WP pluginy píšou, a je to záměr. A pak je tu pořád ten problém, že to v té dokumentaci není popsané jako bezpečnostní riziko, a že tam ty nebezpečné funkce vůbec jsou uváděné jako primární řešení, místo aby primární byly ty bezpečné funkce a tyhle nebezpečné byly v nějaké advanced sekci pro programátory, kteří dobře vědí, co dělají.

    Výkon prepared statements není irelevantní.
    Je irelevantní. Pokud předčasná optimalizace jenom stojí čas programátora, je to sice hloupost, ale neškodná. Pokud způsobí bezpečnostní problém, je to vážná chyba. To, že někdo dělá předčasné optimalizace v prototypu, je jeho chyba – měl by si zjistit, k čemu prototyp slouží.

    Někdo to holt nezkousne a v rukách amatéra to může být pohroma.
    Což je u PHP, což je platforma pro amatéry, docela problém.

    A ani není pravda že tě vstup nezajímá a má to řešit knihovna, protože neexistuje jenom SQLInjection a ukládání do databáze.
    Já jsem nepsal, že to má řešit knihovna. Nemá se to řešit vůbec, pokud ten vstup není něco potenciálně nebezpečného jako třeba cesta k souboru nebo kód. Ale obyčejný text není nic, co by mělo být nebezpečné a mělo se to nějak speciálně ošetřovat.

    No, mám z tvého výkonu pocit, že tam kde se použijí knihovny a java, tak není problém. Ono to tak ale ve skutečnosti není, že?
    Ne, ve skutečnosti to tak není, je to jen váš ničím nepodložený pocit.

  • 29. 9. 2017 9:16

    null null (neregistrovaný)

    "Nechápu, proč oslovujete mne, a pak polemizujete s vlastním výmyslem, který já jsme nikdy nenapsal. Opakovaně jsem výslovně napsal, že nejde o to, co je teoreticky možné, ale o to, k čemu daný jazyk a platforma spíš navádí a čemu spíš brání."

    A já ti opakovaně píšu, že i když tomu platforma "spíš" brání, tak nikdo nezbrání tomu, aby tam někdo napráskal chyby - A JE JEDNO JAKÉ - LANGUAGE SPECIFIC - protože je nevylučuje, jenom "spíš" brání. To nemusí být problém u mě, nemusí být u tebe, ale do WP často dělají pluginy amatéři a pak to tak vypadá.

    "A mimochodem, udělat systém, ve kterém bude obtížné ve vlastním kódu udělat některé chyby, je možné – příkladem takového systému je např. PHP, ve kterém je obtížné udělat některé chyby, které byste mohl udělat ve stejném kódu napsaném v C."

    Není, jenom se v C a v PHP dají z nedbalosti práskat jiné chyby. Ne že v jednom ano, v jednom ne.

    "Kdybys o WP a pluginech skutečně něco věděl, tak by ti bylo známo, že kompletní API od WP existuje
    To je v rozporu s něčím, co jsem napsal?"

    Filip Jirsák 100 Bronzový podporovatel Včera 17:09
    "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."

    "ale hromada pluginů jej nepoužívá a implementuje své po svém
    To provozovatelům těch napadených webů nějak pomůže?"

    Ne, ale je to důvod toho o čem se tu polemizuje. Pokud se tak moc chceš bavit o řešeních, tak proč si vybíráš jednotlivé věty a píšeš k nim elaboráty místo návrhu řešení?

    "Ten tvůj návod je k mysqli a s mysqli se prostě jinak nepracuje.
    Což je právě chyba."

    Jenže ta funkce je dost používaná. Už jenom ve starších verzích PHP. Mimochodem to je tvou selectivní slepotou, ale i v tom tvém příkladu v dokkumentaci je "MySQLi extension basic examples". A jelikož si klasický amatér, včetně tebe (nebo možná spíš až taková hvězda), nepřečte poznámky v kódu tak nezjistí že:
    "...Let's make it
    // default to 1, and cast it to an integer as to avoid SQL injection
    // and/or related security problems. Handling all of this goes beyond
    // the scope of this simple example...."

    "Někdo to holt nezkousne a v rukách amatéra to může být pohroma.
    Což je u PHP, což je platforma pro amatéry, docela problém."

    Pokus o laciný flame? Jak je vidět, tak PHP evidentně pro amatéry není. Viz. běžní pisatelé pluginů . . . . .

    "Já jsem nepsal, že to má řešit knihovna. Nemá se to řešit vůbec, pokud ten vstup není něco potenciálně nebezpečného jako třeba cesta k souboru nebo kód. Ale obyčejný text není nic, co by mělo být nebezpečné a mělo se to nějak speciálně ošetřovat."

    Každý vstup do aplikace a každý výstup je potenciálně nebezpečný. Některý více, některý méně. U webů to platí dvojnásob. A ona by to měla řešit nějaká knihovna, protože obecně platí, že programátor při použití knihovních funkcí méně zapomíná udělat nějaký jeden krok z několika. Typický příklad jsou šablony např. v Nette, když už v PHP, nebo ty prepared statements . . .

    "No, mám z tvého výkonu pocit, že tam kde se použijí knihovny a java, tak není problém. Ono to tak ale ve skutečnosti není, že?
    Ne, ve skutečnosti to tak není, je to jen váš ničím nepodložený pocit."

    Výborně

  • 29. 9. 2017 10:45

    Filip Jirsák

    A já ti opakovaně píšu, že i když tomu platforma "spíš" brání, tak nikdo nezbrání tomu, aby tam někdo napráskal chyby
    A píšete to proč? Je to nějak důležité? Podle vás platí, že nemá smysl zabránit 10 %, 50 % nebo 90 % chyb, protože když nemůžu zabránit 100 % chyb, nemám dělat nic? Mají se v autech přestat používat airbagy, bezpečnostní pásy nebo ABS, protože když to nezabrání všem nehodám, nemá se to používat vůbec?

    do WP často dělají pluginy amatéři a pak to tak vypadá
    Právě proto, že to dělají amatéři, je dobré dát jim do rukou takový nástroj, se kterým mohou pracovat i amatéři. Ne něco, kde jim napíšete „takhle se to dělá a takhle to bude fungovat“, a oni si mají někde úplně jinde zjistit, že takhle se to vlastně vůbec dělat nemá.

    Není, jenom se v C a v PHP dají z nedbalosti práskat jiné chyby. Ne že v jednom ano, v jednom ne.
    Chápete rozdíl ve významu slov „obtížné“ a „nemožné“? Když napíšu, že je něco „obtížné“, myslím tím, že je to „obtížné“, takže je zbytečné vyvracet tvrzení, že je to „nemožné“.

    Jenže ta funkce je dost používaná.
    Budu se opakovat, ale to je právě ta chyba.

    Mimochodem to je tvou selectivní slepotou, ale i v tom tvém příkladu v dokkumentaci je "MySQLi extension basic examples". A jelikož si klasický amatér, včetně tebe (nebo možná spíš až taková hvězda), nepřečte poznámky v kódu tak nezjistí že:
    "...Let's make it
    // default to 1, and cast it to an integer as to avoid SQL injection
    // and/or related security problems. Handling all of this goes beyond
    // the scope of this simple example...."

    Vždyť jsem to psal. Autoři PHP považují kód s SQL injection za základ, a zabránění SQL injection a bezpečnost jsou teprve věci pro pokročilé, které nemusí znát každý programátor. A aplikace podle toho vypadají, SQL injection je běžná věc, a zabezpečení je něco navíc. Mně tenhle přístup připadá zvrácený.

    do WP často dělají pluginy amatéři
    Jak je vidět, tak PHP evidentně pro amatéry není. Viz. běžní pisatelé pluginů . . . . .
    Už jste si rozmyslel, jak to tedy je?

    Každý vstup do aplikace a každý výstup je potenciálně nebezpečný. Některý více, některý méně. U webů to platí dvojnásob.
    Nevím, proč by to mělo u webů platit dvojnásob. Naopak u webů platí, pokud vynecháme upload souborů, že každý vstup je text. Co je na textu nebezpečného? On se vám někdy text v aplikaci třeba sám od sebe spustil? Na textu nic nebezpečného není, nebezpečná je jeho interpretace. A funkce pro uložení textu do databáze nemá text nijak interpretovat, má text vzít tak jak je a bez jakékoli změny ho uložit do databáze. Na tom není nic komplikovaného, a pokud s tím programy na nějaké platformě mají notoricky problém, je to problém té platformy.

    A ona by to měla řešit nějaká knihovna, protože obecně platí, že programátor při použití knihovních funkcí méně zapomíná udělat nějaký jeden krok z několika.
    Ano. A proto má mít funkce ve standardní knihovně pro volání SQL příkazů přímo podporu pro předávání hodnot parametrů. Protože to potřebuje prakticky každá aplikace pracující s databází a používá se to ve spoustě příkazů, takže nedává žádný smysl, aby si to každý programátor řešil znova sám. Zvlášť když na tom závisí bezpečnost aplikace. Zejména když stejně musí existovat varianta bez množiny parametrů nebo s prázdnou množinou, protože některé SQL příkazy parametry nemají – takže pokud někdo má potřebu vyřešit si předávání parametrů sám, nic mu v tom nebrání a prostě si ten dotaz poskládá sám a použije tu bezparametrickou variantu funkce. Negativa takového řešení neexistují žádná.

  • 28. 9. 2017 17:34

    to_je_jedno

    Nedavno jsem videl prednasku na ktere prednasejici pomerne presvedcive tvrdil*, ze statements v PHP jiz rezii nemaji protoze i "obycejna" query se pripravi jako statement a pak se poslou prazdne argumenty.

    * ja tomu verim, ale nejsem ochoten to vydavat za svoje tvrzeni protoze jsem to uvnitr nezkoumal

  • 28. 9. 2017 17:27

    to_je_jedno

    PDO je v PHP v roce 2017 naprosty standard. Asi nepotkavas programatory, ale zacatecniky. Proc bych to vlastne mel delat jinak? Krom toho zrovna v tom Drupalu celou query stavim objektove takze udelat dnes v Drupalu sql injection pri pouziti API neni uplne easy. A jsme mozna zpatky u toho rozdilu proc jej povazuji oproti WP za etalon bezpecneho SW.
    A jestli nekdo dnes pouzije navod z roku 2005 tak si nemyslim, ze je to uplne vina jazyka.

    Jinak ano, taky bych byl pro totalni vyhozeni starych mysql funkci z celeho jazyka. PHP7 bylo k tomuto dobra sance, ale evidentne nekdo na to nemel gule.

  • 28. 9. 2017 12:09

    Filip Jirsák

    Problem s architekturou PHP neni. Tvurci Symfony, Laravelu nebo Drupalu dokazi delat bezpecny SW i v PHP.
    Ta druhá věta ovšem tu první nijak nedokazuje. To, že lze v něčem psát i bezpečný software, neznamená, že k tomu to prostředí vede a že by pro programátora bylo obtížné napsat software nebezpečně. Ty chyby, které se ve WP neustále opakují (injekce kódu, ať už SQL, PHP nebo JS), jsou přesně v tom, k čemu jsou programátoři PHP neustále vedeni, ať už přímo PHP nebo obvyklými postupy. Je to podobné,jako s buffer overflow chybami v C – v programech napsaných v C se neustále opakují, protože je na ně C náchylné a programátor tu chybu snadno udělá. Teoreticky můžete nějakou buffer overflow chybu vyrobit i v PHP (myslím přímo v PHP kódu, ne v PHP interpretu) – ale bude vás to stát značné úsilí a běžně takovou chybu v PHP aplikaci nevyrobíte.

  • 28. 9. 2017 17:37

    to_je_jedno

    Hele takhle, nerikam, ze je to vsespasne, ale pouzit nejakou objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig) a drtiva vetsina problemu je vyresena. To, ze neco takove WP neumi do sebe dostat neni otazka jazyka. Nerikam, ze to dela aplikaci bezpecnou samo o sobe, ale vymyslet tam pak nejaky XSS/SQL-i je pomerne slozitejsi.

  • 28. 9. 2017 17:53

    Filip Jirsák

    Já ale nikde netvrdím, že je to s PHP neřešitelné. Samozřejmě, že to řešit jde, ať už prostředky standardní knihovny, nebo nějakou nadstavbou. Problém je, že to není standard – pokud i dnes někdo bude zjišťovat, jak v PHP zavolat dotaz nad MySQL, s největší pravděpodobností narazí (v lepším případě) na mysqli_query().

  • 28. 9. 2017 18:12

    Vláďa Smitka

    To také není úplně pravda. WP má WP_Query pro přístup k většině datům bez SQL příkazů (je pravda, že výsledné SQL dotazy jsou často dost hrozné, ale umí to i cachovat, takže se to trochu kompenzuje). Dále má svou vrstvu wpdb, která samozřejmě umí prepared statements (což je oficiálně doporučovaný postup) a metody pro vkládání/updaty data automaticky escapují. Pak je zde samozřejmě metoda query(), která vykoná dotaz jak leží - zde spoléhá na pisatele, aby si ho ošetřil (a když si není jistý jak, je zde funkce esc_sql, která to zařídí). Pokud někdo chce používat Twig, tak samozřejmě také může: https://github.com/timber/timber.

  • 28. 9. 2017 18:37

    Filip Jirsák

    To také není úplně pravda.
    Vždyť sám píšete:

    Pak je zde samozřejmě metoda query()
    Vida, takže přeci jen to pravda je.

    která vykoná dotaz jak leží - zde spoléhá na pisatele, aby si ho ošetřil
    Proč? K čemu je taková funkce dobrá? Kdyby ta funkce jako druhý parametr brala pole parametrů, radši to programátor použije, než by hodnoty vkládal do dotazu ručně. A programátora, který to nezná, by to nejspíš aspoň trklo, že se to takhle dá použít. A pokud by někdo opravdu potřeboval hodnoty do dotazu vložit ručně, pořád by měl možnost to udělat a pole parametrů předat prázdné. Pořád by tu byl prostor pro chyby, ale aspoň by to k těm chybám programátora nenavádělo.

    je zde funkce esc_sql, která to zařídí
    Tyhle funkce, které „to zařídí“, jsou snad ještě větší zlo. Escapování parametrů je špatné samo o sobě, a když se k tomu ještě přidá funkce, která „to zařídí“ a programátor netuší, co a proč vlastně dělá, je to na nejlepší cestě, aby někde něco oescapoval dvakrát, pak to zjistí, escapování odstraní a vyrobí tím SQL injection, a ještě si bude pamatovat, že to příště nemá používat, protože „to nefungovalo“.

  • 28. 9. 2017 18:57

    Vláďa Smitka

    Reagoval jsem na "nemá objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig)" - mohu přistupovat k DB přes objekty WP_Query, mohu používat knihovnu, která přidává abstraktní vrstvu, který spousty věcí ošetří, mohu používat Twig, když chci.

    Možnost zavolání dotazu přímo mají snad všechny systémy. Proč je v Javě Statement, když mám používat PreparedStatement?

  • 28. 9. 2017 19:24

    Filip Jirsák

    Reagoval jsem na "nemá objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig)"
    Aha. Jenže to nikdo před vámi nenapsal.

    mohu … když chci
    To je právě ten problém, že nejprve musíte vědět, že něco takového chcete. Zrovna mezi vývojáři pluginů do CMS se dá čekat spousta těch, kteří normálně neprogramují, a jenom potřebují přidat nějakou funkci do CMS.

    Možnost zavolání dotazu přímo mají snad všechny systémy.
    Samozřejmě. Jsou i zcela legitimní dotazy, které nemají žádné parametry. Abyste tomu zabránil, musel byste mít přímo v jazyce podporu pro textové konstanty, jejichž typ by byl odlišný od dynamicky vytvářených řetězců. Ale jak už jsem tu mnohokrát napsal, nejde o to, že něco jde – podstatné je, co se v daném prostředí považuje za běžný postup, na co narazíte v návodech a tutoriálech.

    Proč je v Javě Statement, když mám používat PreparedStatement?
    Jak už jsem psal, považuju za chybu, že statement nemá rovnou jako druhý parametr mapu parametrů s tím, že by JDBC driver povinně musel umět binding parametrů. Na druhou stranu, nevím o tom, že by se někde v oficiální dokumentaci Javy vyskytovalo skládání SQL příkazu z parametrů, Statement, PreparedStatement a CallableStatement jsou v oficiální dokumentaci uváděny dohromady s tím, že Statement je určeno pro jednoduché SQL příkazy bez parametrů a pro statické dotazy, zatímco PreparedStatement pro dotazy s parametry. V žádných návodech se nemotá hlava programátorům nějakým escapováním parametrů, a metoda pro escapování parametrů byla přidána až v Javě 9 (vyšla před pár dny) – asi aby se nestýskalo PHP programátorům, kteří přejdou na Javu.

  • 28. 9. 2017 21:24

    Pavel Stěhule

    Je celá řada SQL příkazů, které např. nemají prováděcí plán, a tudíž nemají parametry a tudíž je nesmysl, aby se pro ně používalo API pro prepared statements.

    Tady s Filipem nesouhlasím - je nesmysl, aby za problémy mohlo PHPko PHP je víc na ráně: pořád se používá v drtivé většině webů, díky minimálním vstupním nákladům je používaný v low cost projektech, kdy a kde jsou pro velkou část vývojářů bezpečnost, věci kolem výkonosti, kvality kódu nepodstatný detaily, které jdou mimo ně, nebo které se jim při té ceně nevyplatí řešit.

    Problémy se znalostma programátorů jsou všude - pokud se firmy nejsou úplně low cost, tak a) jejich problémy jsou méně viditelné, b) sem tam si zaplatí školení, případně odborně zdatnější (a povětšinou výrazně dražší) programátory, c) někdy mají specialisty na bezpečnost.

    Java nebo Python se low costu neprosadí - na to už potřebujete technicky zdatnější programátory - a ti nejsou pro low cost zaplatitelní. Pokud PHP používají proškolení a technicky zdatní vývojáři, tak problémy jsou obdobné jako jiné dynamické jazyky.

  • 28. 9. 2017 21:51

    Filip Jirsák

    Pavel Stěhule: To přece ale vůbec neznamená, že není možné dát low cost programátorům do ruky nástroj, který je povede k bezpečnému použití. Právě naopak, oni takový nástroj potřebují nejvíc. Není potřeba používat speciální API pro prepared statements – úplně stačí metoda execute() nebo query(), která bude mít jako první parametr text se zástupnými znaky a jako druhý volitelný parametr mapu nebo seznam hodnot parametrů. Nezáleží na konkrétní implementaci, jde o to, že když programátor bude chtít do SQL příkazu vložit parametry, bude mít správnou funkci hned po ruce a nebude zbytečně vymýšlet vylomeniny.

  • 28. 9. 2017 22:56

    Pavel Stěhule

    V PDO je o jednu instrukci navíc - musí se volat PREPARE - což má taky svůj smysl (může se umístit mimo cyklus). Navíc, díky dynamice PHPka to jde jednoduše zawrapovat.

    Jádro pudla je v tom, že programátoři (ti, kteří dělají chyby o kterých se tady bavíme) jen matně tuší, co to je SQL injection a pravděpodobně vůbec nebudou tušit, co to je prepared statement. Takže i kdyby ve funkci query bylo možné použít parametry, tak je nepoužijí, bo nebudou tušit proč.

    Třeba ještě s v ADO ve VB byl opruz používat prepared statements, a to se o PHP vůbec říct nedá.

  • 28. 9. 2017 23:04

    Filip Jirsák

    Podle mne pokud by ti programátoři v dokumentaci nebo v okolním kódu viděli třeba tohle:

    $mysqli->execute("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)", $code, $language, $official, $percent);

    budou to používat.

  • 28. 9. 2017 23:33

    Pavel Stěhule

    Mohlo by to být více zdůrazněné, ale když si teď listuji dokumentací k PDO i k mysqli, tak všechny příkazy s parametrizací dělají přes prepare. Takže pokud si dá člověk trochu víc práce a prolítne dvě html stránky místo jedné, tak na všech adekvátních příkazech najde PREPARE. Je fakt, že některé příklady v dokumentaci ke query jsou asi spíš na škodu.

    Tady ještě může hrát roli MySQL - pokud se použijí prepared statements, tak se použije binární protokol a budete dostávat typová, kdežto, když defaultní textový protokol vrací jenom texty, jestli jsem to pochopil. Takže výsledek (metadata) může být jiný pokud použijete nebo nepoužijete parametry.

  • 29. 9. 2017 9:02

    Filip Jirsák

    Já tedy v dokumenatci MySQLi vidím něco úplně jiného. Když vezmu stránky postupně podle obsahu, první stránka, kde se objevují parametrizované dotazy, je Executing statements . Parametry INSERT u jsou tam přímo součástí příkazu, což v reálné aplikaci nedává vůbec žádný smysl – a vše je tam pomocí query, o prepare na té stránce není jediná zmínka. Evidentně i autoři PHP považují prepare za něco speciálního, co se nepoužívá pro běžné vykonávání příkazů. Následuje kapitola Prepared Statements, kde se hned v druhé větě píše, že se to používá pro opakované opakované vykonávání stejných příkazů z důvodu vysoké efektivity. Pokud to čte začátečník, správně si řekne, že optimalizace zatím není nic pro něj, stejně bude zatím používat jen jednoduché příkazy. Následuje kapitola o uložených procedurách, kde jsou všechny parametry opět natvrdo součástí SQL příkazu. prepare je tam uvedené jednou – bez parametrů. Následuje několik dalších kapitol s query a parametry, které jsou natvrdo v SQL příkazu, takže příklady, které nemají nic společného s reálnými aplikacemi – a pokud se jimi někdo inspiruje, logicky dospěje k tomu, že ty konstantní parametry akorát nahradí odkazem na proměnnou. Přitom jinak jsou ty příklady vzorové, všude se testují návratové kódy – tak, jak by ten kód měl vypadat v reálné aplikaci. Kapitoly o instalaci a podobné asi můžeme přeskočit, následuje už dříve odkazovaná stránka MySQLi extension basic examples, kde o prepare opět není ani zmínka, naopak se obsah proměnné vkládá přímo do SQL příkazu. Přitom tohle je ta stránka, odkud začne každý, kdo jenom rychle potřebuje vědět, jak se volají dotazy do databáze. A většina programátorů u téhle stránky taky skončí, protože podle ní napíšou svůj kód, vyzkouší, kód jim vrátí správná data, a tím to pro ně končí, nebudou mít důvod číst něco dalšího – vždyť jim to přece funguje. Zpět k tomu příkladu – na začátku v komentáři sice je zmínka o SQL injection a že se kvůli tomu přetypovává na int, ale kdo ten komentář bude číst? A i když si ho někdo přečte – „Handling all of this goes beyond the scope of this simple example.“ Takže SQL injection a bezpečnost je něco pro pokročilé, začátečníci o tom nepotřebují vědět nic. Když pak někdo tenhle příklad vezme, akorát místo čísla bude potřebovat použít jako parametr text, hned má přímo ukázkový kód s SQL injection – aniž by vůbec tušil, že je něco špatně.

    Autoři PHP zjevně považují prepared statements za něco pokročilého, co si najde ten, koho to opravdu zajímá. Zároveň PHP neumí bindování proměnných jinak, než s prepared statements. PHP zkrátka programátorům doporučuje nástroj, který je (zbytečně) náchylný k SQL injection, a navíc tuhle vážnou bezpečnostní hrozbu odbude poznámkou pro zasvěcené, místo aby tam byl výrazný červený nápis s vykřičníky, že takhle se to dělat nemůže. Tohle prostě je problém platformy PHP a vysvětluje to, proč je tolik PHP aplikací napadnutelných přes SQL injection.

    Interní implementace prepared statements v MySQL v tom nemusí hrát žádnou roli, parametrizované dotazy s bindováním proměnných není vůbec nutné implementovat přes prepared statements – klidně může dvouparametrická funkce query() interně pomocí escapování skládat parametry do textového dotazu. Sice považuju escapování za hack, ale pořád je to milionkrát bezpečnější, když to ta funkce bude dělat takhle, než nechávat to na tom, jestli programátor vůbec tuší něco o SQL injection a vzpomene si, že to má nějak řešit.

  • 29. 9. 2017 8:52

    to_je_jedno

    // úplně stačí metoda execute() nebo query(), která bude mít jako první parametr text se zástupnými znaky a jako druhý volitelný parametr mapu nebo seznam hodnot parametrů.

    Tohle je naprosto naivní představa
    $db->query("select * from users where password = $_POST['passwor­d']", array());

    tak takhle nejak si predstavujes zabezpeceni proti amaterovi/zaca­tecnikovi?

  • 29. 9. 2017 10:17

    Filip Jirsák

    Tohle je naprosto naivní představa
    Klidně vám to napíšu počtvrté, že když někdo v příkladech v dokumentaci uvidí použití s parametry, tak pak sám napíše

    $db->query("select * from users where password = ?", array($_POST['password']));

    – protože je to jednodušší a přehlednější. Že se pořád najde někdo, kdo mermomocí ten kód bude muset napsat špatně, tomu se zabránit nedá, ale jde o to, co se používá normálně.

  • 29. 9. 2017 15:41

    to_je_jedno

    naivni predstava. totalni novacek neznaly zakladnich bezpecnostnich pravidel tam stejne mrskne sql tak jak si ho nekde precetl.

  • 29. 9. 2017 16:45

    Filip Jirsák

    Pokud by to byl takový hňup, že by ani nevěděl, že musí v SQL napsat podmínky, co chce vlastně vybrat, tak to vůbec nevadí. Za prvé by mu zkopírované SQL vůbec nefungovalo, protože by tam měl názvy tabulek a sloupců, které by neměl ve své databázi, za druhé by v tom zkopírovaném SQL nebyly žádné vložené parametry, takže žádný prostor pro SQL injection.

  • 29. 9. 2017 18:58

    j (neregistrovaný)

    Tj, leda debil jako jirsak muze predavat password do databaze v podobe textu, coz jednoznacne znamena, ze ty hesla jako text i skladuje.

    Jinak se to jirsak dela tak, ze u kazdyho pole se pomerna jasne vi, co obsahovat muze a co obsahovat nemuze, coz je docela podstatny nejen kvuli SQLi. Takze kdyz o necem prohlasim, ze to je cislo, a sem na webu, kde vzdycky dostanu textovou podobu cisla, tak povoleny znaky snadno overim za pomoci [0-9\.,] ... coz si samozrejme dam nekam jako funkci a overim to u kazdyho vstupu kterej ma bejt cislo ....

    Anzto a protoze 0x621 je taky cislo zejo ... a pak ty vysledky podle toho vypadaj. Coz je mimochodem naprosta klasika .NET, protoze tam to bez osetreni zblajzne cisla v nekolika ruznych formach, at uz binarne nebo hexa ... naprosto vpohode. Ale jo, az mi nekdo zada do prikazu k uhrade 47e5 misto 4745 tak se zlobit nebudu.

  • 28. 9. 2017 22:31

    Ravise (neregistrovaný)

    Ad query, když má počítač vykonat to, co mu někdo řekne, je to špatně? Měl jsem pocit že programátor je tu od toho aby říkal počítači co má dělat... A dětem a blbcům zkrátka sirky do ruky nepatřej.