Meni

Vadnica za testiranje vbrizgavanja SQL (primer in preprečevanje napada vbrizgavanja SQL)

sql injection testing tutorial example

Preizkusite Naš Instrument Za Odpravo Težav

c programiranje vprašanja in odgovori s pojasnili pdf

Primeri vbrizga SQL in načini za preprečevanje napadov vbrizgavanja SQL na spletne aplikacije

Med preizkušanjem spletnega mesta ali sistema je cilj preizkuševalca zagotoviti, ali je preizkušeni izdelek čim bolj zaščiten.

V ta namen se običajno opravi varnostno preskušanje. Za izvedbo te vrste testiranja moramo najprej razmisliti, kateri napadi se bodo najverjetneje zgodili. SQL Injection je eden od teh napadov.

Primer in preprečevanje priloge za vbrizgavanje SQL

SQL Injection velja za enega najpogostejših napadov, saj lahko povzroči resne in škodljive posledice za vaš sistem in občutljive podatke.

Kaj se boste naučili:

Kaj je vbrizgavanje SQL?

Nekateri uporabniški vhodi se lahko uporabijo za kadriranje Izjave SQL ki jih aplikacija nato izvede v bazi podatkov. Aplikacija NE more pravilno ravnati z vnosi, ki jih da uporabnik.

Če je temu tako, zlonamerni uporabnik lahko aplikaciji posreduje nepričakovane vhodne podatke, ki se nato uporabljajo za oblikovanje in izvajanje stavkov SQL v zbirki podatkov. To se imenuje SQL Injection. Posledice takega dejanja bi lahko bile zaskrbljujoče.

Kot že ime pove, je namen napada Injection SQL vbrizgati zlonamerno kodo SQL.

Vsako polje spletnega mesta je kot vrata do baze podatkov. V prijavni obrazec uporabnik vpiše podatke za prijavo, v iskalno polje uporabnik vnese besedilo za iskanje, v obrazec za shranjevanje podatkov uporabnik vnese podatke, ki jih je treba shraniti. Vsi navedeni podatki gredo v bazo podatkov.

Če se vnese kakršna koli zlonamerna koda, namesto pravilnih podatkov obstaja zbirka podatkov in celoten sistem resne škode.

SQL Injection se izvaja s programskim jezikom SQL. SQL (jezik strukturiranih poizvedb) se uporablja za upravljanje podatkov v bazi podatkov. Zato se med tem napadom ta programska koda jezika uporablja kot zlonamerna injekcija.

To je eden izmed najbolj priljubljenih napadov, saj se baze podatkov uporabljajo za skoraj vse tehnologije.

Številne aplikacije uporabljajo neko vrsto zbirke podatkov. Preskušana aplikacija ima lahko uporabniški vmesnik, ki sprejema uporabniški vnos, ki se uporablja za izvajanje naslednjih nalog:

# 1) Uporabniku pokažite ustrezne shranjene podatke, npr. aplikacija s pomočjo uporabniških podatkov, ki jih vnese uporabnik, preveri poverilnice uporabnika in uporabniku izpostavi samo ustrezne funkcije in podatke

#two) Podatke, ki jih vnese uporabnik, shranite v bazo podatkov, npr. ko uporabnik izpolni obrazec in ga odda, aplikacija nadaljuje s shranjevanjem podatkov v bazo podatkov; ti podatki so nato uporabniku na voljo v isti seji kot tudi v naslednjih sejah

Tveganja vbrizga SQL

Dandanes se baza podatkov uporablja za skoraj vse sisteme in spletna mesta, saj bi morali biti podatki nekje shranjeni.

Ker se občutljivi podatki shranjujejo v zbirki podatkov, obstaja več tveganj za varnost sistema. Če bi ukradli katero koli osebno spletno stran ali podatke spletnega dnevnika, potem v primerjavi s podatki, ki bi bili ukradeni iz bančnega sistema, ne bo veliko škode.

Glavni namen tega napada je vdor v zbirko podatkov sistema, zato so lahko posledice tega napada resnično škodljive.

