SQL Injection Testing Tutorial (Exempel och förebyggande av SQL Injection Attack)

sql injection testing tutorial example

SQL Injection Exempel och sätt att förhindra SQL Injection Attacks på webbapplikationer

Under testning av en webbplats eller ett system är testarens mål att säkerställa att den testade produkten är så mycket skyddad som möjligt.

Säkerhetstester utförs vanligtvis för detta ändamål. För att kunna utföra den här typen av tester måste vi inledningsvis överväga vilka attacker som mest sannolikt kommer att hända. SQL Injection är en av dessa attacker.

SQL Injection anses vara en av de vanligaste attackerna eftersom det kan ge allvarliga och skadliga konsekvenser för ditt system och känsliga data.

Vad du kommer att lära dig:

• Vad är SQL-injektion?
• Risker med SQL-injektion
• Essensen av denna attack
• Rekommenderat verktyg
  • # 1) Kiuwan
• Säkerhetstestning av webbapplikationer mot SQL-injektion
• Sårbara delar av denna attack
• Automatisera SQL-injektionstester
• Jämförelse med andra attacker
• Slutsats
• Rekommenderad läsning

Vad är SQL-injektion?

Några av användaringångarna kan användas i inramningen SQL-uttalanden som sedan körs av applikationen i databasen. Det är möjligt för en applikation att INTE hantera de ingångar som ges av användaren ordentligt.

Om detta är fallet, en skadlig användare kan ge oväntade ingångar till applikationen som sedan används för att inrama och köra SQL-satser i databasen. Detta kallas SQL Injection. Konsekvenserna av en sådan åtgärd kan vara alarmerande.

Som namnet själv antyder är syftet med SQL Injection-attacken att injicera den skadliga SQL-koden.

Varje fält på en webbplats är som en port till databasen. I inloggningsformuläret anger användaren inloggningsdata, i sökfältet anger användaren en söketekst, i datalagringsformuläret anger användaren data som ska sparas. Alla dessa angivna data går till databasen.

I stället för korrekta data, om någon skadlig kod anges, finns det möjligheter för allvarlig skada att hända databasen och hela systemet.

SQL-injektion utförs med SQL-programmeringsspråket. SQL (Structured Query Language) används för att hantera data som finns i databasen. Därför används den här programmeringsspråkkoden som en skadlig injektion under denna attack.

Detta är en av de mest populära attackerna, eftersom databaser används för nästan all teknik.

Många applikationer använder någon typ av databas. Ett program som testas kan ha ett användargränssnitt som accepterar användarinmatning som används för att utföra följande uppgifter:

# 1) Visa relevant lagrad data till användaren, t.ex. applikationen kontrollerar användarens referenser med hjälp av inloggningsinformationen som anges av användaren och exponerar endast relevant funktionalitet och data för användaren

#två) Spara de data som användaren har angett i databasen, t.ex. när användaren fyller i ett formulär och skickar det fortsätter applikationen att spara data i databasen. dessa data görs sedan tillgängliga för användaren i samma session och i efterföljande sessioner

Risker med SQL-injektion

Numera används en databas för nästan alla system och webbplatser, eftersom data bör lagras någonstans.

Eftersom känslig data lagras i databasen finns det fler risker med systemets säkerhet. Om någon personlig webbplats eller bloggs data skulle stulas kommer det inte att bli mycket skada jämfört med de uppgifter som skulle stulas från banksystemet.

Huvudsyftet med denna attack är att hacka systemets databas, därför kan attackens konsekvenser verkligen vara skadliga.

Följande saker kan komma från SQL Injection

• Hackar andras konto.
• Stjäla och kopiera webbplatsens eller systemets känsliga data.
• Ändra systemets känsliga data.
• Ta bort systemets känsliga data.
• Användaren kan logga in på applikationen som en annan användare, även som administratör.
• Användaren kan se privat information som tillhör andra användare, t.ex. information om andra användares profiler, transaktionsdetaljer etc.
• Användaren kan ändra programkonfigurationsinformation och data för de andra användarna.
• Användaren kan ändra strukturen i databasen; ta bort till och med tabeller i applikationsdatabasen.
• Användaren kan ta kontroll över databasservern och utföra kommandon på den efter behag.

Ovanstående risker kan verkligen betraktas som allvarliga, eftersom återställning av en databas eller dess data kan kosta mycket. Det kan kosta ditt företag rykte och pengar att återställa förlorade data och system. Det rekommenderas därför att skydda ditt system mot denna typ av attacker och betrakta säkerhetstestning som en bra investering i din produkts och företagets rykte.

Som testare vill jag kommentera att det är bra att testa mot möjliga attacker även om Säkerhetstestning var inte planerad. På så sätt kan du skydda och testa produkten mot oväntade fall och skadliga användare.

