Meni

Vodič za ispitivanje ubrizgavanja SQL (Primjer i sprečavanje napada na ubrizgavanje SQL)

  • Glavni
  • Web Testiranje
  • Vodič za ispitivanje ubrizgavanja SQL (Primjer i sprečavanje napada na ubrizgavanje SQL)

sql injection testing tutorial example

Isprobajte Naš Instrument Za Uklanjanje Problema

čime otvaraš jar datoteke

Primjeri SQL ubrizgavanja i načini za sprečavanje napada SQL ubrizgavanja na web aplikacije

Tijekom testiranja web stranice ili sustava, cilj testera je osigurati je li testirani proizvod što je moguće zaštićeniji.

U tu se svrhu obično provodi sigurnosno ispitivanje. Da bismo izvršili ovu vrstu testiranja, u početku moramo razmotriti koji će se napadi najvjerojatnije dogoditi. SQL Injection je jedan od tih napada.

Primjer i sprječavanje dodavanja SQL injekcije

SQL Injection smatra se jednim od najčešćih napada jer može donijeti ozbiljne i štetne posljedice na vaš sustav i osjetljive podatke.

Što ćete naučiti:

Što je SQL ubrizgavanje?

Neki korisnički ulazi mogu se koristiti u kadriranju SQL Izjave koje zatim izvršava aplikacija na bazi podataka. Moguće je da aplikacija NE pravilno obrađuje unose koje je dao korisnik.

Ako je to slučaj, zlonamjerni korisnik mogao bi aplikaciji pružiti neočekivane ulaze koji se zatim koriste za uokvirivanje i izvršavanje SQL izraza u bazi podataka. To se naziva SQL Injection. Posljedice takvog postupka mogu biti alarmantne.

Kao što samo ime govori, svrha napada SQL Injection je ubrizgavanje zlonamjernog SQL koda.

Svako polje web stranice je poput ulaza u bazu podataka. U obrazac za prijavu korisnik unosi podatke za prijavu, u polje za pretraživanje korisnik unosi tekst pretraživanja, u obrazac za spremanje podataka korisnik unosi podatke za spremanje. Svi ovi navedeni podaci idu u bazu podataka.

Umjesto ispravnih podataka, ako se unese bilo koji zlonamjerni kôd, postoje mogućnosti da se dogodi ozbiljna šteta u bazi podataka i cijelom sustavu.

SQL Injection se izvodi s programskim jezikom SQL. SQL (strukturirani jezik upita) koristi se za upravljanje podacima koji se čuvaju u bazi podataka. Stoga se tijekom ovog napada ovaj programski jezik koristi kao zlonamjerna injekcija.

Ovo je jedan od najpopularnijih napada, jer se baze podataka koriste za gotovo sve tehnologije.

Mnoge aplikacije koriste neku vrstu baze podataka. Aplikacija koja se testira može imati korisničko sučelje koje prihvaća korisnički unos koji se koristi za izvršavanje sljedećih zadataka:

# 1) Pokažite relevantne pohranjene podatke korisniku, npr. aplikacija provjerava vjerodajnice korisnika pomoću podataka za prijavu koje je korisnik unio i korisniku izlaže samo relevantne funkcije i podatke

#dva) Spremite podatke koje je korisnik unio u bazu podataka, npr. nakon što korisnik ispuni obrazac i preda ga, aplikacija nastavlja spremati podatke u bazu podataka; ti se podaci zatim stavljaju na raspolaganje korisniku u istoj sesiji, kao i u sljedećim sesijama

Rizici ubrizgavanja SQL-a

Danas se baza podataka koristi za gotovo sve sustave i web stranice, jer bi podaci trebali biti negdje pohranjeni.

Budući da se osjetljivi podaci pohranjuju u bazu podataka, postoji više rizika koji uključuju sigurnost sustava. Ako bi bilo koja osobna web stranica ili podaci bloga bili ukradeni, tada neće biti velike štete u usporedbi s podacima koji bi bili ukradeni iz bankarskog sustava.

Glavna svrha ovog napada je hakiranje baze podataka sustava, stoga posljedice ovog napada zaista mogu biti štetne.

