SQL Injection Tutorial: Lær med eksempel

⚡ Smart opsummering

SQL-injektion er et angreb, der forgifter dynamiske SQL-sætninger for at omgå godkendelse eller eksponere data, og udnytter webapplikationer, der bygger forespørgsler ud fra usanitificeret brugerinput. Denne side viser, hvordan angrebet fungerer, og hvordan man forhindrer det.

  • ???? Definition: SQL-injektion indsætter skadelig SQL i en forespørgsel via et uvalideret inputfelt.
  • 🔓 Indvirkning: Et vellykket angreb kan omgå logins og læse, ændre eller slette poster.
  • 🧪 Eksempel: En altid-sand-betingelse plus en kommentar forvandler en login-kontrol til en omgåelse.
  • 🛠️ Værktøjer: SQLMap og jSQL automatiserer detektion og udnyttelse af injicerbare parametre.
  • 🛡️ Forebyggelse: Parameteriserede forespørgsler, inputvalidering og konti med mindste rettigheder lukker hullet.
  • 🤖 Moderne kant: AI-drevne scannere og firewalls markerer injektionsmønstre, som faste signaturer overser.

SQL-injektionsvejledning

Hvad er en SQL-injektion?

SQL Injection er et angreb, der forgifter dynamiske SQL-sætninger for at kommentere bestemte dele af sætningen eller tilføje en betingelse, der altid vil være sand. Det udnytter designfejl i dårligt designede webapplikationer til at udnytte SQL-sætninger til at udføre ondsindet SQL-kode.

Data er en af ​​de vigtigste komponenter i informationssystemer. Databasedrevne webapplikationer bruges af organisationer til at hente data fra kunder. SQL er akronymet for Struktureret forespørgselssprogDet bruges til at hente og manipulere data i databasen.

Diagram over, hvordan en SQL-injektion manipulerer en dynamisk databaseforespørgsel

Hvordan fungerer et SQL-injektionsangreb?

De typer angreb, der kan udføres ved hjælp af SQL-injektion, varierer afhængigt af typen af ​​databasemotor. Angrebet fungerer på dynamiske SQL-sætninger. En dynamisk sætning er en sætning, der genereres under kørsel ved hjælp af parametre, der sendes fra en webformular eller URI-forespørgselsstreng.

SQL-injektionseksempel

Lad os betragte en simpel webapplikation med en loginformular. Koden til HTML-formularen er vist nedenfor.

<form action=‘index.php’ method="post">

<input type="email" name="email" required="required"/>

<input type="password" name="password"/>

<input type="checkbox" name="remember_me" value="Remember me"/>

<input type="submit" value="Submit"/>

</form>

HER,

  • Ovenstående formular accepterer e-mailadressen og adgangskoden og sender dem derefter til en PHP fil med navnet index.php.
  • Den har en mulighed for at gemme login-sessionen i en cookie. Vi har udledt dette fra afkrydsningsfeltet remember_me. Den bruger post-metoden til at indsende data. Det betyder, at værdierne ikke vises i URL.

Lad os antage, at sætningen i backend til kontrol af bruger-ID'et er som følger.

SELECT * FROM users WHERE email = $_POST['email'] AND password = md5($_POST['password']);

HER,

  • Ovenstående sætning bruger værdierne fra $_POST[]-arrayet direkte uden at rense dem.
  • Adgangskoden hashes ved hjælp af MD5-algoritmen.

Vi vil illustrere et SQL-injektionsangreb ved hjælp af SQL Fiddle. Åbn URL http://sqlfiddle.com/ i din webbrowser. Du får følgende vindue.

Bemærk: Du skal skrive SQL-sætningerne.

Tom SQL Fiddle Vinduet er klar til skemaet og forespørgslen

Trin 1) Indtast denne kode i venstre rude.

CREATE TABLE `users` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `email` VARCHAR(45) NULL,
  `password` VARCHAR(45) NULL,
  PRIMARY KEY (`id`));
  
  
insert into users (email,password) values ('m@m.com',md5('abc'));

Trin 2) Klik på Opbyg skema.

Trin 3) Indtast denne kode i højre rude.

select * from users;

Trin 4) Klik på Kør SQL. Du vil se følgende resultat.

