SQL Injection Testing Tutorial (Eksempel og forebyggelse af SQL Injection Attack)

sql injection testing tutorial example

Prøv Vores Instrument Til At Fjerne Problemer

test case management værktøjer open source

Vælg Operativsystemet Vælg Et Projektionsprojekt (Valgfrit)

Beskriv Dit Problem

SQL Injection Eksempler og måder at forhindre SQL Injection Attack på webapplikationer

Under test af et websted eller et system er testers mål at sikre, at det testede produkt er så meget beskyttet som muligt.

Sikkerhedstest udføres normalt til dette formål. For at udføre denne type test er vi i første omgang nødt til at overveje, hvilke angreb der mest sandsynligt vil ske. SQL Injection er et af disse angreb.

SQL Injection Attach eksempel og forebyggelse

SQL Injection betragtes som et af de mest almindelige angreb, da det kan medføre alvorlige og skadelige konsekvenser for dit system og følsomme data.

Hvad du lærer:

Hvad er SQL Injection?
Risici ved SQL-injektion
Essensen af dette angreb
Anbefalet værktøj
- # 1) Kiuwan
Sikkerhedstest af webapplikationer mod SQL-injektion
Sårbare dele af dette angreb
Automatisering af SQL Injection Tests
Sammenligning med andre angreb
Konklusion
Anbefalet læsning

Hvad er SQL Injection?

Nogle af brugerindgangene kan bruges til indramning SQL-udsagn der derefter udføres af applikationen i databasen. Det er muligt for en applikation IKKE at håndtere de input, der er givet af brugeren korrekt.

Hvis dette er tilfældet, en ondsindet bruger kunne give uventede input til applikationen, som derefter bruges til at indramme og udføre SQL-sætninger på databasen. Dette kaldes SQL Injection. Konsekvenserne af en sådan handling kan være alarmerende.

Som navnet selv antyder, er formålet med SQL Injection-angrebet at injicere den ondsindede SQL-kode.

Hvert felt på et websted er som en port til databasen. I loginformularen indtaster brugeren logindataene, i søgefeltet indtaster brugeren en søgetekst, i datalagringsformularen bruger brugeren data, der skal gemmes. Alle disse angivne data går til databasen.

I stedet for korrekte data, hvis der angives en ondsindet kode, er der muligheder for alvorlig skade for databasen og hele systemet.

SQL-injektion udføres med SQL-programmeringssprog. SQL (Structured Query Language) bruges til at styre de data, der opbevares i databasen. Derfor bruges denne programmeringssprogkode under dette angreb som en ondsindet injektion.

Dette er et af de mest populære angreb, da databaser bruges til næsten alle teknologier.

Mange applikationer bruger en eller anden type database. En applikation under test kan have en brugergrænseflade, der accepterer brugerinput, der bruges til at udføre følgende opgaver:

# 1) Vis de relevante lagrede data til brugeren, f.eks. applikationen kontrollerer brugerens legitimationsoplysninger ved hjælp af loginoplysninger, der er indtastet af brugeren, og udsætter kun den relevante funktionalitet og data for brugeren

#to) Gem de data, der er indtastet af brugeren, i databasen, f.eks. når brugeren udfylder en formular og sender den, fortsætter applikationen med at gemme dataene i databasen; disse data gøres derefter tilgængelige for brugeren i den samme session såvel som i de efterfølgende sessioner

Risici ved SQL-injektion

I dag bruges en database til næsten alle systemer og websteder, da data skal gemmes et eller andet sted.

Da følsomme data lagres i databasen, er der flere risici involveret i systemets sikkerhed. Hvis et personligt websted eller blogs data bliver stjålet, vil der ikke være meget skade sammenlignet med de data, der ville blive stjålet fra banksystemet.

Hovedformålet med dette angreb er at hacke systemets database, hvorfor konsekvenserne af dette angreb virkelig kan være skadelige.

Følgende ting kan skyldes SQL Injection