Naslednje stvari so lahko posledica vbrizgavanja SQL

  • Vdor v račun druge osebe.
  • Kraja in kopiranje občutljivih podatkov spletnega mesta ali sistema.
  • Spreminjanje občutljivih podatkov sistema.
  • Brisanje občutljivih podatkov sistema.
  • Uporabnik se je lahko prijavil v aplikacijo kot drug uporabnik, tudi kot skrbnik.
  • Uporabnik si je lahko ogledal zasebne podatke, ki pripadajo drugim uporabnikom, npr. podrobnosti o profilih drugih uporabnikov, podrobnosti o transakcijah itd.
  • Uporabnik je lahko spreminjal podatke o konfiguraciji aplikacije in podatke drugih uporabnikov.
  • Uporabnik je lahko spremenil strukturo baze podatkov; celo brisanje tabel v zbirki podatkov aplikacije.
  • Uporabnik je lahko prevzel nadzor nad strežnikom baze podatkov in na njem poljubno izvrševal ukaze.

Zgoraj navedena tveganja lahko resnično štejemo za resna, saj lahko obnavljanje baze podatkov ali njenih podatkov stane veliko. Vaše podjetje lahko stane ugleda in denarja za obnovitev izgubljenih podatkov in sistema. Zato je zelo priporočljivo, da zaščitite svoj sistem pred tovrstnimi napadi in preskus varnosti je dobra naložba v ugled vašega izdelka in podjetja.

Kot preizkuševalec bi rad komentiral, da je testiranje proti možnim napadom dobra praksa, četudi Testiranje varnosti ni bilo načrtovano. Na ta način lahko izdelek zaščitite in preizkusite pred nepričakovanimi primeri in zlonamernimi uporabniki.

Bistvo tega napada

Kot smo že omenili, je bistvo tega napada vdiranje baze podatkov z zlonamernim namenom.

Če želite izvesti to varnostno preskušanje, morate najprej najti ranljive sistemske dele in nato z njimi poslati zlonamerno kodo SQL v bazo podatkov. Če je ta napad mogoč za sistem, bo poslana ustrezna zlonamerna koda SQL in v bazi podatkov bodo izvedena škodljiva dejanja.

Vsako polje spletnega mesta je kot vrata do baze podatkov. Vsi podatki ali vnosi, ki jih običajno vnesemo v katero koli polje sistema ali spletnega mesta, se pošljejo v poizvedbo v zbirki podatkov. Zato bi namesto pravilnih podatkov, če bi vtipkali škodljivo kodo, lahko to izvedli v poizvedbi baze podatkov in povzročili škodljive posledice.

Priporočeno orodje

# 1) Kiuwan

kiuwan pasica

Na vsaki stopnji SDLC v svoji kodi enostavno poiščite in odpravite ranljivosti, kot je vbrizgavanje SQL. Kiuwan je skladen z najstrožjimi varnostnimi standardi, vključno z OWASP, CWE, SANS 25, HIPPA in drugimi.

Vključite Kiuwan v svoj IDE za takojšnje povratne informacije med razvojem. Kiuwan podpira vse glavne programske jezike in se integrira z vodilnimi orodji DevOps.

=> Skenirajte kodo brezplačno

Za izvedbo tega napada moramo spremeniti dejanje in namen ustrezne poizvedbe v zbirki podatkov. Eden od možnih načinov izvedbe je, da poizvedba vedno drži in po njej vstavite zlonamerno kodo. Spreminjanje poizvedbe v zbirki podatkov na vedno true lahko izvedemo s preprosto kodo, kot je 'ali 1 = 1; -.

Bistvo vbrizgavanja SQL

Preizkuševalci ne smejo pozabiti, da je treba med preverjanjem, ali je mogoče poizvedbo spremeniti na vedno resnično, preizkusiti različne narekovaje - enojne in dvojne. Če smo poskusili s kodo, kot je 'ali 1 = 1; -, poskusimo tudi z dvojnimi narekovaji' ali 1 = 1; -.

Bistvo vbrizgavanja SQL

Na primer, upoštevajmo, da imamo poizvedbo, ki išče vneseno besedo v tabeli zbirke podatkov:

izberite * med opombami nt, kjer je nt.subject = 'search_word';

Če namesto iskalne besede vnesemo poizvedbo za vbrizgavanje SQL ‘ali 1 = 1; -, bo poizvedba vedno postala resnična.

izberite * med opombami nt, kjer je nt.subject = ‘‘ ali 1 = 1; -

V tem primeru se parameter 'subject' zapre s ponudbo in potem imamo kodo ali 1 = 1, zaradi česar je poizvedba vedno resnična. Z znakom '-' komentiramo preostalo kodo poizvedbe, ki se ne bo izvedla. To je eden najbolj priljubljenih in najlažjih načinov za začetek nadzora poizvedbe.

