Menu

Výukový program pro testování injekce SQL (příklad a prevence útoku SQL Injection)

sql injection testing tutorial example

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

otázky týkající se kódování java pro zkušené

Příklady SQL Injection a způsoby, jak zabránit útokům SQL Injection na webové aplikace

Při testování webu nebo systému je cílem testeru zajistit, aby byl testovaný produkt co nejvíce chráněn.

Za tímto účelem se obvykle provádí testování zabezpečení. Abychom mohli tento typ testování provést, musíme nejprve zvážit, ke kterým útokům dojde nejpravděpodobněji. SQL Injection je jedním z těchto útoků.

Příklad připojení SQL a prevence

SQL Injection je považován za jeden z nejběžnějších útoků, protože může mít vážné a škodlivé důsledky pro váš systém a citlivá data.

Co se naučíte:

Co je to SQL Injection?

Některé z uživatelských vstupů mohou být použity při rámování Příkazy SQL které jsou poté provedeny aplikací v databázi. Je možné, že aplikace NENÍ správně zpracována vstupy zadanými uživatelem.

Pokud tomu tak je, uživatel se zlými úmysly může aplikaci poskytnout neočekávané vstupy, které se pak použijí k vytvoření rámce a provedení příkazů SQL v databázi. Toto se nazývá SQL Injection. Důsledky takového jednání mohou být alarmující.

Jak název napovídá, účelem útoku SQL Injection je injektování škodlivého kódu SQL.

Každé pole webové stránky je jako brána do databáze. V přihlašovacím formuláři uživatel zadá přihlašovací údaje, do vyhledávacího pole uživatel zadá vyhledávací text, ve formuláři pro ukládání dat uživatel zadá data, která se mají uložit. Všechna tato uvedená data putují do databáze.

Místo správných dat, pokud je zadán nějaký škodlivý kód, existují možnosti vážného poškození databáze a celého systému.

SQL Injection se provádí pomocí programovacího jazyka SQL. Pro správu dat uchovávaných v databázi se používá jazyk SQL (Structured Query Language). Proto se během tohoto útoku tento kód programovacího jazyka používá jako škodlivá injekce.

Jedná se o jeden z nejpopulárnějších útoků, protože databáze se používají téměř pro všechny technologie.

Mnoho aplikací používá nějaký typ databáze. Testovaná aplikace může mít uživatelské rozhraní, které přijímá vstup uživatele a slouží k provádění následujících úkolů:

# 1) Zobrazit uživateli příslušná uložená data, např. aplikace kontroluje přihlašovací údaje uživatele pomocí přihlašovacích údajů zadaných uživatelem a vystavuje uživateli pouze příslušné funkce a data

#dva) Uložte data zadaná uživatelem do databáze, např. jakmile uživatel vyplní formulář a odešle jej, aplikace pokračuje v ukládání dat do databáze; tato data jsou poté zpřístupněna uživateli ve stejné relaci i v dalších relacích

Rizika SQL Injection

V současné době se databáze používá téměř pro všechny systémy a webové stránky, protože data by měla být někde uložena.

Jelikož se v databázi ukládají citlivá data, se zabezpečením systému je spojeno více rizik. Pokud by došlo ke krádeži dat jakéhokoli osobního webu nebo blogu, pak by ve srovnání s daty, která by byla odcizena z bankovního systému, nedošlo k velké škodě.

Hlavním účelem tohoto útoku je hacknutí databáze systému, proto mohou být následky tohoto útoku skutečně škodlivé.

Následující věci mohou být výsledkem SQL Injection

  • Hacknutí účtu jiné osoby.
  • Krádež a kopírování citlivých dat webu nebo systému.
  • Změna citlivých údajů systému.
  • Mazání citlivých dat systému.
  • Uživatel se mohl do aplikace přihlásit jako jiný uživatel, dokonce i jako správce.
  • Uživatel mohl zobrazit soukromé informace patřící jiným uživatelům, např. podrobnosti o profilech ostatních uživatelů, podrobnosti transakcí atd.
  • Uživatel může změnit informace o konfiguraci aplikace a data ostatních uživatelů.
  • Uživatel může upravit strukturu databáze; dokonce odstranit tabulky v databázi aplikace.
  • Uživatel by mohl převzít kontrolu nad databázovým serverem a libovolně na něm provádět příkazy.

