Děkuji za zajímavou otázku. Tady to je:
Uniká nebezpečným postavám,
Váš koncept je naprosto špatný.
Ve skutečnosti jsou „nebezpečné postavy“ mýtus, žádné neexistují. A mysql_real_escape_string escaping, ale pouze oddělovače řetězců . Z této definice můžete usuzovat na její omezení - funguje pouze pro řetězce .
stále je však zranitelný vůči jiným útokům, které mohou obsahovat bezpečné znaky, ale mohou být škodlivé pro zobrazení dat nebo v některých případech jejich modifikaci nebo mazání.
Všechno tady mícháte.
Když už mluvíme o databázi,
- pro řetězce NENÍ zranitelný. Dokud jsou vaše řetězce citovány a escapovány, nemohou "neoprávněně upravovat nebo mazat data".
* - pro ostatní data typu dat – ano, je to zbytečné . Ale ne proto, že by to bylo nějak "nebezpečné", ale jen kvůli nesprávnému použití.
Pokud jde o zobrazovaná data, předpokládám, že jsou offtopic v otázce týkající se PDO, protože PDO nemá nic společného ani se zobrazováním dat.
escapování uživatelského vstupu
^^^ Další klam, který je třeba poznamenat!
-
Uživatelský vstup nemá s escapováním absolutně nic společného . Jak se můžete naučit z předchozí definice, musíte uniknout řetězcům, ne jakémukoli „uživatelskému vstupu“. Takže znovu:
- máte escape řetězce, bez ohledu na jejich zdroj
- je zbytečné unikat jiným typům dat, bez ohledu na zdroj.
Chápete?
Nyní doufám, že chápete omezení útěku, stejně jako mylnou představu o "nebezpečných postavách".
Chápu, že používání CHOP/připravených výpisů je mnohem bezpečnější
Vlastně ne.
Ve skutečnosti jsou čtyři různé části dotazu, které do něj můžeme dynamicky přidávat:
- řetězec
- číslo
- identifikátor
- klíčové slovo se syntaxí.
takže můžete vidět, že escapování pokrývá pouze jeden problém. (ale samozřejmě, pokud čísla považujete za řetězce (v uvozovkách), pokud je to možné , můžete je také zabezpečit)
zatímco připravená prohlášení pokrývají - fuj - celá 2 čísla! Velká věc;-)
Další 2 problémy viz moje dřívější odpověď, Mám se v PHP při odesílání řetězců do databáze starat o nepovolené znaky pomocí htmlspecialchars() nebo použít regulární výraz?
Nyní se názvy funkcí liší, takže můj mysql_query, mysql_fetch_array, mysql_num_rows atd. již nebudou fungovat.
To je další, vážný blud uživatelů PHP , přírodní katastrofa, katastrofa:
I když používáte starý mysql ovladač, nikdy by se nemělo používat holé funkce API v jejich kódu! Člověk je musí dát do nějaké funkce knihovny pro každodenní použití! (Ne jako nějaký magický rituál, ale jen proto, aby byl kód kratší, méně se opakující, odolný proti chybám, konzistentnější a čitelnější).
Totéž platí pro CHOP!
Nyní znovu s vaší otázkou.
ale jejich použití eliminuje potřebu používat něco jako mysql_real_escape_string?
ANO.
Ale myslím, že toto je zhruba myšlenka toho, co by se mělo udělat pro získání uživatele z databáze
Ne k načtení, ale k přidání jakýchkoli dat do dotazu !
musíte zadat délku za PDO:PARAM_STR, pokud se nemýlím
Můžete, ale nemusíte.
Je to všechno bezpečné?
Pokud jde o bezpečnost databáze, tento kód prostě nemá žádná slabá místa. Není zde nic k zajištění.
pro zabezpečení zobrazení - stačí na tomto webu vyhledat XSS klíčové slovo.
Doufám, že jsem do této záležitosti vnesl trochu světla.
BTW, pro dlouhé vložky můžete použít funkci, kterou jsem jednou napsal, Vložit/aktualizovat pomocnou funkci pomocí PDO
V tuto chvíli však nepoužívám připravené příkazy, protože před nimi preferuji své domácí zástupné symboly využívající knihovnu Zmínil jsem se výše. Abychom odolali kódu, který zveřejnil riha níže, byl by krátký jako tyto 2 řádky:
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Ale samozřejmě můžete mít stejný kód také pomocí připravených příkazů.
* (yes I am aware of the Schiflett's scaring tales)