SQL Attack

Přehled

SQL injection útok se skládá z vložení nebo "injekci" SQL dotazu prostřednictvím vstupních dat od klienta do aplikace. Úspěšný SQL injection zneužití může číst citlivá data z databáze, upravovat data z databáze (Vložit / Update / Delete), provádět administrativní operace na databázi (např. vypnutí DBMS), obnovit obsah daného souboru dárek k souboru DBMS systém av některých příkazů případech vydat do operačního systému. SQL injection útoky jsou typem vstřikování útoku , ve kterém jsou příkazy SQL vstříkne do data-roviny vstupu, aby umožnily provádění předdefinovaných SQL příkazů.

Hrozba Modeling

• SQL injection útoky umožňují útočníkům spoof identity, manipulovat s existující data, způsobit zapuzení otázky, jako jsou mikční transakce nebo změnit rovnováhu, umožňují úplné informace o všech údajů o systému, ke zničení dat nebo je jinak nedostupné, a stát se správci databázový server.
• SQL Injection je velmi častá PHP a ASP aplikací díky výskytu starších funkčních rozhraní. Vzhledem k povaze programové rozhraní k dispozici, J2EE a ASP.NET aplikace jsou méně pravděpodobné, že snadno zneužít SQL injekce.
• Závažnost injection útoky SQL je omezen na útočníkův dovednosti a představivost, a do lesser rozsahu, obranu do hloubky protiopatření, jako jsou nízké výsada připojení k databázovému serveru a tak dále. Obecně platí, že považují SQL Injection velký vliv závažnosti.

Související bezpečnostních činností

Jak se vyhnout SQL injection Slabá

Podívejte se na OWASP Průvodce článek o tom, jak se vyhnout SQL injectionSlabá. 
Viz OWASP SQL Injection prevence Cheat Sheet .

Jak Ohodnotit kód pro injekci zabezpečení SQL

Viz OWASP kód Review Průvodce článek o tom, jak se Ohodnotit kód pro injekce SQL zabezpečení.

Jak testovat pro SQL injection zabezpečení

Viz OWASP Testing Guide článek o tom, jak test pro injekce SQLzabezpečení.

Popis

SQL injection dojít k chybám při:

1. Data zadá program z nedůvěryhodného zdroje.
2. Údaje použité pro dynamicky sestavit SQL dotaz

Hlavními důsledky jsou:

• Důvěrnost : Vzhledem k tomu, SQL databáze obecně mají citlivá data, ztráta důvěrnosti je častý problém s SQL Injection zranitelnosti.

• Ověření : Pokud chudé SQL příkazy se používají pro kontrolu uživatelských jmen a hesel, je možné připojit k systému jako jiný uživatel bez předchozí znalosti hesla.

• Autorizace : Pokud autorizační informace se koná v SQL databázi, je možné změnit tuto informaci prostřednictvím úspěšného využití v SQL Injection zranitelnosti.

• Integrita : Tak, jak to může být možné číst citlivé informace, je také možné, aby se změny nebo dokonce odstranit tyto informace s Injection SQL útok.

Rizikové faktory

Ovlivněny platforma může být:

• Jazyk: SQL
• Platforma: Všechny (vyžaduje interakci s databází SQL)

SQL Injection se stalo běžným problémem s databází zaměřených webových stránek. Chyba je snadno zjistit, a snadno zneužít, a jako takový, jakékoli stránky nebo software s ještě minimálním uživatelské základny je pravděpodobné, že bude podléhat pokusu o útok tohoto druhu.

V podstatě, je útok dosaženo umístěním metadat postavu do datového vstupu do umístěte SQL příkazy v kontrolní rovině, který neexistoval tam předtím. Tato chyba závisí na skutečnosti, že SQL nečiní rozdíl mezi skutečnou kontrolu a datových rovinách.

Příklady

Příklad 1

V SQL:

SELECT ID, jméno, příjmení z autorů

Jestliže jeden předpokladu, že:

Jméno: evil'ex
Příjmení: Newman

řetězec dotazu se stává:

SELECT ID, jméno, příjmení od autorů, kde jméno = 'evil'ex' a příjmení = 'Newman'
které databáze pokusí spustit jako 

Nesprávná syntaxe poblíž al 'jako databáze pokusil vykonat zlo. 

Bezpečné verze výše SQL příkazu může být kódovány v Javě jako:

String křestní jméno = req.getParameter ("křestní jméno");
String prijmeni = req.getParameter ("prijmeni");
/ / FIXME: udělat si vlastní validaci k detekci útoků
String query = "SELECT id, jméno, příjmení FROM autoři KDE jméno = a příjmení =?";
PreparedStatement pstmt = connection.prepareStatement (query);
pstmt.setString (1, jmeno);
pstmt.setString (2, příjmení);
zkusit
{
	Výsledný výsledky = pstmt.execute ();
}

Příklad 2

Následující C # kód dynamicky vytvoří a spustí SQL dotaz, který vyhledá položek odpovídajících zadaným názvem. Dotaz omezuje položky zobrazené na ty, u kterých vlastník odpovídá uživatelské jméno aktuálně přihlášeného uživatele.

	...