Výše uvedená rizika lze skutečně považovat za vážná, protože obnovení databáze nebo jejích dat může stát hodně. Obnova ztracených dat a systému může vaši společnost stát reputaci a peníze. Proto se důrazně doporučuje chránit váš systém před tímto typem útoku a považovat Testování zabezpečení za dobrou investici do reputace vašeho produktu a společnosti.

Jako tester bych chtěl poznamenat, že testování proti možným útokům je dobrým postupem, i když Testování zabezpečení nebylo plánováno. Tímto způsobem můžete produkt chránit a otestovat před neočekávanými případy a škodlivými uživateli.

Podstata tohoto útoku

Jak již bylo zmíněno dříve, podstatou tohoto útoku je hacknutí databáze se škodlivým úmyslem.

Chcete-li provést toto testování zabezpečení, musíte nejprve najít zranitelné části systému a poté přes ně odeslat škodlivý kód SQL do databáze. Pokud je tento útok pro systém možný, bude odeslán příslušný škodlivý kód SQL a v databázi mohou být provedeny škodlivé akce.

Každé pole webové stránky je jako brána do databáze. Jakákoli data nebo vstupy, které obvykle zadáme do libovolného pole systému nebo webu, přejdou do databázového dotazu. Pokud bychom tedy místo správných dat zadali jakýkoli škodlivý kód, může být spuštěn v databázovém dotazu a mít škodlivé důsledky.

Doporučený nástroj

# 1) Kiuwan

kiuwan banner

Snadno vyhledejte a opravte chyby zabezpečení, jako je například vložení SQL, do kódu v každé fázi SDLC. Kiuwan vyhovuje nejpřísnějším bezpečnostním standardům včetně OWASP, CWE, SANS 25, HIPPA a dalších.

Integrujte Kiuwan do svého IDE pro okamžitou zpětnou vazbu během vývoje. Kiuwan podporuje všechny hlavní programovací jazyky a integruje se s předními nástroji DevOps.

=> Naskenujte svůj kód zdarma

K provedení tohoto útoku musíme změnit jednání a účel příslušného databázového dotazu. Jednou z možných metod, jak jej provést, je provést dotaz vždy pravdivý a poté vložit škodlivý kód. Změnu databázového dotazu na vždy pravdivý lze provést jednoduchým kódem jako ‚or 1 = 1; -.

Esence SQL Injection

Testeři by měli mít na paměti, že při kontrole, zda lze provést změnu dotazu na vždy pravdivý nebo ne, je třeba vyzkoušet různé uvozovky - jednoduché a dvojité. Pokud jsme tedy vyzkoušeli kód jako ‘nebo 1 = 1; -, měli bychom také zkusit kód s uvozovkami„ nebo 1 = 1; -.

Esence vstřikování SQL

Například, uvažujme, že máme dotaz, který hledá zadané slovo v databázové tabulce:

vyberte * z poznámek nt kde nt.subject = 'search_word';

Pokud tedy místo hledaného slova zadáme dotaz SQL Injection „nebo 1 = 1; -, bude dotaz vždy pravdivý.

vyberte * z poznámek nt, kde nt.subject = ‚‘ nebo 1 = 1; -

V tomto případě je parametr „předmět“ uzavřen uvozovkou a pak máme kód nebo 1 = 1, díky čemuž je dotaz vždy pravdivý. Znakem „-“ komentujeme zbytek kódu dotazu, který nebude proveden. Je to jeden z nejpopulárnějších a nejjednodušších způsobů, jak začít ovládat dotaz.

K tomu, aby byl dotaz vždy pravdivý, lze použít i několik dalších kódů, například:

  • „Nebo„ abc “=„ abc “; -
  • „Nebo“ „=“ „; -

Nejdůležitější částí je, že po znaku čárky můžeme zadat jakýkoli škodlivý kód, který bychom chtěli spustit.

Například, může to být „nebo 1 = 1; poznámky k rozevíracímu stolu; -

Poznámky k přetažení tabulky

Pokud je tato injekce možná, může být napsán jakýkoli jiný škodlivý kód. V takovém případě to bude záviset pouze na znalostech a úmyslu uživatele se zlými úmysly. Jak zkontrolovat SQL Injection?

Kontrolu této chyby zabezpečení lze provést velmi snadno. Někdy do testovaných polí stačí napsat znak „nebo“. Pokud vrátí jakoukoli neočekávanou nebo mimořádnou zprávu, můžeme si být jisti, že je pro toto pole možné SQL Injection.

Například , pokud se vám jako výsledek vyhledávání zobrazí chybová zpráva jako „Interní chyba serveru“, můžeme si být jisti, že tento útok je v dané části systému možný.

Mezi další výsledky, které mohou upozornit na možný útok, patří:

  • Prázdná stránka načtena.
  • Žádné chybové zprávy nebo zprávy o úspěchu - funkčnost a stránka nereagují na vstup.
  • Zpráva o úspěchu škodlivého kódu.

Podívejme se, jak to v praxi funguje.

Například, Zkusme otestovat, zda je vhodné přihlašovací okno zranitelné pro SQL Injection. Za tímto účelem do pole e-mailová adresa nebo heslo stačí zadat znak, jak je uvedeno níže.

Emailová adresa

Pokud takový vstup vrátí výsledek, jako je chybová zpráva „Interní chyba serveru“ nebo jakýkoli jiný uvedený nevhodný výsledek, můžeme si být téměř jisti, že tento útok je pro dané pole možný.

Interní chyba serveru

Velmi choulostivé Kód SQL Injection lze také vyzkoušet. Chtěl bych zmínit, že jsem se ve své kariéře nestretl s žádným případem, kdy by v důsledku znamení byla zpráva „Interní chyba serveru“, ale pole někdy na složitější kód SQL nereagovala.

Proto je kontrola SQL Injection s jedinou citací „docela důvěryhodným způsobem, jak zkontrolovat, zda je tento útok možný nebo ne.

Pokud jednoduchá nabídka nevrátí žádný nevhodný výsledek, můžeme zkusit zadat dvojité uvozovky a zkontrolovat výsledky.

Jednoduchá nabídka

Kód SQL pro změnu dotazu na vždy pravdivý lze také považovat za způsob, jak zkontrolovat, zda je tento útok možný nebo ne. Zavře parametr a změní dotaz na „true“. Pokud tedy nebude ověřen, může takový vstup také vrátit jakýkoli neočekávaný výsledek a informovat jej, že v tomto případě je tento útok možný.

Esence vstřikování SQL

Kontrolu možných útoků SQL lze provést také z odkazu na webu. Předpokládejme, že máme odkaz na web jako http://www.testing.com/books=1 . V tomto případě je „knihy“ parametr a „1“ je jeho hodnota. Pokud bychom v uvedeném odkazu napsali „znaménko místo 1, pak bychom zkontrolovali možnou injekci.

Proto odkaz http://www.testing.com/books= bude jako test, pokud je pro web možný útok SQL http://www.testing.com nebo ne.

Testovací odkaz

V tomto případě, pokud odkaz http://www.testing.com/books= vrátí chybovou zprávu jako „Interní chyba serveru“ nebo prázdnou stránku nebo jakoukoli jinou neočekávanou chybovou zprávu, pak si také můžeme být jisti, že je pro tento web možný SQL Injection. Později se můžeme pokusit odeslat složitější kód SQL prostřednictvím odkazu na web.

Chcete-li zkontrolovat, zda je tento útok možný prostřednictvím odkazu na web, můžete odeslat také kód jako „nebo 1 = 1; -.

Testování odkazů

Jako zkušený tester softwaru bych chtěl připomenout, že nejen neočekávaná chybová zpráva může být považována za chybu zabezpečení SQL Injection. Mnoho testerů kontroluje možné útoky pouze v souladu s chybovými zprávami.