Hacking af andres konto.
Stjæling og kopiering af websides eller systemets følsomme data.
Ændring af systemets følsomme data.
Sletning af systemets følsomme data.
Brugeren kunne logge på applikationen som en anden bruger, selv som administrator.
Brugeren kunne se private oplysninger, der tilhører andre brugere, f.eks. detaljer om andre brugeres profiler, transaktionsoplysninger osv.
Brugeren kunne ændre oplysninger om applikationskonfiguration og dataene for de andre brugere.
Brugeren kunne ændre strukturen i databasen; slet endda tabeller i applikationsdatabasen.
Brugeren kunne tage kontrol over databaseserveren og udføre kommandoer på den efter eget valg.

Ovennævnte risici kan virkelig betragtes som alvorlige, da gendannelse af en database eller dens data kan koste meget. Det kan koste din virksomhed et ry og penge at gendanne de mistede data og systemet. Derfor anbefales det stærkt at beskytte dit system mod denne type angreb og overveje sikkerhedstestning som en god investering i dit produkts og virksomheds omdømme.

Som tester vil jeg gerne kommentere, at test mod mulige angreb er en god praksis, selvom Sikkerhedstest ikke var planlagt. På denne måde kan du beskytte og teste produktet mod uventede tilfælde og ondsindede brugere.

Essensen af dette angreb

Som nævnt tidligere er essensen af dette angreb at hacke databasen med et ondsindet formål.

For at udføre denne sikkerhedstest skal du først finde de sårbare systemdele og derefter sende ondsindet SQL-kode gennem dem til databasen. Hvis dette angreb er muligt for et system, sendes passende ondsindet SQL-kode, og der kan muligvis udføres skadelige handlinger i databasen.

Hvert felt på et websted er som en port til databasen. Alle data eller input, som vi normalt indtaster i ethvert felt på systemet eller webstedet, går til databaseforespørgslen. Derfor, i stedet for korrekte data, hvis vi skriver en ondsindet kode, kan den muligvis udføres i databaseforespørgslen og medføre skadelige konsekvenser.

Anbefalet værktøj

# 1) Kiuwan

kiuwan banner

Find og ret nemt sårbarheder som SQL-injektion i din kode på hvert trin i SDLC. Kiuwan overholder de strengeste sikkerhedsstandarder, herunder OWASP, CWE, SANS 25, HIPPA og mere.

Integrer Kiuwan i din IDE for øjeblikkelig feedback under udvikling. Kiuwan understøtter alle større programmeringssprog og integreres med førende DevOps-værktøjer.

=> Scan din kode gratis

For at udføre dette angreb er vi nødt til at ændre handlingen og formålet med en passende databaseforespørgsel. En af de mulige metoder til at udføre det er at gøre forespørgslen altid sand og derefter indsætte din ondsindede kode. Ændring af databaseforespørgsel til altid sand kan udføres med simpel kode som ‘eller 1 = 1; -.

Essensen af SQL Injection

Testere skal huske på, at mens der kontrolleres, om ændring af forespørgslen til altid sand kan udføres eller ej, skal forskellige citater prøves - enkelt og dobbelt. Derfor, hvis vi har prøvet kode som ‘eller 1 = 1; -, bør vi også prøve koden med dobbelt anførselstegn“ eller 1 = 1; -.

Essensce of SQL Injection

For eksempel, lad os overveje, at vi har en forespørgsel, der søger efter det indtastede ord i databasetabellen:

vælg * fra noter nt hvor nt.subject = ‘search_word’;

Derfor i stedet for søgeordet, hvis vi indtaster en SQL Injection-forespørgsel ‘eller 1 = 1; -, bliver forespørgslen altid sand.

vælg * fra noter nt hvor nt.subject = ‘‘ eller 1 = 1; -

I dette tilfælde lukkes parameteren 'emne' med citatet, og så har vi kode eller 1 = 1, hvilket gør en forespørgsel altid sand. Med tegnet “-“ kommenterer vi resten af forespørgselskoden, som ikke udføres. Det er en af de mest populære og nemmeste måder at begynde at kontrollere forespørgslen på.

