Menu

Výukový program na testovanie injekcie SQL (príklad a zabránenie útoku SQL Injection)

  • Hlavná
  • Testovanie Webu
  • Výukový program na testovanie injekcie SQL (príklad a zabránenie útoku SQL Injection)

sql injection testing tutorial example

Príklady SQL Injection a spôsoby, ako zabrániť útokom SQL Injection na webové aplikácie

ako prehrať mkv súbor v systéme Windows

Pri testovaní webu alebo systému je cieľom testera zaistiť, aby bol testovaný produkt čo najviac chránený.

Za týmto účelom sa zvyčajne vykonáva testovanie bezpečnosti. Aby sme mohli vykonať tento typ testovania, je potrebné najskôr zvážiť, ku ktorým útokom dôjde s najväčšou pravdepodobnosťou. Jedným z týchto útokov je SQL Injection.

Príklad a prevencia priloženia injekcie SQL

Aplikácia SQL Injection sa považuje za jeden z najbežnejších útokov, pretože môže mať vážne a škodlivé následky pre váš systém a citlivé údaje.

Čo sa dozviete:

Čo je to SQL Injection?

Niektoré zo vstupov používateľa môžu byť použité pri vytváraní rámcov Príkazy SQL ktoré potom vykoná aplikácia v databáze. Je možné, že aplikácia NIE správne spracováva vstupy poskytnuté používateľom.

Ak je to tak, škodlivý používateľ by mohol poskytnúť neočakávané vstupy do aplikácie, ktoré sa potom použijú na vytvorenie a vykonanie príkazov SQL v databáze. Toto sa nazýva SQL Injection. Dôsledky takéhoto konania môžu byť alarmujúce.

Ako už z názvu vyplýva, účelom útoku SQL Injection je vloženie škodlivého kódu SQL.

Každé pole webovej stránky je ako brána do databázy. V prihlasovacom formulári užívateľ zadá prihlasovacie údaje, do vyhľadávacieho poľa užívateľ zadá vyhľadávací text, vo formulári na ukladanie údajov užívateľ zadá údaje, ktoré sa majú uložiť. Všetky tieto uvedené údaje idú do databázy.

Ak zadáte nejaký škodlivý kód, namiesto správnych údajov existuje možnosť vážneho poškodenia databázy a celého systému.

SQL Injection sa vykonáva v programovacom jazyku SQL. Na správu údajov uchovávaných v databáze sa používa jazyk SQL (Structured Query Language). Preto sa počas tohto útoku tento kód programovacieho jazyka používa ako škodlivá injekcia.

Toto je jeden z najpopulárnejších útokov, pretože databázy sa používajú takmer pre všetky technológie.

Mnoho aplikácií používa nejaký typ databázy. Testovaná aplikácia môže mať používateľské rozhranie, ktoré akceptuje vstup používateľa, ktorý sa používa na vykonávanie nasledujúcich úloh:

# 1) Zobraziť príslušné uložené údaje používateľovi napr. aplikácia skontroluje prihlasovacie údaje používateľa pomocou prihlasovacích údajov zadaných používateľom a používateľovi sprístupní iba príslušné funkcie a údaje

#dva) Údaje zadané používateľom uložiť do databázy, napr. akonáhle užívateľ vyplní formulár a odošle ho, aplikácia pokračuje v ukladaní údajov do databázy; tieto údaje sa potom sprístupnia používateľovi v tej istej relácii aj v ďalších reláciách

Riziká vstrekovania SQL

V súčasnosti sa takmer pre všetky systémy a webové stránky používa databáza, pretože údaje by mali byť niekde uložené.

Pretože sa v databáze ukladajú citlivé údaje, so zabezpečením systému súvisí viac rizík. Ak by došlo k odcudzeniu údajov na nejakom osobnom webe alebo blogu, v porovnaní s údajmi, ktoré by boli odcudzené z bankového systému, nedôjde k ich veľkému poškodeniu.

Hlavným účelom tohto útoku je hacknutie databázy systému, takže následky tohto útoku môžu byť skutočne škodlivé.