Essensen av denna attack

Som nämnts tidigare är kärnan i denna attack att hacka databasen med skadligt syfte.

För att utföra denna säkerhetstestning måste du först hitta de utsatta systemdelarna och sedan skicka skadlig SQL-kod genom dem till databasen. Om denna attack är möjlig för ett system skickas lämplig skadlig SQL-kod och skadliga åtgärder kan utföras i databasen.

Varje fält på en webbplats är som en port till databasen. All data eller inmatning som vi vanligtvis matar in i vilket fält som helst på systemet eller webbplatsen går till databasfrågan. Därför, i stället för korrekta data, om vi skulle skriva någon skadlig kod, kan den köras i databasfrågan och få skadliga konsekvenser.

Rekommenderat verktyg

# 1) Kiuwan

Hitta och fixa enkelt sårbarheter som SQL-injektion i din kod i alla steg i SDLC. Kiuwan uppfyller de strängaste säkerhetsstandarderna inklusive OWASP, CWE, SANS 25, HIPPA och mer.

Integrera Kiuwan i din IDE för omedelbar feedback under utvecklingen. Kiuwan stöder alla större programmeringsspråk och integreras med ledande DevOps-verktyg.

=> Skanna din kod gratis

För att utföra denna attack måste vi ändra handling och syfte med en lämplig databasfråga. En av de möjliga metoderna för att utföra den är att göra frågan alltid sant och sedan infoga din skadliga kod. Att ändra databasfrågan till alltid true kan utföras med enkel kod som ‘eller 1 = 1; -.

Testare bör komma ihåg att samtidigt som man kontrollerar om man kan utföra frågan till alltid sant kan man göra olika citat - enkla och dubbla. Därför, om vi har provat kod som “eller 1 = 1; -, bör vi också prova koden med dubbla citat” eller 1 = 1; -.

Till exempel, låt oss överväga att vi har en fråga som söker efter det angivna ordet i databastabellen:

välj * från anteckningar nt där nt.subject = ‘search_word’;

Därför, i stället för sökordet, om vi anger en SQL Injection-fråga 'eller 1 = 1; -, blir frågan alltid sant.

välj * från anteckningar nt där nt.subject = ‘‘ eller 1 = 1; -

I det här fallet stängs parametern ”subject” med offerten och då har vi kod eller 1 = 1, vilket gör en fråga alltid sant. Med tecknet “-” kommenterar vi resten av frågekoden, som inte kommer att köras. Det är ett av de mest populära och enklaste sätten att börja kontrollera frågan.

Få andra koder kan också användas för att göra frågan alltid sant, som:

• 'Eller' abc '=' abc '; -
• 'Eller' '=' '; -

Den viktigaste delen här är att vi efter kommatecken kan ange vilken skadlig kod som helst som vi vill köras.

Till exempel, det kan vara ‘eller 1 = 1; släpp tabellanteckningar; -

Om denna injektion är möjlig kan eventuell annan skadlig kod skrivas. I det här fallet beror det bara på den skadliga användarens kunskap och avsikt. Hur kontrollerar jag SQL-injektion?

Kontroll av denna sårbarhet kan utföras mycket enkelt. Ibland räcker det att skriva 'eller' logga in i de testade fälten. Om det returnerar något oväntat eller extraordinärt meddelande kan vi vara säkra på att SQL Injection är möjligt för det fältet.

Till exempel , om du får ett felmeddelande som ”Internt serverfel” som ett sökresultat, kan vi vara säkra på att denna attack är möjlig i den delen av systemet.

Andra resultat som kan meddela eventuella attacker inkluderar:

• Tom sida laddad.
• Inga fel- eller framgångsmeddelanden - funktionalitet och sida reagerar inte på ingången.
• Framgångsmeddelande för skadlig kod.

Låt oss titta runt på hur detta fungerar i praktiken.

Till exempel, Låt oss testa om ett lämpligt inloggningsfönster är sårbart för SQL Injection. För detta ändamål, i e-postadressen eller lösenordsfältet, skriver vi bara sign som visas nedan.

Om sådan inmatning returnerar resultat som felmeddelande 'Internt serverfel' eller något annat listat olämpligt resultat, kan vi nästan vara säkra på att denna attack är möjlig för det fältet.

En mycket knepig SQL-injektionskod kan också prövas. Jag vill nämna att jag under min karriär inte har stött på något fall när det fanns meddelandet ”Internt serverfel” som ett resultat av tecknet, men ibland reagerade fälten inte för mer komplicerad SQL-kod.

Därför är det ganska pålitligt att kontrollera SQL Injection med ett enda citat för att kontrollera om denna attack är möjlig eller inte.