Få andre koder kan også bruges til at gøre forespørgslen altid sand, som:

'Eller' abc '=' abc '; -
‘Eller‘ ‘=‘ ‘; -

Den vigtigste del her er, at efter komma-tegn kan vi indtaste enhver ondsindet kode, som vi gerne vil udføre.

For eksempel, det kan være ‘eller 1 = 1; drop tabel noter; -

Bemærkninger til tabellen

Hvis denne injektion er mulig, kan der skrives enhver anden ondsindet kode. I dette tilfælde afhænger det kun af den ondsindede brugers viden og hensigt. Hvordan kontrolleres SQL-injektion?

Kontrol af denne sårbarhed kan udføres meget let. Nogle gange er det nok at skrive 'eller' logge på de testede felter. Hvis det returnerer en uventet eller ekstraordinær besked, kan vi være sikre på, at SQL Injection er mulig for dette felt.

For eksempel , hvis du får en fejlmeddelelse som 'Intern serverfejl' som et søgeresultat, kan vi være sikre på, at dette angreb er muligt i den del af systemet.

Andre resultater, der kan meddele mulige angreb, inkluderer:

Tom side er indlæst.
Ingen fejl- eller succesmeddelelser - funktionalitet og side reagerer ikke på input.
Succesmeddelelse for ondsindet kode.

Lad os se omkring på, hvordan dette fungerer i praksis.

For eksempel, Lad os teste, om et passende loginvindue er sårbart for SQL Injection. Til dette formål skriver vi bare tegn som vist nedenfor i e-mail-adressen eller adgangskodefeltet.

Email adresse

Hvis sådan input returnerer et resultat som en fejlmeddelelse 'Intern serverfejl' eller ethvert andet listet upassende resultat, så kan vi næsten være sikre på, at dette angreb er muligt for det felt.

Intern serverfejl

En meget vanskelig SQL-injektionskode kan også prøves. Jeg vil gerne nævne, at jeg i min karriere ikke har stødt på noget tilfælde, hvor der var meddelelsen 'Intern serverfejl' som et resultat af tegnet, men til tider reagerede felterne ikke for mere kompliceret SQL-kode.

Derfor er det en pålidelig måde at kontrollere, om dette angreb er muligt eller ej, at kontrollere for SQL Injection med et enkelt citat.

Hvis det enkelte tilbud ikke returnerer noget upassende resultat, kan vi prøve at indtaste dobbelt tilbud og kontrollere resultaterne.

Enkelt tilbud

SQL-kode til ændring af forespørgslen til altid sand kan også betragtes som en måde at kontrollere, om dette angreb er muligt eller ej. Det lukker parameteren og ændrer forespørgslen til 'sand'. Derfor kan sådanne input, hvis de ikke valideres, også returnere ethvert uventet resultat og informere det samme om, at dette angreb er muligt i dette tilfælde.

Essensce of SQL Injection

Kontrol af mulige SQL-angreb kan også udføres fra webstedets link. Antag, at vi har et websides link som http://www.testing.com/books=1 . I dette tilfælde er 'bøger' en parameter, og '1' er dens værdi. Hvis vi i det medfølgende link ville skrive 'tegn i stedet for 1, så ville vi kontrollere, om der er mulig injektion.

Derfor link http://www.testing.com/books= vil være som en test, hvis SQL-angrebet er muligt for webstedet http://www.testing.com eller ikke.

Test Link

I dette tilfælde, hvis link http://www.testing.com/books= returnerer en fejlmeddelelse som 'Intern serverfejl' eller en tom side eller enhver anden uventet fejlmeddelelse, så kan vi også være sikre på, at SQL Injection er mulig for det websted. Senere kan vi prøve at sende mere vanskelig SQL-kode via webstedslinket.

For at kontrollere, om dette angreb er muligt via webstedets link eller ej, kan kode som 'eller 1 = 1; - også sendes.

