SQL Injection Testing Tutorial (Eksempel og forebygging av SQL Injection Attack)

sql injection testing tutorial example

SQL Injection Eksempler og måter å forhindre SQL Injection Attack på webapplikasjoner

Under testing av et nettsted eller et system er testeren som mål å sikre om det testede produktet er så mye beskyttet som mulig.

Sikkerhetstesting utføres vanligvis for dette formålet. For å kunne utføre denne typen testing, må vi først vurdere hvilke angrep som mest sannsynlig vil skje. SQL Injection er et av disse angrepene.

SQL Injection regnes som et av de vanligste angrepene, da det kan føre til alvorlige og skadelige konsekvenser for systemet ditt og sensitive data.

Hva du vil lære:

• Hva er SQL Injection?
• Risiko for SQL-injeksjon
• Essensen av dette angrepet
• Anbefalt verktøy
  • # 1) Kiuwan
• Sikkerhetstesting av webapplikasjoner mot SQL-injeksjon
• Sårbare deler av dette angrepet
• Automatisering av SQL Injection Tests
• Sammenligning med andre angrep
• Konklusjon
• Anbefalt lesing

Hva er SQL Injection?

Noen av brukerinngangene kan brukes i innramming SQL-uttalelser som deretter kjøres av applikasjonen i databasen. Det er mulig for et program IKKE å håndtere inngangene gitt av brukeren riktig.

Hvis dette er tilfelle, en ondsinnet bruker kan gi uventede innganger til applikasjonen som deretter brukes til å ramme inn og utføre SQL-setninger på databasen. Dette kalles SQL Injection. Konsekvensene av en slik handling kan være alarmerende.

Som navnet tilsier, er formålet med SQL Injection-angrepet å injisere den ondsinnede SQL-koden.

Hvert felt på et nettsted er som en port til databasen. I påloggingsskjemaet legger brukeren inn påloggingsdataene, i søkefeltet brukeren skriver inn en søketekst, i datalagringsskjemaet brukeren legger inn data som skal lagres. Alle disse angitte dataene går til databasen.

I stedet for riktige data, hvis det oppgis skadelig kode, er det muligheter for alvorlig skade på databasen og hele systemet.

SQL Injection utføres med SQL-programmeringsspråket. SQL (Structured Query Language) brukes til å administrere dataene som holdes i databasen. Derfor brukes dette programmeringsspråkkoden under dette angrepet som en ondsinnet injeksjon.

Dette er et av de mest populære angrepene, ettersom databaser brukes til nesten alle teknologiene.

Mange applikasjoner bruker en hvilken som helst type database. Et program som testes kan ha et brukergrensesnitt som godtar brukerinngang som brukes til å utføre følgende oppgaver:

#1) Vis relevante lagrede data til brukeren f.eks. applikasjonen sjekker legitimasjonen til brukeren ved hjelp av påloggingsinformasjonen som er angitt av brukeren og eksponerer bare relevant funksjonalitet og data for brukeren

#to) Lagre dataene som er angitt av brukeren i databasen, f.eks. når brukeren fyller ut et skjema og sender det, fortsetter applikasjonen med å lagre dataene i databasen; disse dataene blir deretter gjort tilgjengelig for brukeren i samme økt så vel som i påfølgende økter

Risiko for SQL-injeksjon

I dag brukes en database for nesten alle systemer og nettsteder, ettersom data skal lagres et sted.

Siden sensitive data lagres i databasen, er det flere risikoer involvert i systemets sikkerhet. Hvis data fra et personlig nettsted eller blogg blir stjålet, blir det ikke mye skade sammenlignet med dataene som vil bli stjålet fra banksystemet.

Hovedformålet med dette angrepet er å hacke systemets database, derfor kan dette angrepets konsekvenser være skadelige.

Følgende ting kan skyldes SQL Injection