SQL Fiddle resultat, der viser den returnerede enkeltbrugerpost

Antag, at en bruger angiver admin@admin.sys og 1234 som adgangskode. Sætningen, der udføres mod databasen, ville være:

SELECT * FROM users WHERE email = 'admin@admin.sys' AND password = md5('1234');

Ovenstående kode kan udnyttes ved at kommentere adgangskodedelen ud og tilføje en betingelse, der altid vil være sand. Lad os antage, at en angriber indtaster følgende i e-mailadressefeltet.

xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ' ]

xxx for adgangskoden.

Den genererede dynamiske erklæring vil være som følger.

SELECT * FROM users WHERE email = 'xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ' ] AND password = md5('1234');

HER,

  • xxx@xxx.xxx slutter med et enkelt anførselstegn, der fuldender strengen citationstegn.
  • OR 1 = 1 LIMIT 1 er en betingelse, der altid vil være sand og begrænser de returnerede resultater til kun én post.
  • — ' AND ... er en SQL-kommentar, der eliminerer adgangskodedelen.

Kopier ovenstående SQL-sætning og indsæt den i SQL Fiddle Kør SQL-tekstfeltet som vist nedenfor.

SQL Fiddle returnerer posten efter den indsprøjtede betingelse kører

Hackingaktivitet: SQL Inject a Web Application

Vi har en simpel webapplikation på http://www.techpanda.org/ der er sårbar over for SQL-injektionsangreb, kun til demonstrationsformål. Ovenstående HTML-formularkode er taget fra loginsiden. Applikationen yder grundlæggende sikkerhed, såsom rensning af e-mailfeltet. Det betyder, at ovenstående kode ikke kan bruges til at omgå login.

For at omgå det, bruger vi i stedet adgangskodefeltet. Diagrammet nedenfor viser de trin, der skal følges.

Flowdiagram over trinene til at indsætte adgangskodefeltet i loginformularen

Lad os antage, at en angriber giver følgende input.

  • Trin 1: Indtast xxx@xxx.xxx som e-mailadresse
  • Trin 2: Indtast xxx') ELLER 1 = 1 — ]

Loginformular med indsprøjtningsstrengen indtastet i adgangskodefeltet

  • Klik på knappen Send.
  • Du vil blive dirigeret til dashboardet.

Den genererede SQL-sætning vil se ud som følger.

SELECT * FROM users WHERE email = 'xxx@xxx.xxx' AND password = md5('xxx') OR 1 = 1 -- ]');

Diagrammet nedenfor illustrerer, hvordan udsagnet genereres.

Oversigt over, hvordan den indsprøjtede SQL-sætning genereres

HER,

  • Udsagnet antager intelligent, at der anvendes md5-kryptering.
  • Fuldfører det enkelte citationstegn og den afsluttende parentes.
  • Tilføjer en betingelse til udsagnet, der altid vil være sand.

Generelt kombinerer et vellykket angreb flere teknikker som dem, der er vist ovenfor.

Andre SQL-injektionsangrebstyper

SQL-injektioner kan gøre mere skade end blot at omgå login-algoritmerne. Nogle af angrebene inkluderer:

  • Sletning af data
  • Opdaterer data
  • Indsættelse af data
  • Udførelse af kommandoer på serveren, der kan downloade og installere ondsindede programmer såsom trojanske heste
  • Eksport af værdifulde data såsom kreditkortoplysninger, e-mail og adgangskoder til angriberens fjernserver
  • Hentning af brugerloginoplysninger osv.
  • SQL-injektion baseret på cookies
  • Fejlbaseret SQL-injektion
  • Blind SQL-injektion

Ovenstående liste er ikke udtømmende; den giver dig blot en idé om, hvad SQL Injection kan gøre.

Automatiseringsværktøjer til SQL-injektion

I ovenstående eksempel brugte vi manuelle angrebsteknikker baseret på vores omfattende viden om SQL. Der findes automatiserede værktøjer, der kan hjælpe dig med at udføre angrebene mere effektivt og på kortest mulig tid. Disse værktøjer omfatter:

Sådan forhindrer du SQL-injektionsangreb