Test af links

Som en erfaren softwaretester vil jeg gerne minde om, at ikke kun den uventede fejlmeddelelse kan betragtes som en SQL Injection-sårbarhed. Mange testere kontrollerer kun for mulige angreb i overensstemmelse med fejlmeddelelser.

Det skal dog huskes, at ingen valideringsfejlmeddelelse eller succesmeddelelse for ondsindet kode også kan være et tegn på, at dette angreb er muligt.

Sikkerhedstest af webapplikationer mod SQL-injektion

Sikkerhedstest af webapplikationer forklaret med enkle eksempler:

Da konsekvenserne af at tillade denne sårbarhedsteknik kan være alvorlige, følger det, at dette angreb skal testes under sikkerhedstesten af en applikation. Nu med et overblik over denne teknik, lad os forstå et par praktiske eksempler på SQL-injektion.

Vigtigt: Denne SQL Injection Test bør kun testes i testmiljøet.

Hvis applikationen har en login-side, er det muligt, at applikationen bruger dynamisk SQL som f.eks. Udsagnet nedenfor. Denne erklæring forventes at returnere mindst en enkelt række med brugeroplysningerne fra tabellen Brugere som resultatsæt, når der er en række med brugernavn og adgangskode indtastet i SQL-sætningen.

VÆLG * FRA brugere WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & '’; '

Hvis testeren ville indtaste John som strUserName (i tekstboksen for brugernavn) og Smith som strPassword (i tekstboksen for adgangskode), ville ovenstående SQL-sætning blive:

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

Hvis testeren ville indtaste John’– som strUserName og ikke noget strPassword, ville SQL-sætningen blive:

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

Bemærk, at den del af SQL-sætningen efter John bliver til en kommentar. Hvis der var nogen bruger med brugernavnet John i tabellen Brugere, kunne applikationen tillade testeren at logge ind som brugeren John. Testeren kunne nu se brugerens private oplysninger.

Hvad hvis testeren ikke kender navnet på nogen eksisterende bruger af applikationen? I et sådant tilfælde kunne testeren prøve almindelige brugernavne som admin, administrator og sysadmin. Hvis ingen af disse brugere findes i databasen, kunne testeren indtaste John 'eller' x '=' x som strUserName og Smith 'eller' x '=' x som strPassword. Dette ville få SQL-sætningen til at ligne den nedenfor.

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

Da 'x' = 'x' -tilstand altid er sand, vil resultatsættet bestå af alle rækkerne i tabellen Brugere. Applikationen kan give testeren mulighed for at logge ind som den første bruger i tabellen Brugere.

Vigtigt: Testeren skal anmode databaseadministratoren eller udvikleren om at kopiere den pågældende tabel, inden de prøver på følgende angreb.

Hvis testeren ville komme ind i John '; DROP-tabel users_details; ’- som strUserName og alt som strPassword, vil SQL-sætningen blive som den nedenfor.

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

Denne erklæring kan medføre, at tabellen 'brugere_detaljer' slettes permanent fra databasen.

Selvom ovenstående eksempler kun bruger SQL-injektionsteknikken login-siden, skal testeren teste denne teknik på alle siderne i applikationen, der accepterer brugerinput i tekstformat, f.eks. søgesider, feedback-sider osv.

SQL-injektion er muligvis mulig i applikationer, der bruger SSL. Selv en firewall kan muligvis ikke beskytte applikationen mod denne teknik.

Jeg har forsøgt at forklare denne angrebsteknik i en simpel form. Jeg vil gerne gentage dette angreb skal kun testes i et testmiljø og ikke i udviklingsmiljøet, produktionsmiljøet eller ethvert andet miljø.

hvordan man programmerer computere til begyndere

I stedet for manuelt at teste, om applikationen er sårbar over for SQL-angreb eller ej, kunne man bruge en Web-sårbarhedsscanner der kontrollerer for denne sårbarhed.