Sljedeće stvari mogu proizaći iz SQL Injection-a

  • Hakiranje računa druge osobe.
  • Krađa i kopiranje osjetljivih podataka web mjesta ili sustava.
  • Promjena osjetljivih podataka sustava.
  • Brisanje osjetljivih podataka sustava.
  • Korisnik se mogao prijaviti u aplikaciju kao drugi korisnik, čak i kao administrator.
  • Korisnik je mogao pregledavati privatne podatke koji pripadaju drugim korisnicima, npr. detalji profila drugih korisnika, detalji transakcije itd.
  • Korisnik je mogao promijeniti podatke o konfiguraciji aplikacije i podatke ostalih korisnika.
  • Korisnik je mogao mijenjati strukturu baze podataka; čak i brisanje tablica u bazi podataka aplikacija.
  • Korisnik je mogao preuzeti kontrolu nad poslužiteljem baze podataka i izvršavati naredbe na njemu po svojoj volji.

Gore navedeni rizici doista se mogu smatrati ozbiljnima, jer obnavljanje baze podataka ili njezinih podataka može puno koštati. Vaša tvrtka može koštati reputacije i novca za vraćanje izgubljenih podataka i sustava. Stoga se toplo preporučuje da zaštitite svoj sustav od ove vrste napada i testiranje sigurnosti smatrate dobrim ulaganjem u reputaciju vašeg proizvoda i tvrtke.

Kao tester, želio bih komentirati da je testiranje protiv mogućih napada dobra praksa čak i ako Ispitivanje sigurnosti nije bilo planirano. Na ovaj način možete zaštititi i testirati proizvod od neočekivanih slučajeva i zlonamjernih korisnika.

Suština ovog napada

Kao što je ranije spomenuto, suština ovog napada je hakiranje baze podataka sa zlonamjernom svrhom.

Da biste izvršili ovo sigurnosno testiranje, u početku morate pronaći ranjive dijelove sustava, a zatim poslati zlonamjerni SQL kôd kroz njih u bazu podataka. Ako je ovaj napad moguć za sustav, tada će se poslati odgovarajući zlonamjerni SQL kôd i u bazi podataka mogu se izvršiti štetne radnje.

Svako polje web stranice je poput ulaza u bazu podataka. Svi podaci ili unosi koje obično unesemo u bilo koje polje sustava ili web mjesta idu na upit baze podataka. Stoga, umjesto ispravnih podataka, ako bismo upisali bilo koji zlonamjerni kod, on bi se mogao izvršiti u upitu baze podataka i donijeti štetne posljedice.

Preporučeni alat

# 1) Kiuwan

kiuvanski transparent

Jednostavno pronađite i popravite ranjivosti poput SQL ubrizgavanja u kodu u svakoj fazi SDLC-a. Kiuwan je usklađen s najstrožim sigurnosnim standardima, uključujući OWASP, CWE, SANS 25, HIPPA i druge.

Integrirajte Kiuwan u svoj IDE za trenutne povratne informacije tijekom razvoja. Kiuwan podržava sve glavne programske jezike i integrira se s vodećim DevOps alatima.

=> Skenirajte svoj kod besplatno

Za izvođenje ovog napada moramo promijeniti čin i svrhu odgovarajućeg upita baze podataka. Jedna od mogućih metoda za njegovo izvođenje je da upit uvijek bude istinit i nakon toga ubacite svoj zlonamjerni kôd. Promjena upita baze podataka u uvijek istinito može se izvršiti jednostavnim kodom poput 'ili 1 = 1; -.

Bit SQL ubrizgavanja

Ispitivači bi trebali imati na umu da, provjeravajući može li se promjena upita u uvijek istinito izvršiti ili ne, treba isprobati različite citate - pojedinačne i dvostruke. Stoga, ako smo isprobali kod poput 'ili 1 = 1; -, trebali bismo isprobati i kod s dvostrukim navodnicima' ili 1 = 1; -.

Suština ubrizgavanja SQL-a

Na primjer, uzmimo u obzir da imamo upit koji traži unesenu riječ u tablici baze podataka:

odaberite * iz bilješki nt gdje je nt.subject = 'riječ_ pretraživanja';

Stoga, umjesto riječi za pretraživanje, ako unesemo upit za SQL ubrizgavanje ‘ili 1 = 1; -, tada će upit uvijek postati istinit.

odaberite * iz bilješki nt gdje je nt.subject = ‘‘ ili 1 = 1; -

U ovom se slučaju parametar „subject“ zatvara citiranjem i tada imamo kôd ili 1 = 1, što čini upit uvijek istinitim. Znakom '-' komentiramo ostatak koda upita koji se neće izvršiti. To je jedan od najpopularnijih i najlakših načina za započinjanje kontrole upita.

Nekoliko drugih kodova također se može koristiti da bi se upit uvijek učinio istinitim, poput:

  • 'Ili' abc '=' abc '; -
  • ‘Ili‘ ‘=‘ ‘; -

Ovdje je najvažnije da nakon znaka zarez možemo unijeti bilo koji zlonamjerni kod koji bismo željeli da se izvrši.

Na primjer, može biti ‘ili 1 = 1; ispustite bilješke u tablici; -

Ispusti bilješke u tablici

Ako je ovo ubrizgavanje moguće, tada se može napisati bilo koji drugi zlonamjerni kod. U ovom će slučaju ovisiti samo o znanju i namjeri zlonamjernog korisnika. Kako provjeriti ubrizgavanje SQL-a?

Provjera ove ranjivosti može se izvršiti vrlo jednostavno. Ponekad je dovoljno unijeti znak „ili“ u testirana polja. Ako vrati bilo kakvu neočekivanu ili izvanrednu poruku, možemo biti sigurni da je za to polje moguće ubrizgavanje SQL-a.

Na primjer , ako kao rezultat pretraživanja dobijete poruku o pogrešci poput 'Interna pogreška poslužitelja', možemo biti sigurni da je ovaj napad moguć u tom dijelu sustava.

Ostali rezultati koji mogu izvijestiti o mogućem napadu uključuju:

  • Učitana prazna stranica.
  • Nema poruka o pogreškama ili uspjehu - funkcionalnost i stranica ne reagiraju na unos.
  • Poruka o uspjehu za zlonamjerni kôd.

Pogledajmo oko sebe kako ovo djeluje u praksi.

Na primjer, Provjerimo je li odgovarajući prozor za prijavu ranjiv za SQL Injection. U tu svrhu u polje adrese e-pošte ili lozinke samo upišemo znak kao što je prikazano dolje.

Email adresa

Ako takav unos vrati rezultat poput poruke pogreške 'Interna pogreška poslužitelja' ili bilo kojeg drugog navedenog neprimjerenog rezultata, tada možemo biti gotovo sigurni da je taj napad moguć za to polje.

Interna pogreška poslužitelja

Vrlo zeznuto Kôd za ubrizgavanje SQL može se i pokušati. Želio bih napomenuti da u svojoj karijeri nisam naišao na slučaj da je kao znak bila poruka 'Interna pogreška poslužitelja', ali ponekad polja nisu reagirala na složeniji SQL kôd.

Stoga je provjeravanje SQL Injection s jednim navodnikom 'vrlo pouzdan način provjere je li ovaj napad moguć ili ne.

Ako pojedinačni navodnik ne daje neprikladan rezultat, tada možemo pokušati unijeti dvostruke navodnike i provjeriti rezultate.

Pojedinačni citat

Također, SQL kod za promjenu upita u uvijek istinit može se smatrati načinom provjere je li ovaj napad moguć ili ne. Zatvara parametar i mijenja upit u 'true'. Stoga, ako nije provjeren, takav unos može vratiti i svaki neočekivani rezultat i obavijestiti isti da je ovaj napad u ovom slučaju moguć.

Suština ubrizgavanja SQL-a

Provjera mogućih SQL napada također se može izvršiti putem veze na web mjestu. Pretpostavimo da imamo vezu na web stranicu kao http://www.testing.com/books=1 . U ovom je slučaju 'knjige' parametar, a '1' njegova vrijednost. Ako bismo u navedenu vezu napisali ‘znak umjesto 1, tada bismo provjerili postoji li mogućnost ubrizgavanja.

Stoga link http://www.testing.com/books= bit će poput testa ako je za web mjesto moguć SQL napad http://www.testing.com ili ne.

Link za testiranje

U ovom slučaju, ako link http://www.testing.com/books= vraća poruku o pogrešci poput 'Interna pogreška poslužitelja' ili praznu stranicu ili bilo koju drugu neočekivanu poruku pogreške, tada također možemo biti sigurni da je za tu web lokaciju moguće ubrizgavanje SQL-a. Kasnije možemo pokušati poslati još nezgodnog SQL koda putem veze na web mjestu.

Da biste provjerili je li ovaj napad moguć putem veze na web mjestu ili ne, također se može poslati kod poput 'ili 1 = 1; -.

Ispitivanje veza