• Hacking av andres konto.
• Stjeling og kopiering av sensitive eller sensitive nettstedsdata.
• Endring av systemets sensitive data.
• Slette systemets sensitive data.
• Brukeren kan logge på applikasjonen som en annen bruker, selv som administrator.
• Brukeren kunne se privat informasjon som tilhører andre brukere, f.eks. detaljer om andre brukeres profiler, transaksjonsdetaljer osv.
• Brukeren kan endre informasjon om applikasjonskonfigurasjon og dataene til de andre brukerne.
• Brukeren kunne endre strukturen i databasen; til og med slette tabeller i applikasjonsdatabasen.
• Brukeren kan ta kontroll over databaseserveren og utføre kommandoer på den etter eget ønske.

Ovennevnte risikoer kan virkelig betraktes som alvorlige, da gjenoppretting av en database eller dens data kan koste mye. Det kan koste bedriften et rykte og penger å gjenopprette tapte data og system. Derfor anbefales det sterkt å beskytte systemet ditt mot denne typen angrep og vurdere sikkerhetstesting som en god investering i produktets og selskapets omdømme.

Som tester vil jeg kommentere at testing mot mulige angrep er en god praksis selv om Sikkerhetstesting var ikke planlagt. På denne måten kan du beskytte og teste produktet mot uventede tilfeller og ondsinnede brukere.

Essensen av dette angrepet

Som nevnt tidligere er essensen av dette angrepet å hacke databasen med ondsinnet formål.

For å kunne utføre denne sikkerhetstesten må du først finne de sårbare systemdelene og deretter sende skadelig SQL-kode gjennom dem til databasen. Hvis dette angrepet er mulig for et system, vil passende skadelig SQL-kode bli sendt, og skadelige handlinger kan utføres i databasen.

Hvert felt på et nettsted er som en port til databasen. Alle data eller innspill som vi vanligvis legger inn i et hvilket som helst felt på systemet eller nettstedet, går til databasesøket. Derfor, i stedet for riktige data, hvis vi skriver inn skadelig kode, kan den kjøres i databasespørringen og gi skadelige konsekvenser.

Anbefalt verktøy

# 1) Kiuwan

Det er enkelt å finne og fikse sårbarheter som SQL-injeksjon i koden din på hvert trinn av SDLC. Kiuwan overholder de strengeste sikkerhetsstandardene, inkludert OWASP, CWE, SANS 25, HIPPA og mer.

Integrer Kiuwan i IDE-en din for øyeblikkelig tilbakemelding under utviklingen. Kiuwan støtter alle de viktigste programmeringsspråkene og integreres med ledende DevOps-verktøy.

=> Skann koden din gratis

For å utføre dette angrepet må vi endre handlingen og formålet med et passende databasespørsmål. En av de mulige metodene for å utføre det er å gjøre spørringen alltid sant og deretter sette inn din ondsinnede kode. Endring av databasespørringen til alltid true kan utføres med enkel kode som ‘eller 1 = 1; -.

Testere bør huske at mens du sjekker om du kan utføre spørringen til alltid sant eller ikke, bør forskjellige sitater prøves - enkelt og dobbelt. Derfor, hvis vi har prøvd kode som ‘eller 1 = 1; -, bør vi også prøve koden med doble anførselstegn“ eller 1 = 1; -.

For eksempel, la oss vurdere at vi har et spørsmål som søker etter det oppgitte ordet i databasetabellen:

velg * fra notater nt der nt.subject = ‘search_word’;

Derfor, i stedet for søkeordet, hvis vi skriver inn et SQL Injection-spørsmål ‘eller 1 = 1; -, blir spørringen alltid sant.

velg * fra notater nt der nt.subject = ‘‘ eller 1 = 1; -

I dette tilfellet lukkes parameteren “subject” med sitatet, og da har vi kode eller 1 = 1, noe som gjør at et spørsmål alltid er sant. Med skiltet “-“ kommenterer vi resten av spørringskoden, som ikke vil bli utført. Det er en av de mest populære og enkleste måtene å begynne å kontrollere spørringen.

Få andre koder kan også brukes til å gjøre spørringen alltid sant, som:

• ‘Eller‘ abc ’=‘ abc ’; -
• ‘Eller‘ ‘=‘ ‘; -