Relateret læsning: Sikkerhedstest af webapplikationen . Tjek dette for at få flere oplysninger om forskellige websårbarheder.

Sårbare dele af dette angreb

Inden testprocessen påbegyndes, bør hver oprigtig tester mere eller mindre vide, hvilke dele der er mest sårbare over for dette angreb.

Det er også en god praksis at planlægge, hvilket felt i systemet der skal testes nøjagtigt og i hvilken rækkefølge. I min testkarriere har jeg lært, at det ikke er en god ide at teste felter mod SQL-angreb tilfældigt, da nogle felter kan gå glip af.

Da dette angreb udføres i databasen, er alle dataindtastningssystemdele, indtastningsfelter og websitelinks sårbare.

Sårbare dele inkluderer:

Login felter
Søg i felter
Kommentarfelter
Enhver anden dataindtastning og lagring af felter
Websteds links

Det er vigtigt at bemærke, at mens det testes mod dette angreb, er det ikke nok kun at kontrollere et eller et par felter. Det er ret almindeligt, at et felt kan være beskyttet mod SQL Injection, men så gør et andet ikke. Derfor er det vigtigt ikke at glemme at teste alle webstedsfelterne.

Automatisering af SQL Injection Tests

Da nogle testede systemer eller websteder kan være ret komplicerede og indeholde følsomme data, kan manuel test være virkelig vanskelig, og det tager også meget tid. Derfor kan test til dette angreb med specielle værktøjer til tider være virkelig nyttige.

Et sådant SQL Injection-værktøj er SOAP UI . Hvis vi har automatiserede regressionstest på API-niveau, kan vi også skifte kontrol mod dette angreb ved hjælp af dette værktøj. I SOAP UI-værktøjet er der allerede udarbejdede kodeskabeloner til kontrol mod dette angreb. Disse skabeloner kan også suppleres med din egen skrevne kode.

Det er et ret pålideligt værktøj.

En test skal dog allerede være automatiseret på API-niveau, hvilket ikke er så let. En anden mulig måde at teste automatisk på er ved hjælp af forskellige browser-plugins.

Det skal nævnes, at selvom automatiserede værktøjer sparer din tid, anses de ikke altid for at være meget pålidelige. Hvis vi tester et banksystem eller et websted med meget følsomme data, anbefales det stærkt at teste det manuelt. Hvor du kan se de nøjagtige resultater og analysere dem. I dette tilfælde kan vi også være sikre på, at intet blev sprunget over.

Sammenligning med andre angreb

SQL Injection kan betragtes som et af de mest alvorlige angreb, da det påvirker databasen og kan skade dine data og hele systemet alvorligt.

Det kan helt sikkert have mere alvorlige konsekvenser end en Javascript Injection eller HTML Injection, da begge udføres på klientsiden. Til sammenligning med dette angreb kan du få adgang til hele databasen.

Det skal nævnes, at for at teste mod dette angreb, skal du have ret godt kendskab til SQL-programmeringssprog, og generelt skal du vide, hvordan databaseforespørgsler fungerer. Også når du udfører dette injektionsangreb, skal du være mere forsigtig og opmærksom, da enhver unøjagtighed kan efterlades som SQL-sårbarheder.

Konklusion

Jeg håber, du ville have fået en klar idé om, hvad en SQL Injection er, og hvordan skal vi forhindre disse angreb.

Det anbefales dog stærkt at teste mod denne type angreb hver gang et system eller et websted med en database testes. Enhver venstre database eller systemsårbarhed kan koste en virksomheds omdømme og en masse ressourcer for at gendanne hele systemet.

Da test mod denne injektion hjælper med at finde mest vigtige sikkerhedssårbarheder , anbefales det også at investere i din viden og dine testværktøjer.

Hvis sikkerhedstestning er planlagt, skal testning mod SQL Injection planlægges som en af de første testdele.

Har du stødt på nogen typisk SQL Injection? Del gerne dine oplevelser i kommentarfeltet nedenfor.