Za ohranitev vedno resnične poizvedbe se lahko uporabi tudi nekaj drugih kod, na primer:

  • 'Ali' abc '=' abc '; -
  • ‘Ali‘ ‘=‘ ‘; -

Tu je najpomembneje, da lahko za vejico vnesemo katero koli škodljivo kodo, ki bi jo radi izvršili.

Na primer, lahko je „ali 1 = 1; spustite opombe v tabeli; -

Spustite opombe v tabeli

Če je to vbrizgavanje možno, bo morda napisana katera koli druga zlonamerna koda. V tem primeru bo to odvisno samo od znanja in namere zlonamernega uporabnika. Kako preveriti vbrizgavanje SQL?

Preverjanje te ranljivosti je mogoče izvesti zelo enostavno. Včasih je dovolj, da v preizkušena polja vpišete znak »ali«. Če vrne nepričakovano ali izredno sporočilo, smo lahko prepričani, da je za to polje mogoče vbrizgavanje SQL.

Na primer , če se kot rezultat iskanja prikaže sporočilo o napaki, kot je »Notranja napaka strežnika«, smo lahko prepričani, da je ta napad možen v tem delu sistema.

Drugi rezultati, ki lahko opozorijo na možen napad, vključujejo:

  • Naložena je prazna stran.
  • Ni sporočil o napakah ali uspehu - funkcionalnost in stran se ne odzivata na vnos.
  • Sporočilo o uspehu za zlonamerno kodo.

Oglejmo si, kako to deluje v praksi.

Na primer, Preizkusimo, ali je ustrezno okno za prijavo ranljivo za SQL Injection. V ta namen v polje za e-poštni naslov ali geslo samo vtipkamo znak, kot je prikazano spodaj.

Email naslov

Če tak vnos vrne rezultat, kot je sporočilo o napaki »Notranja napaka strežnika« ali kateri koli drug neprimeren rezultat, smo skoraj prepričani, da je za to polje možen ta napad.

napaka notranjega strežnika

Zelo zapleteno Koda za vbrizgavanje SQL lahko tudi poskusili. Omenil bi, da v svoji karieri nisem naletel na primer, ko bi se zaradi znaka pojavilo sporočilo 'Notranja napaka strežnika', vendar se polja včasih niso odzvala zaradi bolj zapletene kode SQL.

Zato je preverjanje vbrizga SQL z enim narekovajem ‘dokaj zanesljiv način, da preverite, ali je ta napad mogoč ali ne.

Če enojna navednica ne vrne neprimernega rezultata, lahko poskusimo vnesti dvojne narekovaje in preverimo rezultate.

Posamezna ponudba

Kodo SQL za spreminjanje poizvedbe na vedno true lahko štejemo za način preverjanja, ali je ta napad mogoč ali ne. Parameter zapre in poizvedbo spremeni v 'true'. Če torej tak vnos ni potrjen, lahko vrne tudi kakršen koli nepričakovan rezultat in mu sporoči, da je v tem primeru možen napad.

Bistvo vbrizgavanja SQL

Preverjanje morebitnih napadov SQL lahko izvedete tudi prek povezave do spletnega mesta. Recimo, da imamo povezavo do spletnega mesta kot http://www.testing.com/books=1 . V tem primeru je 'knjige' parameter, '1' pa njegova vrednost. Če bi v priloženo povezavo napisali 'znak namesto 1, potem bi preverili morebitno injekcijo.

Zato povezava http://www.testing.com/books= bo kot test, če je za spletno mesto možen napad SQL http://www.testing.com ali ne.

Povezava za testiranje

V tem primeru povezava if http://www.testing.com/books= vrne sporočilo o napaki, kot je »Notranja napaka strežnika« ali prazna stran ali katero koli drugo nepričakovano sporočilo o napaki, potem smo lahko tudi prepričani, da je za to spletno mesto možno vbrizgavanje SQL. Kasneje lahko poskusimo poslati bolj zapleteno kodo SQL prek povezave do spletnega mesta.

Če želite preveriti, ali je ta napad možen prek povezave do spletnega mesta ali ne, lahko pošljete tudi kodo, na primer ‘ali 1 = 1; -.

Testiranje povezav

Kot izkušen preizkuševalec programske opreme bi rad opozoril, da ne moremo le nepričakovanega sporočila o napaki obravnavati kot ranljivost vbrizga SQL. Mnogi preizkuševalci preverjajo morebitne napade le v skladu s sporočili o napakah.

Vendar si je treba zapomniti, da nobeno sporočilo o napaki preverjanja ali sporočilo o uspehu zlonamerne kode ne more biti tudi znak, da je ta napad mogoč.

Testiranje varnosti spletnih aplikacij pred vbrizgom SQL

Testiranje varnosti spletnih aplikacij je razloženo s preprostimi primeri:

Ker bi bile posledice dovoljevanja te tehnike ranljivosti lahko resne, iz tega sledi, da bi bilo treba ta napad preizkusiti med varnostnim preskušanjem aplikacije. Zdaj pa s pregledom te tehnike, naj razumemo nekaj praktičnih primerov vbrizgavanja SQL.

Pomembno: Ta test vbrizga SQL je treba preizkusiti samo v testnem okolju.

Če ima aplikacija prijavno stran, je mogoče, da uporablja dinamični SQL, kot je spodnji stavek. Ta stavek naj bi vrnil vsaj eno vrstico z uporabniškimi podatki iz tabele Uporabniki kot rezultat, če je v stavku SQL vnesena vrstica z uporabniškim imenom in geslom.

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

Če bi preizkuševalec John vnesel kot strUserName (v besedilno polje za uporabniško ime) in Smith kot strPassword (v besedilno polje za geslo), bi zgornji stavek SQL postal:

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

Če bi tester vpisal John’– kot strUserName in brez strPassword, bi stavek SQL postal:

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

Upoštevajte, da je del stavka SQL po Janezu spremenjen v komentar. Če bi bil v tabeli Uporabniki uporabnik z uporabniškim imenom John, bi lahko aplikacija dovolila preizkuševalcu, da se prijavi kot uporabnik John. Preizkuševalec si je zdaj lahko ogledal zasebne podatke uporabnika Johna.

Kaj pa, če preizkuševalec ne pozna imena nobenega obstoječega uporabnika aplikacije? V takem primeru lahko preizkuševalec preizkusi običajna uporabniška imena, kot so admin, administrator in sysadmin. Če v bazi podatkov ni nobenega od teh uporabnikov, lahko preizkuševalec vnese John 'ali' x '=' x kot strUserName in Smith 'ali' x '=' x kot strPassword. To bi povzročilo, da bi stavek SQL postal podoben spodnjemu.

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

Ker pogoj 'x' = 'x' vedno drži, bi nabor rezultatov sestavljal vse vrstice v tabeli Uporabniki. Aplikacija lahko preskuševalcu dovoli, da se prijavi kot prvi uporabnik v tabeli Uporabniki.

Pomembno: Preizkuševalec mora pred poskusom naslednjih napadov od skrbnika baze podatkov ali razvijalca kopirati zadevno tabelo.

Če bi tester vstopil v Janeza '; DROP tabela users_details; ’- kot strUserName in karkoli kot strPassword bi izjava SQL postala podobna spodnji.

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

Ta izjava lahko povzroči, da se tabela »user_details« trajno izbriše iz baze podatkov.

Čeprav se zgornji primeri ukvarjajo z uporabo tehnike vbrizgavanja SQL le prijavne strani, bi moral preizkuševalec to tehniko preizkusiti na vseh straneh aplikacije, ki sprejemajo uporabniški vnos v besedilni obliki, npr. strani za iskanje, strani s povratnimi informacijami itd.

Vbrizgavanje SQL je mogoče v aplikacijah, ki uporabljajo SSL. Tudi požarni zid morda ne bo mogel zaščititi aplikacije pred to tehniko.

To tehniko napada sem poskušal razložiti v preprosti obliki. Želel bi ponoviti, da je treba ta napad preizkusiti samo v testnem okolju in ne v razvojnem okolju, proizvodnem okolju ali katerem koli drugem okolju.

izvajanje zgoščevalnega programa v c ++

Namesto da bi ročno preizkusili, ali je aplikacija ranljiva za napad SQL ali ne, bi lahko uporabili datoteko Skener za spletne ranljivosti ki preverja to ranljivost.

Sorodno branje: Testiranje varnosti spletne aplikacije . Preverite to za več podrobnosti o različnih spletnih ranljivostih.