Kao iskusni ispitivač softvera, želio bih podsjetiti da se ne samo neočekivana poruka pogreške može smatrati ranjivošću SQL Injection. Mnogi testeri provjeravaju moguće napade samo u skladu s porukama o pogreškama.

Međutim, treba imati na umu da nijedna poruka o pogrešci provjere valjanosti ili poruka uspjeha za zlonamjerni kôd također ne može biti znak da je ovaj napad moguć.

Ispitivanje sigurnosti web aplikacija protiv ubrizgavanja SQL

Ispitivanje sigurnosti web aplikacija objašnjeno je jednostavnim primjerima:

Budući da bi posljedice dopuštanja ove tehnike ranjivosti mogle biti ozbiljne, proizlazi da bi ovaj napad trebalo testirati tijekom sigurnosnog testiranja aplikacije. Sada ćemo s pregledom ove tehnike razumjeti nekoliko praktičnih primjera ubrizgavanja SQL-a.

Važno: Ovaj test ubrizgavanja SQL trebao bi se testirati samo u testnom okruženju.

Ako aplikacija ima stranicu za prijavu, moguće je da aplikacija koristi dinamički SQL kao što je izjava u nastavku. Očekuje se da će ovaj izraz vratiti barem jedan redak s korisničkim pojedinostima iz tablice Korisnici kao skup rezultata kada postoji red s korisničkim imenom i lozinkom unesenim u SQL izraz.

ODABERITE * OD korisnika GDJE Korisničko ime = ‘” & strUserName & “‘ I Lozinka = ‘” & strPassword & '’; '

Ako bi tester ušao Ivana kao strUserName (u tekstualnom okviru za korisničko ime) i Smith kao strPassword (u tekstnom okviru za lozinku), gornji SQL izraz postao bi:

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

Ako bi ispitivač ušao John’– kao strUserName i bez strPassword, SQL izraz bi postao:

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

Imajte na umu da je dio SQL izraza nakon Johna pretvoren u komentar. Ako je u tablici Korisnici bilo korisnika s korisničkim imenom John, aplikacija bi mogla dopustiti ispitivaču da se prijavi kao korisnik John. Tester je sada mogao vidjeti privatne podatke korisnika Johna.

Što ako ispitivač ne zna ime niti jednog postojećeg korisnika aplikacije? U takvom slučaju ispitivač bi mogao isprobati uobičajena korisnička imena poput admin, administrator i sysadmin. Ako niti jedan od ovih korisnika ne postoji u bazi podataka, ispitivač bi mogao unijeti John 'ili' x '=' x kao strUserName i Smith 'ili' x '=' x kao strPassword. To bi uzrokovalo da SQL izraz postane poput onog u nastavku.

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

Budući da je uvjet 'x' = 'x' uvijek istinit, skup rezultata sastojao bi se od svih redaka u tablici Korisnici. Aplikacija može dopustiti ispitivaču da se prijavi kao prvi korisnik u tablici Korisnici.

Važno: Ispitivač bi trebao zatražiti od administratora baze podataka ili programera da kopira dotičnu tablicu prije pokušaja sljedećih napada.

Ako bi tester ušao u John ’; DROP tablica users_details; ’- kao strUserName i bilo što kao strPassword, SQL izraz postat će poput onog u nastavku.

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

Ova izjava može uzrokovati trajno brisanje tablice 'user_details' iz baze podataka.

Iako se gornji primjeri bave upotrebom tehnike ubrizgavanja SQL samo stranicom za prijavu, ispitivač bi trebao testirati ovu tehniku ​​na svim stranicama aplikacije koje prihvaćaju korisničke unose u tekstualnom formatu, npr. stranice za pretraživanje, stranice s povratnim informacijama itd.

SQL ubrizgavanje moglo bi biti moguće u aplikacijama koje koriste SSL. Čak ni vatrozid možda neće moći zaštititi aplikaciju od ove tehnike.

Pokušao sam objasniti ovu tehniku ​​napada u jednostavnom obliku. Želio bih ponoviti ovaj napad koji treba testirati samo u testnom okruženju, a ne u razvojnom okruženju, proizvodnom okruženju ili bilo kojem drugom okruženju.

prednosti linuxa u odnosu na Windows 10

Umjesto ručnog testiranja je li aplikacija ranjiva na SQL napad ili ne, mogao bi se koristiti a Skener za ranjivost weba koja provjerava ovu ranjivost.

Srodno čitanje: Ispitivanje sigurnosti web aplikacije . Provjerite ovo za više detalja o različitim web ranjivostima.

Ranjivi dijelovi ovog napada

Prije početka postupka testiranja, svaki iskreni ispitivač trebao bi više-manje znati koji bi dijelovi bili najosjetljiviji na mogući napad.

Također je dobra praksa planirati koje će se područje sustava točno testirati i kojim redoslijedom. U svojoj testnoj karijeri naučio sam da nije dobra ideja nasumično testirati polja protiv SQL napada jer neka polja mogu propustiti.

Kako se ovaj napad izvodi u bazi podataka, svi dijelovi sustava za unos podataka, polja za unos i veze do web mjesta su ranjivi.

Ranjivi dijelovi uključuju:

  • Polja za prijavu
  • Polja za pretraživanje
  • Polja komentara
  • Bilo koja druga polja za unos i spremanje podataka
  • Veze na web mjestu

Važno je primijetiti da tijekom testiranja protiv ovog napada nije dovoljno provjeriti samo jedno ili nekoliko polja. Sasvim je uobičajeno da jedno polje može biti zaštićeno od SQL Injection-a, ali onda drugo ne. Stoga je važno ne zaboraviti testirati sva polja web stranice.

Automatizacija testova ubrizgavanja SQL

Budući da neki testirani sustavi ili web stranice mogu biti prilično komplicirani i sadrže osjetljive podatke, ručno testiranje može biti doista teško i oduzima i puno vremena. Stoga testiranje protiv ovog napada pomoću posebnih alata ponekad može biti od velike pomoći.

Jedan od takvih alata za SQL Injection je KORISNIČKO sučelje SAPUN . Ako imamo automatizirane regresijske testove na razini API-ja, također možemo prebaciti provjeru protiv ovog napada pomoću ovog alata. U alatu SOAP UI već postoje pripremljeni predlošci koda za provjeru protiv ovog napada. Ti se predlošci također mogu nadopuniti vlastitim napisanim kodom.

To je prilično pouzdan alat.

Međutim, test bi već trebao biti automatiziran na razini API-ja, što nije tako lako. Drugi mogući način automatskog testiranja je upotreba različitih dodataka za preglednik.

Treba napomenuti da, čak i ako automatizirani alati štede vaše vrijeme, ne smatraju se uvijek vrlo pouzdanima. Ako testiramo bankarski sustav ili bilo koju web stranicu s vrlo osjetljivim podacima, toplo se preporučuje ručno testiranje. Gdje možete vidjeti točne rezultate i analizirati ih. Također, u ovom slučaju možemo biti sigurni da ništa nije preskočeno.

Usporedba s drugim napadima

SQL Injection može se smatrati jednim od najozbiljnijih napada, jer utječe na bazu podataka i može nanijeti ozbiljnu štetu vašim podacima i cijelom sustavu.

Sigurno može imati ozbiljnije posljedice od ubrizgavanja Javascripta ili HTML ubrizgavanja, jer se oba izvode na strani klijenta. Za usporedbu, ovim napadom možete imati pristup cijeloj bazi podataka.

Treba spomenuti da biste za testiranje protiv ovog napada trebali imati prilično dobro znanje programskog jezika SQL i općenito biste trebali znati kako rade upiti baza podataka. Također tijekom izvođenja ovog injekcijskog napada trebali biste biti oprezniji i pažljiviji, jer svaka netočnost može biti SQL ranjivost.

Zaključak

Nadam se da biste imali jasnu predodžbu o tome što je SQL ubrizgavanje i kako bismo trebali spriječiti ove napade.

Međutim, toplo se preporučuje testiranje protiv ove vrste napada svaki put kada se testira sustav ili web stranica s bazom podataka. Bilo koja preostala ranjivost baze podataka ili sustava može koštati reputacije tvrtke i puno resursa za vraćanje cijelog sustava.

Kako testiranje protiv ove injekcije pomaže pronaći najviše važne sigurnosne ranjivosti , također se preporučuje ulaganje u svoje znanje i alate za testiranje.

Ako je planirano sigurnosno testiranje, tada bi testiranje protiv SQL Injection trebalo biti planirano kao jedan od prvih dijelova testiranja.

Jeste li naišli na neko tipično SQL Injection? Slobodno podijelite svoja iskustva u odjeljku za komentare u nastavku.

Preporučena literatura

^