Nasledujúce veci môžu byť výsledkom SQL Injection

  • Hacknutie účtu inej osoby.
  • Krádež a kopírovanie citlivých údajov webových stránok alebo systému.
  • Zmena citlivých údajov systému.
  • Odstraňujú sa citlivé údaje systému.
  • Používateľ sa mohol do aplikácie prihlásiť ako iný používateľ, dokonca aj ako správca.
  • Užívateľ si mohol zobraziť súkromné ​​informácie patriace iným používateľom, napr. podrobnosti o profiloch iných používateľov, podrobnosti transakcií atď.
  • Používateľ môže zmeniť informácie o konfigurácii aplikácie a údaje ostatných používateľov.
  • Užívateľ môže upraviť štruktúru databázy; dokonca vymazať tabuľky v databáze aplikácií.
  • Užívateľ môže prevziať kontrolu nad databázovým serverom a vykonávať na ňom ľubovoľné príkazy.

Vyššie uvedené riziká možno skutočne považovať za vážne, pretože obnova databázy alebo jej údajov môže stáť veľa. Obnova stratených údajov a systému môže vašu spoločnosť stáť reputáciu a peniaze. Preto sa dôrazne odporúča chrániť váš systém pred týmto typom útoku a považovať Testovanie zabezpečenia za dobrú investíciu do reputácie vášho produktu a spoločnosti.

Ako tester by som rád poznamenal, že testovanie proti možným útokom je dobrým postupom, aj keď Testovanie bezpečnosti nebolo plánované. Týmto spôsobom môžete chrániť a testovať produkt pred neočakávanými prípadmi a škodlivými používateľmi.

Podstata tohto útoku

Ako už bolo spomenuté, podstatou tohto útoku je hacknutie databázy so škodlivým úmyslom.

Aby ste mohli vykonať toto Testovanie zabezpečenia, musíte najskôr nájsť zraniteľné časti systému a potom cez ne odoslať škodlivý kód SQL do databázy. Ak je tento útok na systém možný, odošle sa príslušný škodlivý kód SQL a v databáze sa môžu vykonať škodlivé akcie.

Každé pole webovej stránky je ako brána do databázy. Akékoľvek údaje alebo vstupy, ktoré zvyčajne zadáme do ľubovoľného poľa systému alebo webovej stránky, sa dostanú do databázového dotazu. Preto by sme namiesto správnych údajov, ak by sme napísali akýkoľvek škodlivý kód, mohli spustiť v databázovom dotaze a priniesť škodlivé následky.

Odporúčaný nástroj

# 1) Kiuwan

banner kiuwan

Ľahko vyhľadajte a opravte chyby zabezpečenia, ako je napríklad vkladanie kódu SQL, do kódu v každej fáze SDLC. Kiuwan je v súlade s najprísnejšími bezpečnostnými štandardmi vrátane OWASP, CWE, SANS 25, HIPPA a ďalších.

Integrujte Kiuwan do svojho IDE pre okamžitú spätnú väzbu počas vývoja. Kiuwan podporuje všetky hlavné programovacie jazyky a integruje sa s poprednými nástrojmi DevOps.

=> Naskenujte svoj kód zadarmo

Na uskutočnenie tohto útoku musíme zmeniť spôsob a účel príslušného databázového dotazu. Jednou z možných metód jeho vykonania je dosiahnuť, aby bol dopyt vždy pravdivý a potom vložte váš škodlivý kód. Zmena databázového dotazu na vždy pravdivý sa dá vykonať jednoduchým kódom ako ‘alebo 1 = 1; -.

Podstata SQL Injection

Testujúci by mali mať na pamäti, že pri kontrole, či je možné vykonať zmenu dotazu na vždy pravdivý, alebo nie, je potrebné vyskúšať rôzne úvodzovky - jednoduché a dvojité. Preto, ak sme vyskúšali kód ako ‘alebo 1 = 1; -, mali by sme vyskúšať aj kód s dvojitými úvodzovkami„ alebo 1 = 1; -.

Podstata SQL Injection

Napríklad, uvažujme, že máme dopyt, ktorý hľadá zadané slovo v databázovej tabuľke:

vyberte * z poznámok nt kde nt.subject = ‘hľadané_slovo‘;

Preto ak namiesto hľadaného slova zadáme dopyt SQL Injection ‘alebo 1 = 1; -, potom bude dopyt vždy pravdivý.

vyberte * z poznámok nt, kde nt.subject = ‘‘ alebo 1 = 1; -

V takom prípade je parameter „subject“ uzavretý úvodzovkou a potom máme kód alebo 1 = 1, vďaka čomu je dopyt vždy pravdivý. Znakom „-“ komentujeme zvyšok kódu dotazu, ktorý sa nebude vykonávať. Je to jeden z najpopulárnejších a najjednoduchších spôsobov, ako začať ovládať dopyt.