Ranljivi deli tega napada

Preden začne preskusni postopek, bi moral vsak iskreni preizkuševalec bolj ali manj vedeti, kateri deli bi bili najbolj ranljivi za možen napad.

Prav tako je dobra praksa, če načrtujete, katero področje sistema bo natančno preizkušeno in v kakšnem vrstnem redu. V svoji preizkusni karieri sem se naučil, da ni dobro testirati polj proti napadom SQL naključno, saj lahko nekatera polja zamudimo.

Ker se ta napad izvaja v bazi podatkov, so vsi deli sistema vnosa podatkov, vnosna polja in povezave do spletnih mest ranljivi.

Ranljivi deli vključujejo:

  • Prijava polja
  • Iskalna polja
  • Polja za komentar
  • Vsa druga polja za vnos in shranjevanje podatkov
  • Povezave do spletnega mesta

Pomembno je opozoriti, da med testiranjem proti temu napadu ni dovolj preveriti samo enega ali nekaj polj. Pogosto je, da je eno polje zaščiteno pred vbrizgom SQL, drugo pa ne. Zato je pomembno, da ne pozabite preizkusiti vseh polj spletnega mesta.

Avtomatizacija preskusov vbrizgavanja SQL

Ker so nekateri preizkušeni sistemi ali spletna mesta lahko precej zapleteni in vsebujejo občutljive podatke, je lahko ročno testiranje resnično težko in tudi traja veliko časa. Zato je testiranje proti temu napadu s posebnimi orodji včasih lahko zelo koristno.

Eno takšnih orodij za vbrizgavanje SQL je VELIKI MIEL . Če imamo na ravni API avtomatizirane regresijske teste, lahko s tem orodjem tudi preklopimo preverjanje proti temu napadu. V orodju SOAP UI so že pripravljene predloge kode za preverjanje proti temu napadu. Te predloge lahko dopolnite tudi s svojo pisno kodo.

Je precej zanesljivo orodje.

Vendar bi moral biti test že avtomatiziran na ravni API, kar pa ni tako enostavno. Drug možen način samodejnega preizkusa je uporaba različnih vtičnikov brskalnika.

Omeniti je treba, da četudi vam avtomatizirana orodja prihranijo čas, niso vedno zelo zanesljiva. Če testiramo bančni sistem ali katero koli spletno mesto z zelo občutljivimi podatki, je zelo priporočljivo, da ga preizkusite ročno. Kjer lahko vidite natančne rezultate in jih analizirate. Tudi v tem primeru smo lahko prepričani, da ni nič preskočeno.

Primerjava z drugimi napadi

SQL Injection lahko štejemo za enega najresnejših napadov, saj vpliva na bazo podatkov in lahko resno poškoduje vaše podatke in celoten sistem.

Zagotovo ima lahko resnejše posledice kot vbrizgavanje Javascripta ali vbrizgavanje HTML-ja, saj se oba izvajata na strani odjemalca. Za primerjavo, s tem napadom imate dostop do celotne baze podatkov.

Omeniti je treba, da bi morali za preizkus proti temu napadu dobro poznati programski jezik SQL in na splošno bi morali vedeti, kako delujejo poizvedbe v zbirkah podatkov. Tudi med izvajanjem tega vbrizgalnega napada morate biti bolj previdni in pozorni, saj lahko kakršno koli netočnost pustite kot ranljivosti SQL.

Zaključek

Upam, da bi imeli jasno predstavo o tem, kaj je SQL Injection in kako naj preprečimo te napade.

Vendar je zelo priporočljivo, da testirate proti tovrstnim napadom vsakič, ko testirate sistem ali spletno mesto z bazo podatkov. Vsaka leva ranljivost baze podatkov ali sistema lahko stane ugleda podjetja in veliko virov za obnovitev celotnega sistema.

Ker testiranje proti tej injekciji pomaga najti največ pomembne varnostne ranljivosti , priporočljivo je tudi, da vlagate v svoje znanje in orodja za testiranje.

Če je načrtovano varnostno testiranje, je treba načrtovanje testiranja proti vbrizgavanju SQL načrtovati kot enega prvih delov testiranja.

Ste že naleteli na kakšen tipičen SQL Injection? Svoje izkušnje lahko delite v spodnjem oddelku za komentarje.

Priporočeno branje

^