eller hur man skyddar användardata från SQL-injektion

xkcd

roliga fakta:

SQL Injection har funnits ganska mycket sedan webbplatser har lagrat data i databaser.

Open Web Application Security Project bedömde injektionsattacker som ett av de 10 bästa hoten mot webbapplikationer 2017.,

SQL injection är fortfarande ansvarig för många stora dataläckor. I 2016 överträddes Illinois och Arizona State Board of Elections voter registration databases. Medan ingen information stals i Arizona, i Illinois angripare hade tillgång till väljare data inklusive namn, adress, födelsedatum, kön och partiella personnummer, för cirka 80,000 personer.

det är skrämmande, vad är det?

SQL injection är en typ av attack som riktar sig till en ansökan databas genom införandet av oavsiktlig kod i användarinmatningsfält., Genom att dra nytta av SQL syntax angriparen kan använda inmatningsfält för att fånga information från dessa databaser – inklusive saker som lösenord och kreditkortsnummer. Någon kan även ta kontroll över din databas eller ta bort all information den innehar.

Hur fungerar det?

SQL Injection fungerar genom att använda information som infogas i ett fält för att manipulera motsvarande SQL-sats till att utföra en oavsiktlig åtgärd.,

här är ett grundläggande exempel:

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

låt oss säga att variabeln user_name skapas direkt från användarens inmatning på en webbplats. Den strängen infogas i ovanstående SQL-sats och alla fält som rör det användarnamnet returneras. Ingen fara.

men vad händer om någon skriver Steve ” eller 1 = 1; — som deras användarnamn? då SQL genereras skulle vara detta:

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

eftersom 1=1 är alltid sant, detta skulle returnera alla data i tabellen. Inte Bra!,

Let’s take one more look at that comic.

xkcd

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

Tja, vi kan anta att om lite Bobby tabeller lades till skolans databas av studenter, SQL-satsen skulle se ut ungefär som: 

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

… och när vi sätter Bobby…

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

eftersom Bobbys namn innehåller ); värdena argumentet är stängt i mitten av hans namn och texten som följer DROP TABLE studenter är en ny SQL-sats som tar bort hela bordet. Slutligen-i slutet kommenterar den återstående SQL, väsentligen ignorerar resten av den ursprungliga koden och se till att inget fel uppstår.,

så, vad du säger är mina Data kommer aldrig att bli säkert igen?

Nej! Det finns faktiskt en hel del åtgärder som du kan vidta för att skydda dig från denna typ av attack. Låt oss titta på några:

  1. sanera Data. Det första steget är att styra vad användaren får mata in. Det bästa sättet att göra detta är att begränsa de typer av inmatning som tillåts för ett visst fält., Till exempel i ett telefonnummer fält kan du bara tillåta numerisk inmatning, eller i ett e-postfält endast tillåta tecken som kan hittas i en giltig e-postadress. Självklart kommer vissa fält att kräva tecken som kan användas i en attack, så den här metoden är inte oslagbar.
  2. konfigurera felrapportering. Ofta har standardfelrapporteringen på databashanteringssystem utvecklarfelsökningsinformation i den. Detta kan returnera användbar information till angriparen, som tabellnamn eller kolumnnamn., Se till att du inte visar denna typ av information till utomstående användare eftersom det kan göra en potentiell angripare liv sätt lättare.
  3. använd bundna parametrar. Bundna parametrar kan du lagra användardata i en variabel och sedan infoga den i en SQL-sats som har skapats med platshållare. Eftersom SQL-satsen och variabeln skickas till servern separat är bundna parametrar bra för att skydda mot injektion. Ta den lilla Bobby T!, Ett exempel på bundna parametrar i en uppdateringsmetod i Ruby skulle se ut så här:
def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end

det är galet att tro att något så enkelt och väl förstått fortfarande är ansvarigt för så många stora databrott., Även i högprofilerade fall som voterregistreringshackarna som nämns ovan och den senaste Equifax-överträdelsen (som inte berodde på SQL-injektion, men till en liknande sårbarhet som företaget misslyckades med att adressera), kommer roten till sårbarheten ner till mänskligt fel och brist på uppmärksamhet på detaljer. Att ta sig tid att noggrant tänka igenom problemet kan avsevärt hjälpa oss att skydda användardata från vanliga överträdelser, särskilt SQL-injektioner.