string userName = ctx.getAuthenticatedUserName ();
string query = "SELECT * FROM položek, kde majitel =" '" 
					+ UserName + "'AND ItemName ='"  
					+ ItemName.Text + "'";
	sda = new SqlDataAdapter (dotaz, conn);
	DataTable dt = new DataTable ();
	sda.Fill (dt);
	...

Dotaz, který tento kód hodlá provést takto:

	SELECT * FROM položek
	KDE majitel = 
	A ItemName =;

Nicméně, protože dotaz je konstruován dynamicky zřetězení konstantní základní řetězec dotazu a vstup uživatele řetězec, dotaz pouze chová správně, pokud itemName neobsahuje jediné uvozovky. Pokud útočník s uživatelským jménem Wiley zadá řetězec "název" nebo "" = '"pro itemName, pak dotaz bude následující:

	SELECT * FROM položek
	KDE majitel = 'Wiley'
	A ItemName = 'name' OR 'a' = 'a';

Přidání OR "'=' A 'stavu způsobí, že klauzule WHERE vždy vyhodnotí na true, takže dotaz stane logicky ekvivalentní k mnohem jednodušší dotazu:

	SELECT * FROM položek;

Toto zjednodušení dotazu umožňuje útočníkovi obejít požadavek, aby dotaz vrátit pouze položky ve vlastnictví ověřeného uživatele, dotaz se vrátí všechny záznamy uložené v tabulce položek, bez ohledu na jejich zadaného vlastníka.

Příklad 3

Tento příklad zkoumá účinky jiného škodlivého hodnoty předané k dotazu konstruovaného a popraven v příkladu 1. Pokud útočník s hackerem uživatelské jméno zadá řetězec "hacker"); DELETE FROM položek; - "pro itemName, pak dotaz bude následující dva dotazy:

	SELECT * FROM položek 
	KDE majitel = 'hacker'
	A ItemName = 'name';

DELETE FROM položek;

- "

Mnoho databázových serverů, včetně Microsoft ® SQL Server 2000, umožňuje více příkazů SQL oddělených středníky které mají být provedeny najednou.Zatímco tento výsledků útok řetězce v chybě v Oracle a dalších databázových serverů, které neumožňují dávkového plnění prohlášení oddělených středníky, v databázích, které dělají umožňují dávkové spuštění, tento typ útoku umožňuje útočníkovi spustit libovolný příkazy na databázi .

Všimněte si, že koncové pár pomlček (-), která určuje, pro většinu databázových serverech, které zbytek prohlášení je třeba považovat za komentář a nebudou provedeny. V tomto případě se poznámka charakter slouží k odstranění koncové apostrofy zbylý z modifikovaného dotazu. V databázi, kde jsou komentáře nesmí být použit v tomto způsobu, může obecně útok ještě být účinné použití trik podobný tomu, který je znázorněno v příkladu 1. Pokud útočník zadá řetězec "název"); DELETE FROM položek; SELECT * FROM položek, kde 'a' = '", budou následující tři platné výpovědi Založeno:

	SELECT * FROM položek 
	KDE majitel = 'hacker'
	A ItemName = 'name';

DELETE FROM položek;

SELECT * FROM položek, kde 'a' = '";

Jeden z tradičních přístup k prevenci SQL injection útoků je s nimi jako problém vstupní validace a buď akceptovat pouze znaky z whitelistu bezpečných hodnot nebo identifikovat a uniknout černou listinu potenciálně škodlivých hodnot.Whitelisting, může být velmi účinným prostředkem prosazování přísná pravidla ověřování vstupu, ale parametrizované SQL příkazy vyžadují menší údržbu a může nabídnout více záruk s ohledem na bezpečnost. Jak je to téměř vždy, blacklisting je protkána mezery, které dělají to neefektivní v prevenci SQL injection útoků. Například, mohou útočníci:

• Cílové pole, která nejsou kótovaná
• Najít způsob, jak obejít potřebu některých uniklých meta-znaky
• Pomocí uložené procedury skrýt injekčně meta-znaky

Ručně unikající znaků vstup do SQL dotazů může pomoci, ale to nebude dělat aplikace bezpečné z SQL injection útoky.

Dalším řešením obyčejně navrhuje řešení vstřikovací útoky SQL je použít uložené procedury. Přestože uložené procedury zabránit vzniku některých typů SQL injection útoků, které nejsou schopny chránit proti mnoha dalších.Například, následující PL / SQL postup je citlivá na stejném SQL injection útoku uvedené v prvním příkladu.

	Postup get_item (
		itm_cv IN ItmCurTyp OUT,
		usr v VARCHAR2,
		ITM v VARCHAR2)
	je
		otevřít itm_cv pro "SELECT * FROM položek, kde" | |
				"Majitel ='' '| | usr | | 
				"A ItemName ='' '| | ITM | |'''';
	konec get_item;

Uložené procedury obvykle zabránit SQL injection útoky omezením typy výroků, které mohou být předány do jejich parametrů. Nicméně, existuje mnoho způsobů, jak kolem omezení a řadu dalších zajímavých prohlášení, které může ještě být předány do uložených procedur. Opět platí, že uložené procedury znemoľnit využije, ale nebude dělat aplikace zabezpečené proti SQL injection útokům.