Om den enskilda offerten inte ger något olämpligt resultat kan vi försöka skriva in dubbla citat och kontrollera resultaten.

SQL-kod för att ändra frågan till alltid sant kan också betraktas som ett sätt att kontrollera om denna attack är möjlig eller inte. Den stänger parametern och ändrar frågan till ”true”. Därför, om den inte valideras, kan sådan inmatning också returnera alla oväntade resultat och informera detsamma om att denna attack är möjlig i detta fall.

Kontroll av eventuella SQL-attacker kan också utföras från webbplatsens länk. Antag att vi har en webbplats länk som http://www.testing.com/books=1 . I detta fall är 'böcker' en parameter och '1' är dess värde. Om vi ​​i den tillhandahållna länken skulle skriva 'tecken istället för 1, skulle vi kontrollera om det finns en injektion.

Länk därför http://www.testing.com/books= kommer att vara som ett test om SQL-attacken är möjlig för webbplatsen http://www.testing.com eller inte.

I det här fallet, om länk http://www.testing.com/books= returnerar ett felmeddelande som ”Internt serverfel” eller en tom sida eller något annat oväntat felmeddelande, då kan vi också vara säkra på att SQL Injection är möjlig för den webbplatsen. Senare kan vi försöka skicka mer knepig SQL-kod via webbplatsens länk.

För att kontrollera om denna attack är möjlig via webbplatsens länk eller inte kan kod som “eller 1 = 1; - också skickas.

Som en erfaren programvarutestare vill jag påminna om att inte bara det oväntade felmeddelandet kan betraktas som en SQL Injection-sårbarhet. Många testare letar efter eventuella attacker endast i enlighet med felmeddelanden.

Det bör dock komma ihåg att inget valideringsfelmeddelande eller framgångsmeddelande för skadlig kod också kan vara ett tecken på att denna attack är möjlig.

Säkerhetstestning av webbapplikationer mot SQL-injektion

Säkerhetstestning av webbapplikationer förklarade med enkla exempel:

Eftersom konsekvenserna av att tillåta denna sårbarhetsteknik kan vara allvarliga följer det att denna attack bör testas under säkerhetstestningen av en applikation. Nu med en översikt över denna teknik, låt oss förstå några praktiska exempel på SQL-injektion.

Viktigt: Detta SQL-injektionstest bör endast testas i testmiljön.

Om applikationen har en inloggningssida är det möjligt att applikationen använder dynamisk SQL, såsom uttalandet nedan. Detta uttalande förväntas returnera åtminstone en rad med användardetaljerna från tabellen Användare som resultatuppsättning när det finns en rad med användarnamn och lösenord som anges i SQL-uttalandet.

VÄLJ * FRÅN användare VAR Användarnamn = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & '’; '

Om testaren skulle ange John som strUserName (i textrutan för användarnamn) och Smith som strPassword (i textrutan för lösenord) skulle ovanstående SQL-uttalande bli:

Om testaren skulle ange John’– som strUserName och inget strPassword, skulle SQL-uttalandet bli:

Observera att delen av SQL-uttalandet efter John förvandlas till en kommentar. Om det fanns någon användare med användarnamnet John i tabellen Användare kan applikationen tillåta testaren att logga in som användaren John. Testaren kunde nu se den privata informationen för användaren John.

Vad händer om testaren inte vet namnet på någon befintlig användare av applikationen? I ett sådant fall kan testaren testa vanliga användarnamn som admin, administratör och sysadmin. Om ingen av dessa användare finns i databasen kan testaren ange John 'eller' x '=' x som strUserName och Smith 'eller' x '=' x som strPassword. Detta skulle få SQL-satsen att bli som den nedan.

Eftersom 'x' = 'x' villkor alltid är sant, skulle resultatuppsättningen bestå av alla rader i tabellen Användare. Applikationen kan tillåta testaren att logga in som den första användaren i tabellen Användare.

Viktigt: Testaren bör be databasadministratören eller utvecklaren att kopiera den aktuella tabellen innan du försöker följande attacker.

Om testaren skulle komma in i John '; DROP-tabell users_details; ’- som strUserName och allt som strPassword, skulle SQL-uttalandet bli som det nedan.

Detta uttalande kan leda till att tabellen 'användare_detaljer' raderas permanent från databasen.

Även om ovanstående exempel handlar om att använda SQL-injektionstekniken endast inloggningssidan, bör testaren testa denna teknik på alla sidor i applikationen som accepterar användarinmatning i textformat, t.ex. söksidor, feedback-sidor etc.

SQL-injektion kan vara möjligt i applikationer som använder SSL. Även en brandvägg kanske inte kan skydda applikationen mot denna teknik.

Jag har försökt förklara denna attackteknik i en enkel form. Jag vill upprepa att denna attack endast ska testas i en testmiljö och inte i utvecklingsmiljön, produktionsmiljön eller någon annan miljö.

Android-app för att spionera på en annan telefon

Istället för att manuellt testa om applikationen är sårbar för SQL-attack eller inte kan man använda en Webbsårbarhetsskanner som söker efter denna sårbarhet.

Relaterad läsning: Säkerhetstestning av webbapplikationen . Kontrollera detta för mer information om olika webbsårbarheter.

Sårbara delar av denna attack

Innan testprocessen påbörjas, bör varje uppriktig testare mer eller mindre veta vilka delar som är mest utsatta för eventuella attacker.

Det är också en bra praxis att planera vilket fält i systemet som ska testas exakt och i vilken ordning. Under min testkarriär har jag lärt mig att det inte är en bra idé att testa fält mot SQL-attacker slumpmässigt eftersom vissa fält kan missas.

Eftersom denna attack utförs i databasen är alla datainmatningssystemets delar, inmatningsfält och webbplatslänkar sårbara.

Sårbara delar inkluderar:

• Inloggningsfält
• Sök i fält
• Kommentarfält
• Alla andra datainmatning och sparar fält
• Webbplatsens länkar

Det är viktigt att lägga märke till att det inte räcker att kontrollera bara ett eller några fält under testning mot denna attack. Det är ganska vanligt att ett fält kan skyddas mot SQL Injection, men sedan inte ett annat. Därför är det viktigt att inte glömma att testa alla webbplatsens fält.

Automatisera SQL-injektionstester

Eftersom vissa testade system eller webbplatser kan vara ganska komplicerade och innehålla känslig data kan det vara väldigt svårt att testa manuellt och det tar också mycket tid. Därför kan testning mot denna attack med specialverktyg ibland vara till stor hjälp.

Ett sådant SQL Injection-verktyg är SOAP UI . Om vi ​​har automatiserade regressionstester på API-nivå kan vi också byta kontroll mot denna attack med det här verktyget. I SOAP UI-verktyget finns det redan förberedda kodmallar för att kontrollera mot denna attack. Dessa mallar kan också kompletteras med din egen skrivna kod.

Det är ett ganska pålitligt verktyg.

Ett test bör dock redan automatiseras på API-nivå, vilket inte är så enkelt. Ett annat möjligt sätt att testa automatiskt är att använda olika webbläsarinsticksprogram.

Det bör nämnas att även om automatiserade verktyg sparar tid, anses de inte alltid vara mycket tillförlitliga. Om vi ​​testar ett banksystem eller någon webbplats med mycket känslig data rekommenderas det starkt att testa det manuellt. Där du kan se de exakta resultaten och analysera dem. I det här fallet kan vi också vara säkra på att ingenting hoppades över.

Jämförelse med andra attacker

SQL Injection kan betraktas som en av de allvarligaste attackerna, eftersom den påverkar databasen och kan skada din data och hela systemet allvarligt.

Visst kan det få allvarligare konsekvenser än en Javascript Injection eller HTML Injection, eftersom båda utförs på klientsidan. Som jämförelse, med denna attack kan du få tillgång till hela databasen.

Det bör nämnas att för att testa mot denna attack, bör du ha ganska goda kunskaper i SQL-programmeringsspråk och i allmänhet bör du veta hur databasfrågor fungerar. Även när du utför denna injektionsattack bör du vara mer försiktig och uppmärksam, eftersom alla felaktigheter kan lämnas som SQL-sårbarheter.

Slutsats

Jag hoppas att du skulle ha fått en klar uppfattning om vad en SQL-injektion är och hur ska vi förhindra dessa attacker.

Det rekommenderas dock att testa mot denna typ av attack varje gång ett system eller en webbplats med en databas testas. Varje vänster databas eller systemsårbarhet kan kosta företagets rykte och mycket resurser för att återställa hela systemet.

Eftersom testning mot denna injektion hjälper till att hitta det mesta viktiga säkerhetsproblem , det rekommenderas också att investera i dina kunskaps- och testverktyg.

Om säkerhetstestning planeras bör testning mot SQL Injection planeras som en av de första testdelarna.

Har du stött på någon typisk SQL-injektion? Dela gärna dina erfarenheter i kommentarfältet nedan.

Rekommenderad läsning

• HTML-injektionshandledning: Typer och förebyggande med exempel
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Fördjupade förmörkningsövningar för nybörjare
• Handledning för destruktiv testning och icke-destruktiv testning
• Testing Primer eBook Download
• Funktionell testning mot icke-funktionell testning
• SOA Testing Tutorial: Testing Methodology For a SOA Architecture Model
• Parvis testning eller testning i alla par med hjälp av verktyg och exempel