En organisation kan vedtage følgende politik for at beskytte sig selv mod SQL Injection-angreb.

  • Brugerinput bør aldrig stoles på – Den skal altid renses, før den bruges i dynamiske SQL-sætninger.
  • Gemte procedurer – disse kan indkapsle SQL-sætningerne og behandle alt input som parametre.
  • Forberedte udsagn – forberedte sætninger fungerer ved først at oprette SQL-sætningen og derefter behandle alle indsendte brugerdata som parametre. Dette har ingen effekt på syntaksen i SQL-sætningen.
  • Regelmæssige udtryk – disse kan bruges til at detektere potentielt skadelig kode og fjerne den, før SQL-sætningerne udføres.
  • Adgangsrettigheder for brugere til databaseforbindelse – kun nødvendige adgangsrettigheder bør gives til konti, der bruges til oprette forbindelse til databasen. Dette kan hjælpe med at reducere, hvad SQL-sætningerne kan udføre på serveren.
  • Fejlmeddelelser – disse bør ikke afsløre følsomme oplysninger eller præcis hvor en fejl opstod. Enkle brugerdefinerede fejlmeddelelser som "Beklager, vi oplever tekniske fejl. Det tekniske team er blevet kontaktet. Prøv igen senere" kan bruges i stedet for at vise de SQL-sætninger, der forårsagede fejlen.

Hackingaktivitet: Brug Havij til SQL Injection

I dette praktiske scenarie bruger vi Havij Advanced SQL Injection-programmet til at scanne et websted for sårbarheder.

Bemærk: Havij er en gammeldags, uvedligeholdt bygning Windows værktøj — SQLMap ovenfor er den nuværende open source-standard.

Bemærk: Dit antivirusprogram markerer det muligvis på grund af dets natur. Du bør tilføje det til undtagelseslisten eller sætte din antivirusprogram.

Billedet nedenfor viser hovedvinduet for Havij.

Hovedvinduet i Havij SQL-injektionsværktøjet

Ovenstående værktøj kan bruges til at vurdere sårbarheden af ​​et websted eller en applikation.

Ofte Stillede Spørgsmål

Kun med webstedsejerens skriftlige tilladelse. Det er ulovligt at teste en applikation, du ikke ejer, i henhold til love som den amerikanske Computer Fraud and Abuse Act. Bug-bounty-scenarier definerer, hvad der er tilladt.

Ja. I OWASP Top 10:2025 rangerer injektion som nummer A05, og test finder stadig injektion i næsten alle applikationer. Med tusindvis af nye SQL-injektions-CVE'er om året er det fortsat en førende webrisiko.

MD5 er en hurtig hash, ikke kryptering, og angribere knækker den hurtigt med Rainbow-tabeller og GPU'er. Brug i stedet en langsom, saltet algoritme såsom bcrypt eller Argon2 til adgangskoder.

Enhver database, der forespørges via dynamisk bygget SQL — MySQL, PostgreSQL, Microsoft SQL Server, Oracleog SQLiteFejlen ligger i, hvordan applikationen sammenkæder brugerinput i forespørgsler, ikke i databaseprogrammet.

AI-drevne firewalls og scannere lærer normale trafikmønstre at kende og markerer derefter unormale input, såsom indsprøjtede betingelser eller kommentarer, i realtid. Maskinlæringsmodeller fanger obfuskerede nyttelast, som faste signaturer overser.

AI-assistenter som f.eks. GitHub Copilot kan foreslå parameteriserede forespørgsler og inputvalidering, men de reproducerer også usikre mønstre. Behandl hvert forslag som et udkast, og par det med en sikkerhedsforespørgsel og gennemgang.

SQL-injektion er rettet mod databasen ved at injicere SQL i server-side forespørgsler. Cross-site scripting er rettet mod andre brugere ved at injicere scripts, der kører i deres browsere. Den ene eksponerer data; den anden kaprer sessioner.

En ORM (objekt-relationel mapper) bygger forespørgsler fra kodeobjekter med parametrisering som standard, hvilket forhindrer det meste SQL-injektion. Den er ikke idiotsikker — rå forespørgsler og usikre metoder lækker stadig, så validering er stadig vigtig.

Opsummer dette indlæg med: