Dotaz: Kontrola sql dotazu v php

[Orlando]

Zdravím všechny, prosím o kontrolu sql dotazu. Poradí prosím někdo, jestli takto napsaný sql dotaz splňuje dostatečné zabezpečení jelikož data posílá z formuáře uživatel. Třeba u toho datumu si nejsem vůbec jistej Děkuji všem za pomoc, obracím se zde, jelikož neexistují sránky, které by nabízely validní a zabezpečené příklady sql dotazů a byli z roku více než 2002 Ještě jednou moc děkuji.

<?php

     $_POST['name'] = htmlspecialchars($_POST['name']);
     $_POST['last'] = htmlspecialchars($_POST['last']);
     $_POST['pass'] = htmlspecialchars($_POST['pass']);

     $query = "INSERT INTO `registrace` (`name`, `last`, `pass`, `datum`, `status`) VALUE
                                             ('".mysql_real_escape_string($_POST['name'])."',
                                              '".mysql_real_escape_string($_POST['last'])."',
                                              '".mysql_real_escape_string($_POST['pass'])."',
                                              NOW(),
                                              ".intval(0).")";
?>

---

---

Odpovědi

[ScheRas]

Pokud máte tím datem na mysli volání funkce NOW(), tak to by mělo být v pořádku. Do toho totiž uživatel vůbec nezasahuje, tudíž není možnost, jak s ní ovlivnit chod databáse. A ostatní? Pokud neposíláte výstup do javascriptu, nebo něco podobného, tak je to v pohodě. Jen bych doporučil definovat u htmlspecialchars() také kódování. Viz dokumentace

[Orlando]

U toho datumu jsem myslel, jesli se má dát do nějakých uvozovek, apostrofů nebo tak něco. Jinak tedy ten htmlspecialchars() by měl vypadat takto? Děkuji

     $_POST['name'] = htmlspecialchars($_POST['name'], 'UTF-8');
     $_POST['last'] = htmlspecialchars($_POST['last'], 'UTF-8');
     $_POST['pass'] = htmlspecialchars($_POST['pass'], 'UTF-8');

[Kit]

Do pole $_POST nikdy nezapisuj. Raději použij další proměnné $name, $last, $pass. Kromě získání vyšší přehlednosti tím ušetříš i trochu paměti.

htmlspecialchars() se nepoužívá při zápisu do DB, ale až před prezentací v HTML.

[ScheRas]

Musí to vypadat takto, protože podle dokumentace se na druhém místě při zápisu očekává něco jiného. Tedy:
htmlspecialchars($nazev ,none, 'UTF-8');

[ScheRas]

A jak už bylo řečeno, je blbost používat htmlspecialchars() při vkládání dat do databáze. To jsem měl asi zmínit dřív.

[Filip Jirsák]

Těžko říct, to záleží na tom, co dělá funkce mysql_real_escape_string, například zda používá syntaxi, která do posledního puntíku odpovídá parseru MySQL, kterou právě používáte. Já bych na to nespoléhal, a raději bych použil parametrizovaný dotaz, který je bezpečnější, podle mne přehlednější a snáze se používá, a ještě umožní dělat lepší optimalizace (prostě samá pozitiva a sociální jistoty).

$stmt = $dbh->prepare("INSERT INTO `registrace` (`name`, `last`, `pass`, `datum`, `status`) VALUES (?, ?, ?, now(), 0)");
if ($stmt->execute(array($_POST['name'], $_POST['last'], $_POST['pass']))) {
  …
}

htmlspecialchars() bych si nechal až na případný výstup, zvlášť u toho hesla je to spíš chyba – když uživatel zadá heslo „I<3you“, asi bude při přihlašování psát také „I<3you“ a ne „I&lt;3you“.

[Orlando]

Tak jsem to zkusil použít, ale vrací mi to error: Fatal error: Call to a member function prepare() on a non-object in.... objektové programování neovládám, tak netuším o co jde..

[Filip Jirsák]

Ten příklad samozřejmě nebude fungovat takhle sám o sobě, je potřeba se připojit k databázi atd. V $pdh jsem předpokládal objekt připojení k databázi, třeba výsledek volání

$dbh = new PDO('mysql:host=localhost;dbname=db', 'user', 'pwd');

Podívejte se na dokumentaci PHP Data Objects.

[ScheRas]

Tak čistě teoreticky by uživatel mohl dále zadávat ono "I<3you", ale muselo by se při porovnávání s db také použít htmlspecialchars(). Ale ve výsledku je to tady zbytečné používat samozřejmě.

[Kit]

Teoreticky ano, ale jako záznam v DB by to vypadalo dost blbě. Dále by se s tím obtížně pracovalo, pokud bychom někde potřebovali původní string, například při výpisu do textového souboru. Pokud bych chtěl jen první 2 znaky, místo očekávaného "I<" bych dostal "I&". Pokud bych měl limit délky jména na 8 znaků, "I<3you" by se de facto zkrátilo na "I<3yo" apod.