Mělo by se však pamatovat na to, že žádná chybová zpráva o ověření nebo zpráva o úspěchu škodlivého kódu nemůže být také znamením, že je tento útok možný.

Testování zabezpečení webových aplikací proti SQL Injection

Testování zabezpečení webových aplikací vysvětleno na jednoduchých příkladech:

Protože důsledky povolení této techniky zranitelnosti mohou být závažné, vyplývá z toho, že tento útok by měl být testován během testování zabezpečení aplikace. Nyní s přehledem této techniky pochopíme několik praktických příkladů SQL injection.

Důležité: Tento SQL Injection Test by měl být testován pouze v testovacím prostředí.

Pokud má aplikace přihlašovací stránku, je možné, že aplikace používá dynamický SQL, například následující příkaz. Očekává se, že tento příkaz vrátí alespoň jeden řádek s podrobnostmi uživatele z tabulky Users jako sadu výsledků, pokud je v příkazu SQL zadán řádek s uživatelským jménem a heslem.

SELECT * FROM Users WHERE User_Name = ‚” & strUserName & “‘ AND Password = ‘” & strPassword & „“; “

Pokud by tester zadal Johna jako strUserName (v textovém poli pro uživatelské jméno) a Smith jako strPassword (v textovém poli pro heslo), výše uvedený příkaz SQL by se stal:

SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;

Pokud by tester zadal John’– jako strUserName a no strPassword, příkaz SQL by se stal:

SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;

Všimněte si, že část příkazu SQL po Johnovi se změnila na komentář. Pokud by v tabulce Users existoval jakýkoli uživatel s uživatelským jménem John, aplikace by mohla umožnit testeru přihlásit se jako uživatel John. Tester nyní mohl zobrazit soukromé informace o uživateli Johnovi.

Co když tester nezná jméno žádného existujícího uživatele aplikace? V takovém případě by tester mohl vyzkoušet běžná uživatelská jména jako admin, administrator a sysadmin. Pokud žádný z těchto uživatelů v databázi neexistuje, mohl by tester zadat John 'nebo' x '=' x jako strUserName a Smith 'nebo' x '=' x jako strPassword. To by způsobilo, že příkaz SQL bude podobný níže uvedenému.

SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;

Protože podmínka „x“ = „x“ je vždy pravdivá, výsledková sada by se skládala ze všech řádků v tabulce Uživatelé. Aplikace by mohla umožnit testeru přihlásit se jako první uživatel v tabulce Uživatelé.

Důležité: Tester by měl před pokusem o následující útoky požádat správce databáze nebo vývojáře o zkopírování příslušné tabulky.

Pokud by tester vstoupil do Johna “; DROP tabulka users_details; ‘- jako strUserName a cokoli jako strPassword by příkaz SQL vypadal jako ten níže.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';

Toto prohlášení může způsobit trvalé odstranění tabulky „users_details“ z databáze.

Ačkoli se výše uvedené příklady zabývají použitím techniky vkládání SQL pouze na přihlašovací stránku, měl by tester tuto techniku ​​otestovat na všech stránkách aplikace, které přijímají vstup uživatele v textovém formátu, např. vyhledávací stránky, stránky se zpětnou vazbou atd.

Vložení SQL může být možné v aplikacích, které používají SSL. Dokonce i firewall nemusí být schopen chránit aplikaci před touto technikou.

Snažil jsem se tuto techniku ​​útoku vysvětlit jednoduchou formou. Chtěl bych znovu iterovat tento útok by měl být testován pouze v testovacím prostředí a ne ve vývojovém prostředí, produkčním prostředí nebo jiném prostředí.

aplikace s časovou kartou pro iPhone a Android

Místo ručního testování, zda je aplikace zranitelná vůči útoku SQL, lze použít a Skener zranitelnosti webu který kontroluje tuto chybu zabezpečení.

Související čtení: Testování zabezpečení webové aplikace . Zaškrtněte toto pro více podrobností o různých zranitelnostech webu.

