sql >> Databáze >  >> RDS >> Mysql

Base64 jako metoda dezinfekce uživatelského vstupu pro Mysql

Nedezinfikujte vstup jako prostředek k zabránění vkládání SQL - použijte zástupné symboly (nebo správné escapování) , vždy. Být konzistentní. Být v bezpečí. Problém je již vyřešen.

Tento případ bude "bezpečný" vzhledem k omezené doméně z base64_encode funkce. Nicméně...

Je špatný postup a ukládání hodnot zakódovaných v base64 (tak, aby zobrazený dotaz mohl fungovat) s sebou nese několik negativních důsledky, jak se mění uložené informace:ničí řazení hodnot činí informace netriviálně vyhledatelné , vyžaduje další krok „kódování/dekódování“ a dokonce spotřebuje více místa – aha!

I když tedy mohou existovat specifické případy pro data kódování base64, tento přístup není dobře se hodí jako prostředek ke zmírnění vkládání SQL .

Problém je způsoben přístupem k SQL přes textový protokol kde je dotaz příkaz/tvar a hodnoty jsou promíchané. Použití správného únikové techniky (např. mysql_real_escape_string ) to řeší tím, že zajistí, že informace budou escapovány, aby byl text SQL analyzován jak bylo zamýšleno – na rozdíl od kroku kódování base64 to však nedělá skutečně změnit poskytnuté informace!

Toto je přesně co zástupné symboly poskytují ! Zástupné symboly jsou všeobecně správný přístup a měl by být podporován. Zástupné symboly umožňují odeslání dotazu a hodnot do databáze samostatně pokud je podporována knihovnou/databází; a jsou emulovány útěkem jinak. Správné použití zástupného symbolu eliminuje SQL Injection a potřeba uživatelského kódu pro promíchání hodnot do textu příkazu SQL, což může také usnadnit psaní a údržbu dotazů.

Chcete-li zabránit „individuálním programátorům“ v psaní hrozných dotazů, řešením je zabránit ad-hoc dotazy před rozptýlením v kódu:shromážděte operace přístupu k datům do vrstvy přístupu k datům ( DAL) (případně ve spojení s ORM) a odhalit pouze relevantní akce zajišťující správné použití SQL v rámci DAL. V jednodušších projektech je DAL také vhodným místem pro centrální správu obchodních pravidel pro sanitaci a další logiku ověřování.

Přesněji:

  • Dezinfikujte hodnoty pro obchodní pravidla; to by mělo zabránit „špatným informacím“, jako je uživatelské jméno, které je příliš krátké, obsahuje omezené znaky nebo jinak nesplňuje obchodní požadavky.

  • Používejte zástupné symboly zabránit vkládání SQL . Toto je přísně související s přenosem dat do SQL a nemá žádný vliv na informace v nich obsažené.

Zatímco MySQL 5.6.1 přidává FROM_BASE64 , takže kódování lze jednoduše použít v textu příkazu SQL, to stále přidává další explicitní krok dekódování a komplikuje dotaz při použití takového schématu kódování. Tento přístup base64 prostě není nezbytné, protože již existují osvědčené techniky, jak zabránit vkládání SQL, a nebyl navržen v původní otázce.



  1. Jak funguje SQLite Total()

  2. Jak předat seznam z Java do Oracle Procedure?

  3. mysql/php je toto bezpečný způsob připojení k mysql DB?

  4. Více cizích klíčů ve stejné tabulce