Funkce htmlspecialchars() slouží k ošetření výstupu řetězce do HTML.

[ScheRas]

Jak říkám, použití htmlspecialchars() není na místě. Prostě jsem se soustředil pouze na to, říct, jestli je to v pohodě ošetřený a neřešil jsem, jestli je na místě použít zrovna tuto escapovací proměnou.

[xkucf03]

Ve výsledku je to hlavně špatně, protože máš pak databázi zasviněnou daty ve formátování pro jeden konkrétní výstup (HTML).

BTW: Bohužel tu mám po ruce jeden software za X milionů, kde to experti přesně takhle udělali – výsledkem je, že systém odesílá e-maily a v jejich předmětech (nebo i jinde) jsou HTML entity :-/ Což samozřejmě žádný poštovní klient neinterpretuje jako původní znaky, protože v e-mailu se zapisují jinak než v HTML.

[Kit]

Trochu bych to zkrátil, protože htmlspecialchars() se používá na výstupu a rozhodně se nezapisuje do pole $_POST.

$query = "INSERT INTO `registrace`
  (`name`, `last`, `pass`, `datum`, `status`) VALUES
  ('".mysql_real_escape_string($_POST['name'])."',
  '".mysql_real_escape_string($_POST['last'])."',
  '".mysql_real_escape_string($_POST['pass'])."',
  NOW(),0);";

Ovšem parametrizovaný dotaz by vypadal mnohem lépe a bezpečněji.

[Orlando]

Parametrizované dotazy vypadají opravdu zajímavě - leč to obnáší další učení a učení na které nemám momentálně čas a hlavně si nemůžu dovolit nějaky bug před dokončením aplikace. Jinak člověk se učí celý život ale co by mě hodně moc pomohlo, jo to, že kdyby byl někdo tak hodný a nastínil mě jak může někdo pomocí formuláře smazat mysql, nevěřím, že to je vážně tak jednoduché Zase kdybych věděl jak to funguje, jistě bych jinak přemýšlel nad bezpečností. Problém je v tom, že google na takové dotazy zarytě mlčí Sice jsem něco našel na WIKI ale to jsou spíše hodně povrchní nic neříkající informace. Opravdu bych přišel o data. Jinak hrozí opravdu jen ošetření dat které odesílá uživatel? Jiná hrozba není? Díky za pomoc.

[Kit]

Parametrizované dotazy mi umožnily zahodit učení o obskurním ošetřování vstupů různými mysql_real_escape_string() a jinými funkcemi závislými na použité databázi.

Smazání databáze přes formulář jsem viděl v reálu a není to ani moc složité. Ovšem popisovat to nebudu, protože díky systematickému používání parametrizovaných dotazů mě to už přestalo zajímat.

Hrozeb je samozřejmě víc. Stačí, když se někomu v důsledku chyby v aplikaci vytratí z SQL dotazu při mazání záznamu WHERE i s podmínkou apod.

[xkucf03]

jak může někdo pomocí formuláře smazat mysql

Takhle: Maminčiny exploity

Útočník využije dvou tvých chyb:

• Stačí na jediném místě zapomenout správně escapovat vstup.
• Nerespektuješ zásadu minimálních práv: každý subjekt (v tomto případě aplikace resp. uživatel, pod kterým pracuje) by měl mít pouze ta práva, která skutečně potřebuje. Aplikace obvykle nepotřebuje mazat tabulky, často ani nepotřebuje mazat data v těch tabulkách – proto by ani neměla mít příslušná práva.

[Orlando]

To máte sice pravdu, ale na druhou stranu jestli zakážu v mysql mazání dat nic nevyřeším, jelikož pokud mi útočník db smaže, nebo ji přepíše nějakými nahodnými znaky bude ve finále úplně jedno, v obou případech následuje konec! Jelikož přepisování dat aplikace umožňovat musí... Co by pomohlo, nebo aspoň minimalizovalo problém by bylo to, že by šlo nastavit každé tabulce jiné práva, ale toho se obávám, že to asi nejde...

[xkucf03]

Vždyť taky na každou tabulku můžou být jiná práva – některé budou jen pro čtení, jiné budou i pro zápis a některé třeba nepůjdou ani číst a bude se k nim přistupovat jen přes uložení procedury. Některé databázové systémy dokonce umožňují nastavovat práva pro jednotlivé sloupečky.

Jinak co se týče smazání dat, tak existuje jednoduché řešení – zálohovat.

Neříkám, že je to všespásné – nějaká práva aplikace potřebuje a ta se dají zneužít, pokud získá útočník přístup – ale přesto se tuhle zásadu vyplatí dodržovat.

[Filip Jirsák]

Myslím, že naučit se používat parametrizované dotazy a použít je bude nakonec rychlejší, než kontrolovat veškerý starý kód na správné použití escapovacích funkcí. A jako bonus získáte přehlednější a snáze udržovatelný kód a mnohem větší jistotu, že máte přístup k databázi ošetřen správně.

A příklad, co se může stát? Když vám někdo do formuláře vyplní do políčka name text "Pepa", je to něco, s čím počítáte a z čeho vznikne následující dotaz:

INSERT INTO `registrace` (`name`, `last`, `pass`, `datum`, `status`)
  VALUE ('Pepa', 'Novák', 'neřeknu', NOW(), 0)

Taky vám tam ale může vyplnit tohle:

', 'Novák', 'neřeknu', NOW(), 0); DROP DATABASE;  -- 

A pak dostanete (bez escapování) tenhle příkaz:

INSERT INTO `registrace` (`name`, `last`, `pass`, `datum`, `status`)
  VALUE ('Pepa', 'Novák', 'neřeknu', NOW(), 0);
DROP DATABASE;
  -- ', 'Novák', 'neřeknu', NOW(), 0)

Záleží pak na tom, co dělá escapovací funkce -- ale pokud se přes ni podaří protlačit data, aby dala takovýhle výsledek, provede se dotaz úplně stejně. Ta escapovací funkce je přitom závislá na spoustě věcí -- verze MySQL databáze, kódování vstupu a výstupu atd. Těžko to bude ve všech kombinacích fungovat správně jen tak bez nějakého dalšího nastavování. Takže náhodný kolemjdoucí, který jen zkusí zadat jednu variantu textu do formuláře, vám databázi asi nesmaže, ale pokud bude mít někdo motivaci, zjistí si verzi databáze, PHP, kódování vstupů a výstupů, má už mnohem větší šanci na úspěch.

[Orlando]

Hm, bez urážky, jestli jsem to dobře pochopil tak říkáte tohle?

User vyplnil text Pepa

formulář bude tedy vypad takto
<input type="text name="name" value="Pepa" /">

a v php dostanu tohle
echo $_POST['name']; // Pepa

ale taky to může být takto

User vyplnil text ', 'Novák', 'neřeknu', NOW(), 0); DROP DATABASE;  -- 

formulář bude tedy vypad takto
<input type="text name="name" value="', 'Novák', 'neřeknu', NOW(), 0); DROP DATABASE;  -- " /">

a v php dostanu tohle
echo $_POST['name']; // ', 'Novák', 'neřeknu', NOW(), 0); DROP DATABASE;  -- 

Pochopil jsem to správně? Jestli ano tak k tomu mám dvě věci (z pohledu lajka)

1) znaky ',()0;- nemají ve jménu co dělat //lenost programátora
2) aby tohle uhodl, musel by být kouzelník 

Pokud to tedy shrnu, tak pokud programátor ošetří třeba pomocí reg. výrazu input name jake znaky může user použít, tak nemusí již dál nic řešit, jelikož útočník nemá sebemenší šanci se nějak nabourat. Ale třeba se mi snažíte říct něco úplně jiného a já to nepochopil. Děkuji

[xkucf03]

znaky ',()0;- nemají ve jménu co dělat //lenost programátora

Tohle je až druhotný problém. V první řadě nesmíš dovolit, aby se vstup od uživatele vykonával jako SQL dotaz – smí být pouze parametrem dotazu, který jsi napsal a zkontroloval ty. Tohle je základ.

Jestli kontrolovat povolené znaky a dělat nějaká další omezení, to je věc druhá – nicméně to se nedělá (nemělo by) kvůli bezpečnosti (tu zajistíš viz výše), ale kvůli nějakému většímu pořádku v datech – např. zakážeš mezery, aby uživatel nenacpal jméno a příjmení do jednoho políčka a správně je rozepsal do dvou. Taky můžeš omezit znaky na A-Ž. Jenže pak ti tam přijde člověk např. s francouzským jménem a tam jsou i jiné znaky, takže se nebude moci registrovat. A podobné zbytečné problémy, na které sis sám zadělal. Tahle omezení doporučuji stanovovat s rozvahou a nestavět na nich bezpečnost – ta by měla stát na těch parametrizovaných dotazech.

A další věc je výstup aplikace – v případě webové je to (X)HTML – tam je potřeba zase ošetřit znaky, aby útočník do tvé aplikace nevložil např. svoje JavaSkripty. Sice když omezíš znaky ve jméně na A-Ž, tak tam skript nevloží, ale je to špatné řešení – spolehlivé je všechny výstupy escapovat – buď ručně voláním funkce nebo použít nějaký šablonovací nástroj. To je spolehlivé a opět je ti jedno, že někdo do jména zadal jakkoli nesmyslné znaky – stránku ti to nenaruší a ostatní uživatele neohrozí.