Na to, aby bol dopyt vždy pravdivý, možno použiť aj niekoľko ďalších kódov, napríklad:

  • „Alebo„ abc “=„ abc “; -
  • „Alebo“ „=“ „; -

Najdôležitejšou časťou je, že po znamienku čiarkou môžeme zadať akýkoľvek škodlivý kód, ktorý by sme chceli spustiť.

Napríklad, môže to byť ‘alebo 1 = 1; poznámky k drop stolu; -

Poznámky k vypusteniu tabuľky

Ak je táto injekcia možná, môže byť napísaný akýkoľvek ďalší škodlivý kód. V takom prípade to bude závisieť iba od vedomostí a úmyslu škodlivého používateľa. Ako skontrolovať SQL Injection?

Kontrolu tejto chyby zabezpečenia je možné vykonať veľmi ľahko. Niekedy stačí do testovaných polí napísať znak „alebo“. Ak vráti ľubovoľnú neočakávanú alebo mimoriadnu správu, môžeme si byť istí, že je pre dané pole možné použiť SQL Injection.

Napríklad , ak sa vám ako výsledok vyhľadávania zobrazí chybové hlásenie ako „Internal Server Error“, môžeme si byť istí, že tento útok je v tejto časti systému možný.

Medzi ďalšie výsledky, ktoré môžu upozorniť na možný útok, patria:

  • Načítala sa prázdna stránka.
  • Žiadne chybové alebo úspešné správy - funkčnosť a stránka nereagujú na zadanie.
  • Správa o úspechu škodlivého kódu.

Pozrime sa, ako to funguje v praxi.

Napríklad, Poďme otestovať, či je príslušné prihlasovacie okno zraniteľné pre SQL Injection. Za týmto účelom do poľa e-mailovej adresy alebo hesla iba napíšeme znak, ako je to zobrazené nižšie.

Emailová adresa

Ak takýto vstup vráti výsledok, napríklad chybové hlásenie „Interná chyba servera“ alebo akýkoľvek iný uvedený nevhodný výsledok, môžeme si byť takmer istí, že tento útok je pre dané pole možný.

Interná chyba servera

Veľmi zložité Kód SQL Injection možno tiež vyskúšať. Chcel by som spomenúť, že som sa vo svojej kariére nestretol so žiadnym prípadom, keď by v dôsledku znaku došlo k správe „Internal Server Error“, ale polia niekedy na komplikovanejší kód SQL nereagovali.

Preto je kontrola pre SQL Injection pomocou jedinej ponuky „celkom dôveryhodný spôsob, ako skontrolovať, či je tento útok možný alebo nie.

Pokiaľ jednoduchá cenová ponuka nevráti nevhodný výsledok, môžeme skúsiť zadať dvojité úvodzovky a skontrolovať výsledky.

Jednotná cenová ponuka

Tiež je možné považovať SQL kód na zmenu dotazu na vždy pravdivý za spôsob, ako skontrolovať, či je tento útok možný alebo nie. Zatvorí parameter a zmení dopyt na „true“. Ak teda nebude overený, môže takýto vstup tiež vrátiť akýkoľvek neočakávaný výsledok a informovať ho, že tento útok je v tomto prípade možný.

Podstata SQL Injection

Kontrolu možných útokov SQL je možné vykonať aj pomocou odkazu na webe. Predpokladajme, že máme odkaz na webovú stránku ako http://www.testing.com/books=1 . V tomto prípade je „kniha“ parametrom a „1“ je jej hodnota. Ak by sme v uvedenom odkaze napísali namiesto „1 znak„ podpísať, potom by sme skontrolovali možné vstrekovanie.

Preto link http://www.testing.com/books= bude ako test, či je pre web možný útok SQL http://www.testing.com alebo nie.

Odkaz na testovanie

V takom prípade ak link http://www.testing.com/books= vráti chybové hlásenie ako „Interná chyba servera“ alebo prázdna stránka alebo akékoľvek iné neočakávané chybové hlásenie, potom si tiež môžeme byť istí, že je pre tento web možný SQL Injection. Neskôr sa môžeme pokúsiť poslať zložitejší kód SQL prostredníctvom odkazu na webovú stránku.

Ak chcete skontrolovať, či je tento útok možný prostredníctvom odkazu na webovú stránku, môžete odoslať kód ako „alebo 1 = 1; -.

Testovanie odkazov

Ako skúsený tester softvéru by som rád pripomenul, že za zraniteľnosť nástroja SQL Injection možno považovať nielen neočakávané chybové hlásenie. Mnoho testerov kontroluje možné útoky iba v súlade s chybovými správami.

Malo by sa však pamätať na to, že žiadna chybová správa o overení alebo správa o úspechu škodlivého kódu nemôže byť tiež známkou toho, že tento útok je možný.

Testovanie bezpečnosti webových aplikácií proti vkladaniu SQL

Testovanie bezpečnosti webových aplikácií vysvetlené na jednoduchých príkladoch:

Pretože následky umožnenia tejto techniky zraniteľnosti môžu byť závažné, vyplýva z toho, že tento útok by sa mal testovať počas testovania zabezpečenia aplikácie. Teraz s prehľadom tejto techniky pochopíme niekoľko praktických príkladov vkladania SQL.

Dôležité: Tento SQL Injection Test by sa mal testovať iba v testovacom prostredí.

Ak má aplikácia prihlasovaciu stránku, je možné, že používa dynamické SQL, ako je napríklad vyhlásenie nižšie. Očakáva sa, že tento príkaz vráti aspoň jeden riadok s podrobnosťami o používateľovi z tabuľky Používatelia ako množinu výsledkov, keď je do príkazu SQL zadaný riadok s používateľským menom a heslom.

VYBERTE * OD POUŽÍVATEĽOV, KDE User_Name = „“ & strUserName & „„ AND Heslo = ““ & strPassword & „‘; “

Ak by tester zadal Johna ako strUserName (do textového poľa pre používateľské meno) a Smith ako strPassword (do textového poľa pre heslo), vyššie uvedený príkaz SQL by sa stal:

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

Ak by tester zadal John’– ako strUserName a no strPassword, príkaz SQL by sa stal:

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

Upozorňujeme, že časť príkazu SQL po Jánovi sa zmenila na komentár. Ak by v tabuľke Používatelia bol nejaký používateľ s používateľským menom Jána, mohla by aplikácia umožniť testeru prihlásiť sa ako používateľ John. Tester teraz mohol zobraziť súkromné ​​informácie používateľa John.

Čo ak tester nevie meno žiadneho existujúceho používateľa aplikácie? V takom prípade môže tester vyskúšať bežné používateľské mená ako admin, administrator a sysadmin. Ak žiadny z týchto používateľov v databáze neexistuje, tester mohol zadať John ‘alebo‘ x ’=’ x ako strUserName a Smith ’alebo‘ x ’=’ x ako strPassword. To by spôsobilo, že by sa príkaz SQL stal podobným príkazu uvedenému nižšie.

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

Pretože podmienka „x’ = ’x’ platí vždy, sada výsledkov by pozostávala zo všetkých riadkov v tabuľke Používatelia. Aplikácia by mohla umožniť testeru prihlásiť sa ako prvý používateľ v tabuľke Používatelia.

Dôležité: Tester by mal pred vykonaním nasledujúcich útokov požiadať správcu databázy alebo vývojára o kopírovanie príslušnej tabuľky.

Ak by tester vstúpil do Jána “; DROP tabuľka users_details; ‘- ako strUserName a čokoľvek ako strPassword by príkaz SQL vyzeral ako ten nižšie.

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

Toto vyhlásenie by mohlo spôsobiť trvalé odstránenie tabuľky „users_details“ z databázy.

Aj keď sa vyššie uvedené príklady zaoberajú používaním techniky vstrekovania SQL iba na prihlasovacej stránke, tester by mal túto techniku ​​otestovať na všetkých stránkach aplikácie, ktoré akceptujú vstup používateľa v textovom formáte, napr. vyhľadávacie stránky, stránky so spätnou väzbou atď.

Injekcia SQL môže byť možná v aplikáciách, ktoré používajú SSL. Ani firewall nemusí byť schopný ochrániť aplikáciu pred touto technikou.

Snažil som sa túto útočnú techniku ​​vysvetliť jednoduchou formou. Chcel by som znovu zopakovať, že tento útok by sa mal testovať iba v testovacom prostredí, a nie vo vývojovom prostredí, produkčnom prostredí alebo akomkoľvek inom prostredí.

Namiesto manuálneho testovania, či je aplikácia zraniteľná voči útoku SQL, je možné použiť a Webový skener zraniteľnosti ktorá kontroluje túto zraniteľnosť.

ako čítať súbor .bin

Súvisiace čítanie: Testovanie bezpečnosti webovej aplikácie . Zaškrtnite toto pre viac podrobností o rôznych webových zraniteľnostiach.

