Hvor Lite Bobby Tabeller Ødelagt Internett

Morsomme Fakta:

SQL-injeksjon har eksistert ganske mye siden den gang nettsteder har data som er lagret i databaser.

Open Web Application Security Project rangert injection-angrep som en av de topp 10 trusler mot web-applikasjoner i 2017.,

SQL-injeksjon er fortsatt ansvarlig for mange store data lekker. I 2016, Illinois og Arizona State Board of Valget velgerregistrering databaser ble brutt. Mens ingen informasjon ble stjålet i Arizona, i Illinois angriperne hadde tilgang til deltaking data som navn, adresse, fødselsdato, kjønn og delvis personnummer, for om lag 80 000 personer.⁴

Det er Skremmende, Hva Er Det?

SQL-injeksjon er en type angrep som er rettet mot et program ‘ s database gjennom innsetting av utilsiktede koden inn i brukerens input-feltene., Ved å dra nytte av SQL syntax angriper kan bruke felter for å fange opp informasjon fra disse databasene, inkludert ting som passord og kredittkortnumre. Noen kunne til og med ta kontroll over din database eller slette all informasjon som det holder.

Hvordan Fungerer Det?

SQL-Injeksjon fungerer ved hjelp av informasjon som er lagt inn et felt for å manipulere de tilsvarende SQL-setningen til å utføre en uønsket handling.,

Her er et enkelt eksempel:

SELECT * FROM customers WHERE name = " + user_name + ";

I dette eksempelet la oss si at variabelen brukernavn er opprettet direkte fra brukerens input på en nettside. Denne strengen er satt inn ovenfor SQL-setning og alle feltene knyttet til at brukernavn er returnert. Ingen big deal.

Men hva skjer hvis noen typer Steve» ELLER 1=1; — som brukernavn? deretter SQL generert ville være denne:

SELECT * FROM customers WHERE name = "Steve" OR 1=1;--";

Siden 1=1 er alltid sant, dette ville returnere alle data i tabellen. Ikke Bra!,

Let’s take one more look at that comic.

The son’s name is Robert’); DROP TABLE students; — What would that do exactly?,

Vel, vi kan anta at hvis det er Lite Bobby Bord ble lagt til skolens database av studenter, SQL-setningen vil se omtrent slik ut:

INSERT INTO students (name) VALUES ('<Student Name>');

… og når vi setter inn Bobby…

INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');

Siden Bobby ‘ s navn som inneholder det ); VERDIENE argumentet er stengt i midten av hans navn og tekst som følger DROP TABLE studenter er en ny SQL-setning som sletter hele tabellen. Til slutt — på slutten kommentarer ut de resterende SQL, i hovedsak ignorerer resten av den opprinnelige koden og gjør at ingen feil oppstår.,

Så, Hva Du Sier Er Mine Data Vil Aldri Bli Trygg Igjen?

Nope! Det er faktisk mange skritt du kan ta for å beskytte deg fra denne typen angrep. La oss se på noen av dem:

1. Rense Data. Det første trinnet er å kontrollere hva brukeren har lov til å inngang. Den beste måten å gjøre dette på, er å begrense typer input tillatt for et bestemt felt., For eksempel i et telefonnummer-feltet kan du bare la numeriske inngang, eller i en e-post feltet tillater bare tegn som kan bli funnet i en gyldig e-postadresse. Selvsagt, noen felt vil kreve tegn som kan brukes i et angrep, så denne metoden er ikke enestående.
2. Konfigurer feilrapportering. Ofte standard error reporting på Database Management Systems har utvikleren informasjon om feilsøking i det. Dette kan returnere nyttig informasjon til angriperen, som bord navn eller kolonne navn., Sørg for at du ikke viser denne typen informasjon til eksterne brukere som det kan utgjøre en potensiell angriper livet enklere måte.
3. Bruk Bundet Parametere. Bundet parametere lar deg lagre brukerdata i en variabel, og deretter sette det inn i en SQL-setning som har blitt opprettet med plassholdere. Siden SQL-setningen, og variabelen er sendt til serveren separat, bundet parametere er flinke til å beskytte mot injeksjon. Ta det Lille Bobby T!, Et eksempel på bundet parametre i en oppdatering metode i Ruby ville se ut som dette:

def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end

Det er sprøtt å tenke på at noe så enkelt og godt forstått, er fremdeles ansvarlig for så mange store data brudd., Selv i høy profil tilfeller som velgerregistreringen hacks som er nevnt ovenfor og de siste Equifax brudd (som ikke var på grunn av SQL-injeksjon, men til en lignende sårbarhet som selskapet ikke klarte å løse), roten av sårbarhet kommer ned til menneskelige feil og mangel på oppmerksomhet til detaljer. Tar deg tid til å tenke nøye gjennom problemet kan betydelig hjelpe oss med å beskytte brukerens data fra vanlige brudd, spesielt SQL-injeksjoner.