aby tohle uhodl, musel by být kouzelník

Najdi si něco o „SQL injection“ – skutečně to takhle chodí a útočník nemusí být kouzelník – hodně věcí je předvídatelných a zbytek se dá dohledat postupným zkoušením – když někdo takhle zprasí aplikaci, tak často taky neskrývá chybové hlášky, tzn. zobrazí se chybová hláška, kterou vyplivla SQL databáze – a z ní útočník získá další zajímavé informace. Pak je tu schéma, ze kterého zjistí názvy tabulek a sloupečků atd.

[Filip Jirsák]

znaky ',()0;- nemají ve jménu co dělat //lenost programátora

Nojo, ale vždyť vy to tam nikde ošetřené nemáte.

aby tohle uhodl, musel by být kouzelník

Nemusel. MySQL při některých nastaveních zkonvertuje kdeco do kdejakého sloupečku, spousta sloupců může mít povolenu hodnotu NULL, mají výchozí hodnoty -- takže může stačit uhodnout počet sloupců, což je na pár pokusů. Zvlášť když budete chybové zprávy vypisovat do stránky.

[Kit]

formulář bude tedy vypad takto

<input type="text name="name" value="', 'Novák', 'neřeknu', NOW(), 0); DROP DATABASE;  -- " /">

Formulář tak rozhodně vypadat nebude. To je jen naivní představa některých vývojářů. Možná to tak prezentuje nějaký debugger.

1) znaky ',()0;- nemají ve jménu co dělat //lenost programátora

To bych chtěl vidět, jak to chceš ošetřovat. Proč by někdo nemohl mít v nickname "0"? Které z několika desítek tisíc znaků jsou podle tebe závadné? Rozhodně jsi všechny nevyjmenoval.

2) aby tohle uhodl, musel by být kouzelník

Takového "kouzelníka" jsem viděl při akci. Ani nebyl moc znalý ani šikovný, ale v druhém panelu si otevřel nějakou stránku s nápovědou a bylo to.

Pokud to tedy shrnu, tak pokud programátor ošetří třeba pomocí reg. výrazu input name jake znaky může user použít, tak nemusí již dál nic řešit, jelikož útočník nemá sebemenší šanci se nějak nabourat.

Tak takový regulární výraz bych chtěl vidět. Navíc tím poškodíš i to, co poškodit nesmíš. Například velmi často se ve jméně vyskytuje apostrof. Když to změníš, tak si někdo může stěžovat. Nebo snad chceš dotyčnému vystavit občanku s backslashem před apostrofem ve jméně?

Také jsem si nechal jedno "nedobytné" fórum rozbít od jednoho testera. Povedlo se mu to 3x, počtvrté už ne. Ovšem stále jsem neměl plnou jistotu, že mám ošetřeno všechno. Těch znaků, které mi to fórum úspěšně demolovaly, bylo mnohem víc, než zmíněné ',()0;-.

Nakonec neošetřuji žádné a tester to vzdal. Stačilo použít parametrizované dotazy a už si neškrtl. Kód programu se zkrátil a zjednodušil. Co víc si přát?

[Orlando]

Jinak se naskýtá otázka, je programování v php budoucnost, když si to samo php nedokáže ohlídat? A jistě za ty léta ví kde je zakopaný pes....

[Kit]

Ale PHP si to dokáže ohlídat velmi dobře. Stačí použít ovladač MySQLi nebo PDO. Původní ovladač MySQL se drží už jen z historických důvodů, na nové projekty se nepoužívá.

[xkucf03]

Ale tyhle chyby můžeš dělat v libovolném jazyce – žádný ti nezabrání v tom, aby sis SQL řetězec „poslepoval“ z neošetřených vstupů a poslal do databáze. PHP má parametrizované dotazy už pěknou řádku let. Takže jakkoli můžu mít k PHP výhrady, tohle není jeho chyba, ale chyba programátorů – bastlířů.

[Filip Jirsák]

Samo PHP neví, co chcete udělat. Pokud nějak poskládáte SQL příkaz a předáte ho PHP k provedení, PHP očekává, že ten příkaz chcete provést, a nemá šanci poznat, jestli mu nepředáváte nějaký příkaz, který ve skutečnosti provést nechcete.

Jenže vy ve skutečnosti nechcete skládat různé SQL příkazy, chcete provádět stále jeden a týž příkaz a jenom měnit jeho parametry. A k tomu právě slouží MySQLi nebo PDO. Pak už si to PHP dokáže ohlídat, protože mu dáte zvlášť příkaz a zvlášť parametry, takže může zajistit, aby parametry nebyly interpretovány jako nějaký příkaz.