Zápis zabezpečeného dynamického SQL na SQL Serveru

Stáhnout ADO.NET

Injektáž SQL je proces, pomocí kterého uživatel se zlými úmysly místo platného vstupu zadá příkazy Transact-SQL. Pokud se vstup předá přímo na server bez ověření a pokud aplikace neúmyslně spustí vložený kód, může útok poškodit nebo zničit data.

Všechny procedury, které vytvářejí příkazy SQL, by se měly kontrolovat na zranitelnosti injekcí, protože SQL Server spustí všechny syntakticky platné dotazy, které obdrží. I parametrizovaná data mohou být manipulována zkušeným a určeným útočníkem. Pokud používáte dynamické SQL, nezapomeňte parametrizovat příkazy a nikdy nezahrnujte hodnoty parametrů přímo do řetězce dotazu.

Anatomie útoku prostřednictvím injektáže SQL

Proces injektáže funguje předčasně ukončením textového řetězce a připojením nového příkazu. Vzhledem k tomu, že před spuštěním příkazu k němu mohou být připojeny další řetězce, ukončí pachatel vložený řetězec značkou komentáře "--". Následující text se v době provádění ignoruje. Více příkazů lze vložit pomocí středníku (;) oddělovače.

Pokud je vložený kód SQL syntakticky správný, nelze manipulaci rozpoznat programově. Proto musíte ověřit veškerý uživatelský vstup a pečlivě zkontrolovat kód, který spouští vytvořené příkazy SQL na serveru, který používáte. Nikdy nezřetězujte uživatelský vstup, který nebyl ověřen. Zřetězení řetězců je primárním vstupním bodem pro injekci skriptu.

Tady je několik užitečných pokynů:

• Nikdy nevystavujte Transact-SQL příkazy přímo ze vstupu uživatele; k ověření uživatelského vstupu použijte uložené procedury.

• Ověřte vstup uživatele podle typu testování, délky, formátu a rozsahu. Pomocí funkce Transact-SQL QUOTENAME() uvozujte názvy systému nebo pomocí funkce REPLACE() libovolný znak v řetězci.

• Implementujte více vrstev ověřování v každé vrstvě vaší aplikace.

• Otestujte velikost a datový typ vstupu a vynucujte odpovídající limity. To může pomoct zabránit záměrnému přetečení vyrovnávací paměti.

• Otestujte obsah řetězcových proměnných a přijměte pouze očekávané hodnoty. Odmítne položky obsahující binární data, řídicí sekvence a znaky komentářů.

• Při práci s dokumenty XML ověřte všechna data ve schématu při jejich zadávání.

• Ve vícevrstvých prostředích by se všechna data měla před vstupem do důvěryhodné zóny ověřit.

• Nepřijme následující řetězce v polích, ze kterých lze vytvořit názvy souborů: AUX, CLOCK$, COM1 až COM8, CON, CONFIG$, LPT1 až LPT8, NUL a PRN.

• Pomocí SqlParameter objektů s uloženými procedurami a příkazy můžete zajistit kontrolu typů a ověření délky.

• Pomocí Regex výrazů v klientském kódu můžete filtrovat neplatné znaky.

Dynamické strategie SQL

Provádění dynamicky vytvořených příkazů SQL v procedurálním kódu přeruší řetěz vlastnictví, což způsobí, že SQL Server zkontroluje oprávnění volajícího proti objektům, ke kterému přistupuje dynamický SQL.

SQL Server má metody pro udělení přístupu uživatelů k datům pomocí uložených procedur a uživatelem definovaných funkcí, které spouštějí dynamické SQL.

• Použití zosobnění s klauzulí Transact-SQL EXECUTE AS.

• Podepisování uložených procedur pomocí certifikátů

VYKONAT JAKO

Klauzule EXECUTE AS nahrazuje oprávnění volajícího procesu oprávněními uživatele uvedeného v klauzuli EXECUTE AS. Vnořené uložené procedury nebo triggery se spouštějí v kontextu zabezpečení uživatele proxy serveru. To může narušit aplikace, které spoléhají na zabezpečení na úrovni řádků nebo vyžadují auditování. Některé funkce, které vracejí identitu uživatele, vrátí uživatele zadaného v klauzuli EXECUTE AS, nikoli původní volající. Kontext spuštění se vrátí k původnímu volajícímu až po provedení procedury nebo po vydání příkazu REVERT.

Podepisování certifikátů

Když se spustí uložená procedura podepsaná pomocí certifikátu, oprávnění udělená uživateli certifikátu se sloučí s volajícím. Kontext provádění zůstává stejný; uživatel certifikátu nezosobní volajícího. Podepisování uložených procedur vyžaduje k implementaci několik kroků. Pokaždé, když je postup změněn, musí být znovu podepsán.

Přístup mezi databázemi

Řetězení vlastnictví mezi databázemi nefunguje v případech, kdy se spouští dynamicky vytvořené příkazy SQL. Tento problém můžete obejít tak, že vytvoříte uloženou proceduru, která přistupuje k datům v jiné databázi, a podepíšete proceduru pomocí certifikátu, který existuje v obou databázích. Uživatelé tak mají přístup k databázovým prostředkům používaným postupem, aniž by jim udělili přístup k databázi nebo oprávnění.

Externí zdroje

Další informace najdete v následujících materiálech.

Resource	Description
Uložené procedury a injektáž SQL v knihách SQL Serveru Online	Témata popisují, jak vytvářet uložené procedury a jak funguje injektáž SQL.

Další kroky

• Scénáře zabezpečení aplikací na SQL Serveru