Zraniteľné časti tohto útoku

Pred začatím procesu testovania by mal každý úprimný tester viac-menej vedieť, ktoré časti by boli najcitlivejšie na možný útok.

Osvedčeným postupom je tiež naplánovať, ktorá oblasť systému sa má testovať presne a v akom poradí. Počas svojej testovacej kariéry som sa dozvedel, že nie je dobrý nápad testovať polia proti útokom SQL náhodne, pretože niektoré polia môžu chýbať.

Pretože sa tento útok vykonáva v databáze, všetky časti systému na zadávanie údajov, vstupné polia a odkazy na webové stránky sú zraniteľné.

Medzi zraniteľné časti patrí:

  • Prihlasovacie polia
  • Vyhľadávacie polia
  • Polia komentárov
  • Akékoľvek ďalšie polia na zadávanie a ukladanie údajov
  • Odkazy na webové stránky

Je dôležité si uvedomiť, že pri testovaní proti tomuto útoku nestačí skontrolovať iba jedno alebo niekoľko polí. Je úplne bežné, že jedno pole môže byť chránené proti SQL Injection, ale iné nie. Preto je dôležité nezabudnúť vyskúšať všetky polia webových stránok.

Automatizácia testov SQL Injection

Pretože niektoré testované systémy alebo webové stránky môžu byť dosť komplikované a obsahujú citlivé údaje, manuálne testovanie môže byť naozaj náročné a tiež to vyžaduje veľa času. Preto môže byť testovanie proti tomuto útoku pomocou špeciálnych nástrojov občas skutočne užitočné.

Jedným z takýchto nástrojov je SQL Injection SOAP UI . Ak máme automatizované regresné testy na úrovni API, môžeme pomocou tohto nástroja prepnúť aj kontrolu proti tomuto útoku. V nástroji SOAP UI sú už pripravené šablóny kódu na kontrolu proti tomuto útoku. Tieto šablóny je tiež možné doplniť vlastným napísaným kódom.

Je to celkom spoľahlivý nástroj.

Test by už však mal byť automatizovaný na úrovni API, čo nie je také ľahké. Ďalším možným spôsobom automatického testovania je použitie rôznych doplnkov prehľadávača.

Je potrebné spomenúť, že aj keď vám automatizované nástroje šetria čas, nie vždy sa považujú za veľmi spoľahlivé. Ak testujeme bankový systém alebo inú webovú stránku s veľmi citlivými údajmi, dôrazne sa odporúča otestovať to manuálne. Kde môžete vidieť presné výsledky a analyzovať ich. V tomto prípade si tiež môžeme byť istí, že sa nič nepreskočilo.

Porovnanie s inými útokmi

SQL Injection možno považovať za jeden z najvážnejších útokov, pretože ovplyvňuje databázu a môže vážne poškodiť vaše údaje a celý systém.

Pre istotu to môže mať vážnejšie následky ako Injekcia Javascript alebo HTML Injection, pretože obidve z nich sa vykonávajú na strane klienta. Pre porovnanie, s týmto útokom môžete mať prístup k celej databáze.

Je potrebné spomenúť, že na testovanie proti tomuto útoku by ste mali mať celkom dobrú znalosť programovacieho jazyka SQL a všeobecne by ste mali vedieť, ako fungujú databázové dotazy. Pri vykonávaní tohto injekčného útoku by ste mali byť tiež opatrnejší a pozornejší, pretože akúkoľvek nepresnosť môžete ponechať ako chyby zabezpečenia SQL.

Záver

Dúfam, že by ste mali jasnú predstavu o tom, čo je to SQL Injection a ako by sme mali zabrániť týmto útokom.

Dôrazne sa však odporúča testovať proti tomuto typu útoku vždy, keď sa testuje systém alebo web s databázou. Akékoľvek zraniteľné miesta v databáze alebo systéme môžu stáť reputáciu spoločnosti a veľa prostriedkov potrebných na obnovenie celého systému.

Pretože testovanie proti tejto injekcii pomáha nájsť najviac dôležité bezpečnostné chyby , tiež sa odporúča investovať do svojich znalostí a testovacích nástrojov.

Ak je plánované testovanie zabezpečenia, potom by malo byť plánovanie testovania pomocou SQL Injection naplánované ako jedna z prvých testovacích častí.

Stretli ste sa s nejakým typickým SQL Injection? Neváhajte a podeľte sa o svoje skúsenosti v sekcii komentárov nižšie.

Odporúčané čítanie

^