Den viktigste delen her er at etter kommategn kan vi angi hvilken som helst ondsinnet kode som vi ønsker å bli henrettet.

For eksempel, det kan være ‘eller 1 = 1; slipp tabellnotater; -

Hvis denne injeksjonen er mulig, kan det skrives annen skadelig kode. I dette tilfellet vil det bare avhenge av den ondsinnede brukerens kunnskap og intensjon. Hvordan sjekke SQL Injection?

Det kan enkelt utføres å sjekke for dette sikkerhetsproblemet. Noen ganger er det nok å skrive ‘eller“ logge på de testede feltene. Hvis det returnerer en uventet eller ekstraordinær melding, kan vi være sikre på at SQL Injection er mulig for det feltet.

For eksempel , hvis du får en feilmelding som ‘Intern serverfeil’ som et søkeresultat, så kan vi være sikre på at dette angrepet er mulig i den delen av systemet.

Andre resultater som kan varsle mulig angrep inkluderer:

• Tom side lastet inn.
• Ingen feil- eller suksessmeldinger - funksjonalitet og side reagerer ikke på inngangen.
• Suksessmelding for skadelig kode.

La oss se oss om hvordan dette fungerer i praksis.

For eksempel, La oss teste om et passende påloggingsvindu er sårbart for SQL Injection. For dette formålet, i e-postadressen eller passordfeltet, skriver vi bare sign som vist nedenfor.

Hvis slik inngang returnerer resultat som feilmelding ‘Intern serverfeil’ eller et annet oppført upassende resultat, kan vi nesten være sikre på at dette angrepet er mulig for det feltet.

En veldig vanskelig SQL-injeksjonskode kan også prøves. Jeg vil nevne at jeg i karrieren ikke har opplevd noe tilfelle da det var 'Internal Server Error' -melding som et resultat av tegnet, men til tider reagerte ikke feltene for mer komplisert SQL-kode.

Derfor er det en pålitelig måte å sjekke om SQL Injection med et enkelt tilbud er å sjekke om dette angrepet er mulig eller ikke.

Hvis det eneste tilbudet ikke gir noe upassende resultat, kan vi prøve å legge inn doble tilbud og sjekke resultatene.

SQL-kode for å endre spørringen til alltid true kan betraktes som en måte å sjekke om dette angrepet er mulig eller ikke. Den lukker parameteren og endrer spørringen til ‘true’. Hvis ikke dette blir validert, kan slike innganger også returnere et uventet resultat og informere det samme om at dette angrepet er mulig i dette tilfellet.

Kontroll av mulige SQL-angrep kan også utføres fra nettstedets lenke. Anta at vi har en nettsteds lenke som http://www.testing.com/books=1 . I dette tilfellet er ‘bøker’ en parameter og ‘1’ er verdien. Hvis vi i den oppgitte lenken ville skrive ‘tegn i stedet for 1, ville vi sjekke om det er mulig injeksjon.

Derfor lenke http://www.testing.com/books= vil være som en test hvis SQL-angrepet er mulig for nettstedet http://www.testing.com eller ikke.

I dette tilfellet, hvis link http://www.testing.com/books= returnerer en feilmelding som ‘Intern serverfeil’ eller en tom side eller annen uventet feilmelding, så kan vi også være sikre på at SQL Injection er mulig for det nettstedet. Senere kan vi prøve å sende mer vanskelig SQL-kode gjennom nettstedets lenke.

For å kontrollere om dette angrepet er mulig via nettstedets lenke eller ikke, kan kode som ‘eller 1 = 1; - også sendes.

Som en erfaren programvaretester vil jeg minne om at ikke bare den uventede feilmeldingen kan betraktes som et SQL Injection-sårbarhet. Mange testere ser etter mulige angrep bare i samsvar med feilmeldinger.

Det skal imidlertid huskes at ingen valideringsfeilmeldinger eller suksessmeldinger for ondsinnet kode også kan være et tegn på at dette angrepet er mulig.

Sikkerhetstesting av webapplikasjoner mot SQL-injeksjon