Zranitelné části tohoto útoku

Před zahájením procesu testování by každý upřímný tester měl víceméně vědět, které části by byly nejzranitelnější vůči možnému útoku.

Dobrou praxí je také naplánovat, které pole systému se má přesně testovat a v jakém pořadí. Během své testovací kariéry jsem se dozvěděl, že není dobrý nápad testovat pole proti útokům SQL náhodně, protože některá pole mohou chybět.

Jelikož se tento útok provádí v databázi, jsou všechny součásti systému zadávání dat, vstupní pole a odkazy na webové stránky zranitelné.

Mezi zranitelné části patří:

  • Přihlašovací pole
  • Vyhledávací pole
  • Pole komentářů
  • Jakákoli další pole pro zadávání a ukládání dat
  • Odkazy na webové stránky

Je důležité si uvědomit, že při testování proti tomuto útoku nestačí zkontrolovat pouze jedno nebo několik polí. Je zcela běžné, že jedno pole může být chráněno proti SQL Injection, ale jiné ne. Proto je důležité nezapomenout vyzkoušet všechna pole webových stránek.

Automatizace testů SQL Injection

Jelikož některé testované systémy nebo webové stránky mohou být docela komplikované a obsahují citlivá data, může být manuální testování opravdu obtížné a také to zabere hodně času. Proto může být testování proti tomuto útoku pomocí speciálních nástrojů občas opravdu užitečné.

Jedním z takových nástrojů je SQL Injection SOAP UI . Pokud máme automatizované regresní testy na úrovni API, můžeme také přepnout kontrolu proti tomuto útoku pomocí tohoto nástroje. V nástroji uživatelského rozhraní SOAP jsou již připravené šablony kódu pro kontrolu proti tomuto útoku. Tyto šablony lze také doplnit vlastním psaným kódem.

Je to docela spolehlivý nástroj.

Test by však již měl být automatizován na úrovni API, což není tak snadné. Dalším možným způsobem automatického testování je použití různých pluginů prohlížeče.

Je třeba zmínit, že i když automatizované nástroje šetří váš čas, nejsou vždy považovány za velmi spolehlivé. Pokud testujeme bankovní systém nebo jakýkoli web s velmi citlivými daty, důrazně doporučujeme otestovat jej ručně. Kde můžete vidět přesné výsledky a analyzovat je. Také v tomto případě si můžeme být jisti, že nebylo nic přeskočeno.

Porovnání s jinými útoky

SQL Injection lze považovat za jeden z nejzávažnějších útoků, protože ovlivňuje databázi a může vážně poškodit vaše data a celý systém.

Určitě to může mít vážnější důsledky než injekce Javascript nebo HTML Injection, protože obě jsou prováděny na straně klienta. Pro srovnání, s tímto útokem můžete mít přístup k celé databázi.

Je třeba zmínit, že k testování proti tomuto útoku byste měli mít docela dobrou znalost programovacího jazyka SQL a obecně byste měli vědět, jak fungují databázové dotazy. Při provádění tohoto injekčního útoku byste také měli být opatrnější a pozornější, protože jakoukoli nepřesnost lze ponechat jako chyby zabezpečení SQL.

Závěr

Doufám, že byste měli jasnou představu o tom, co je SQL Injection a jak bychom měli těmto útokům zabránit.

Důrazně se však doporučuje testovat proti tomuto typu útoku pokaždé, když se testuje systém nebo web s databází. Jakákoli zranitelná místa v databázi nebo systému mohou stát reputaci společnosti a spoustu prostředků k obnovení celého systému.

Protože testování proti této injekci pomáhá najít co nejvíce důležité bezpečnostní chyby , také se doporučuje investovat do svých znalostí a testovacích nástrojů.

Pokud je plánováno testování zabezpečení, mělo by být testování proti SQL Injection naplánováno jako jedna z prvních testovacích částí.

Setkali jste se s nějakým typickým SQL Injection? Neváhejte se podělit o své zkušenosti v sekci komentáře níže.

Doporučené čtení

^