Sikkerhetstesting av webapplikasjoner forklart med enkle eksempler:

Siden konsekvensene av å tillate denne sårbarhetsteknikken kan være alvorlige, følger det at dette angrepet bør testes under sikkerhetstesten av et program. Nå med en oversikt over denne teknikken, la oss forstå noen få praktiske eksempler på SQL-injeksjon.

Viktig: Denne SQL-injeksjonstesten skal bare testes i testmiljøet.

Hvis applikasjonen har en påloggingsside, er det mulig at applikasjonen bruker dynamisk SQL, slik som utsagnet nedenfor. Denne uttalelsen forventes å returnere minst en enkelt rad med brukeropplysningene fra tabellen Brukere som resultat satt når det er en rad med brukernavn og passord angitt i SQL-setningen.

VELG * FRA brukere WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & '’; '

Hvis testeren ville angi John som strUserName (i tekstboksen for brukernavn) og Smith som strPassword (i tekstboksen for passord), ville SQL-setningen ovenfor bli:

Hvis testeren ville angi John’– som strUserName og ikke noe strPassword, ville SQL-setningen bli:

Merk at den delen av SQL-setningen etter John blir omgjort til en kommentar. Hvis det var noen brukere med brukernavnet til John i tabellen Brukere, kunne applikasjonen tillate testeren å logge på som brukeren John. Testeren kunne nå se den private informasjonen til brukeren John.

Hva om testeren ikke vet navnet på en eksisterende bruker av applikasjonen? I et slikt tilfelle kan testeren prøve vanlige brukernavn som admin, administrator og sysadmin. Hvis ingen av disse brukerne finnes i databasen, kan testeren angi John ’eller‘ x ’=’ x som strUserName og Smith ’eller‘ x ’=’ x som strPassword. Dette vil føre til at SQL-setningen blir som den nedenfor.

Siden 'x' = 'x' er alltid sant, vil resultatsettet bestå av alle radene i tabellen Brukere. Applikasjonen kan tillate testeren å logge på som den første brukeren i tabellen Brukere.

Viktig: Testeren bør be databaseadministratoren eller utvikleren om å kopiere den aktuelle tabellen før du prøver følgende angrep.

Hvis testeren ville komme inn i John ’; DROP-tabellen brukere_detaljer; ’- som strUserName og alt som strPassword, vil SQL-setningen bli som den nedenfor.

Denne uttalelsen kan føre til at tabellen 'brukere_detaljer' slettes permanent fra databasen.

Selv om eksemplene ovenfor handler om å bruke SQL-injeksjonsteknikken bare påloggingssiden, bør testeren teste denne teknikken på alle sidene i applikasjonen som godtar brukerinngang i tekstformat, f.eks. søkesider, tilbakemeldingssider osv.

SQL-injeksjon kan være mulig i applikasjoner som bruker SSL. Selv en brannmur kan ikke være i stand til å beskytte applikasjonen mot denne teknikken.

Jeg har prøvd å forklare denne angrepsteknikken i en enkel form. Jeg vil gjenta dette angrepet skal bare testes i et testmiljø og ikke i utviklingsmiljøet, produksjonsmiljøet eller noe annet miljø.

legg til et element i en matrise

I stedet for manuelt å teste om applikasjonen er sårbar for SQL-angrep eller ikke, kan man bruke en Web-sårbarhetsskanner som ser etter dette sikkerhetsproblemet.

Relatert lesing: Sikkerhetstesting av webapplikasjonen . Sjekk dette for mer informasjon om forskjellige nettsårbarheter.

Sårbare deler av dette angrepet

Før du starter testprosessen, bør hver oppriktig tester mer eller mindre vite hvilke deler som vil være mest sårbare for mulig dette angrepet.

Det er også en god praksis å planlegge hvilket felt i systemet som skal testes nøyaktig og i hvilken rekkefølge. I testkarrieren har jeg lært at det ikke er en god idé å teste felt mot SQL-angrep tilfeldig, da noen felt kan bli savnet.

Ettersom dette angrepet utføres i databasen, er alle systeminnsatsene for dataregistrering, inndatafelt og lenker til nettsteder sårbare.

Sårbare deler inkluderer:

• Påloggingsfelt
• Søk i felt
• Kommentarfelt
• Eventuell annen dataregistrering og lagring av felt
• Nettsteds lenker

Det er viktig å legge merke til at mens det testes mot dette angrepet, er det ikke nok å bare sjekke ett eller noen få felt. Det er ganske vanlig at ett felt kan være beskyttet mot SQL Injection, men et annet gjør det ikke. Derfor er det viktig å ikke glemme å teste alle nettstedets felt.

Automatisering av SQL Injection Tests

Siden noen testede systemer eller nettsteder kan være ganske kompliserte og inneholde sensitive data, kan det være veldig vanskelig å teste manuelt, og det tar også mye tid. Derfor kan det være veldig nyttig å teste mot dette angrepet med spesialverktøy til tider.

Et slikt SQL Injection-verktøy er SOAP UI . Hvis vi har automatiserte regresjonstester på API-nivå, kan vi også bytte mot dette angrepet ved hjelp av dette verktøyet. I SOAP UI-verktøyet er det allerede utarbeidede kodemaler for å sjekke mot dette angrepet. Disse malene kan også suppleres med din egen skriftlige kode.

Det er et ganske pålitelig verktøy.

Imidlertid bør en test allerede være automatisert på API-nivå, noe som ikke er så enkelt. En annen mulig måte å teste automatisk er ved å bruke forskjellige nettleser-plugins.

Det bør nevnes at selv om automatiserte verktøy sparer tid, blir de ikke alltid ansett for å være veldig pålitelige. Hvis vi tester et banksystem eller et hvilket som helst nettsted med veldig sensitive data, anbefales det sterkt å teste det manuelt. Hvor du kan se de eksakte resultatene og analysere dem. I dette tilfellet kan vi være sikre på at ingenting ble hoppet over.

Sammenligning med andre angrep

SQL Injection kan betraktes som et av de mest alvorlige angrepene, da det påvirker databasen og kan skade dataene dine og hele systemet.

Det kan helt sikkert få alvorligere konsekvenser enn en Javascript Injection eller HTML Injection, da begge utføres på klientsiden. Til sammenligning, med dette angrepet, kan du få tilgang til hele databasen.

Det bør nevnes at for å teste mot dette angrepet, bør du ha ganske god kunnskap om SQL-programmeringsspråk, og generelt sett bør du vite hvordan databaser spørringer fungerer. Også når du utfører dette injeksjonsangrepet, bør du være mer forsiktig og være oppmerksom, da enhver unøyaktighet kan bli liggende som SQL-sårbarhet.

Konklusjon

Jeg håper du ville ha fått en klar ide om hva en SQL Injection er og hvordan skal vi forhindre disse angrepene.

Det anbefales imidlertid sterkt å teste mot denne typen angrep hver gang et system eller et nettsted med en database blir testet. En hvilken som helst venstre sårbarhet i databasen eller systemet kan koste selskapets omdømme og mange ressurser for å gjenopprette hele systemet.

Ettersom testing mot denne injeksjonen bidrar til å finne mest mulig viktige sikkerhetsproblemer , anbefales det også å investere i kunnskap og testverktøy.

Hvis sikkerhetstesting er planlagt, bør testing mot SQL Injection planlegges som en av de første testdelene.

Har du kommet over noen typisk SQL Injection? Del gjerne dine erfaringer i kommentarfeltet nedenfor.

Anbefalt lesing

• HTML Injection Tutorial: Typer og forebygging med eksempler
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• In-Depth Eclipse Tutorials For Beginners
• Destruktiv testing og ikke-destruktiv testing
• Testing Primer eBook Download
• Funksjonstesting mot ikke-funksjonell testing
• SOA Testing Tutorial: Testing Methodology For a SOA Architecture Model
• Pairwise Testing eller All-Pairs Testing Tutorial med verktøy og eksempler