sv.onlinewebcreations.com

Om man tittar tillbaka på de mest slående datahackarna de senaste åren gäller en stor del av detta de så kallade SQL-injektionsattackerna. Nästan alla stora datahackar var resultatet av SQL-injektionsattacker. Men vad är en SQL-injektionsattack och hur kan du förhindra det?

De flesta webbplatsägare lider av kontinuerliga försök på internetbots att hacka sin webbplats. För detta behöver du bara titta i dina Apache- eller PHP-loggfiler och då kommer du att se många förfrågningar om webbadresser som inte finns på din webbplats. URL-adresser som ofta används av plattformar som WordPress, Magento eller andra open source-plattformar. Tänk på login.php, wp-login.php etcetera. Dessa är ofta så kallade brute force attacks. Man försöker hitta en inloggningssida och bombardera den med hundratals eller tusentals gemensamma inloggningskombinationer.

Definition av en SQL-injektionsattack

En SQL-injektionsattack är faktiskt utförandet av skadliga SQL-frågor från utsidan i databaser på vilka webbplatser som fungerar. En SQL-injektionsattack kan verkligen göras från utsidan, ingen direkt server eller databasåtkomst krävs. En SQL-injektionsattack kan användas för att få direkt åtkomst till servern eller databasen.

Viktigt att veta är att en SQL-injektionsattack kan förhindras 100 procent av rätt programkod. Men om jag säger att även de stora öppna källkodssystemen som WordPress, Magento, Joomla och kalla dem alla har hål som kan ha orsakat SQL-injektionsattacker, kan du bara misstänka att de många anpassade webbplatser som Twinkle200-medlemmar fortfarande använder är redan helt sårbara.

Vad är en skadlig URL för en SQL-injektionsattack?

Alla webbplatser där en databas körs är potentiellt mottagliga för en SQL-injektionsattack. Detta gäller därför alla e-handelswebbplatser, bloggwebbplatser och liknande. Potentiellt skadliga är de webbadresser där någon parameter har passerat, vilket leder till visning av dynamiskt innehåll från databasen på den webbsidan.
Låt oss ge ett konkret exempel på en URL på bol.com:

https://www.bol.com/nl/l/parfums/N/12428/

Detta är en kategorisida på bol.com i kategorin parfym. Tydligen har denna parfymkategori i databasen kategorin ID 12428. Innehållet på denna specifika webbsida genereras baserat på detta ID 12428. Baserat på detta ID körs en fråga i bakgrunden på bol.com-databasen där kategorin Information hämtas och visas i webbläsaren.

Nu har jag ingen aning om bol.com har säkrats mot SQL-injektionsattacker. Så exemplet som ges nu är rent hypotetiskt och jag har inte försökt den här webbadressen själv.
Antag att bol.com-programmerarna har följande konstruktion i sin programmeringskod:

idcode = request.POST ['id']
sql = "VÄLJ * FRÅN kategorier WHERE id = '" + idcode + "'"
database.execute (sql)

Koden som visas ovan är känslig för en SQL-injektionsattack.

Antag att användaren i webbläsaren skulle ändra ovanstående bol.com URL till:

https://www.bol.com/en/l/parfums/N/12428 'ELLER 1 = 1 /

SQL-frågan i programmeringskoden skulle således bli:

VÄLJ * FRÅN KATEGORIER VAR ID = '12428' ELLER 1 = 1 '

Som ett resultat visas all kategoriinformation. Det här är ett mycket enkelt exempel, men en angripare kan lägga ett annat SQL-uttalande på samma sätt som en utskrift av alla tabellnamn i databasen. Baserat på detta kunde han använda samma webbadress för att göra en utskrift av alla användare och deras lösenord (genom att välja rätt tabellnamn).

Vad är det värsta som en angripare kan göra med en SQL-injektionsattack?

En SQL-injektionsattack ger således mer eller mindre direkt obehörig åtkomst till databasen. Vad kan en angripare göra? Hämta, ändra eller ta bort all data som finns i databasen.

Vilka är de enkla förutsättningarna för en SQL-injektionsattack?

Det finns faktiskt bara två väldigt enkla förhållanden:
• Databasen måste vara SQL-baserad (men alla stora databaser som MySQL, Oracle, SQL Server är baserade på SQL)
• En användarstyrd inmatning i en webbadress som direkt leder till en databasfråga

Hur kan du förhindra en SQL-injektionsattack?

Egentligen mycket enkelt. Genom att kontrollera inmatningen. Har du webbadresser på din webbplats (till exempel bol.com) där exempelvis ett ID-nummer för en kategori eller produkt leder till utmatningen på webbsidan? Se alltid till att du inte bara tar med det antagna "ID-numret" från webbadressen i frågan, men kontrollera om det är ett nummer alls och huruvida numret uppfyller villkoren du ställt in för det. Med webbadresser med text i dem som leder till en SQL-fråga blir det något svårare. Kontrollera om det är en sträng, men också om inmatningssträngen uppfyller vad du förväntar dig.

Standard-system och deras skydd mot SQL-injektionsattacker

Magento har lanserat många säkerhetsuppdateringar förra året som bör förhindra en stor del (eller till och med alla) SQL-injektionsattacker. WordPress är allmänt känd som en plattform som fortfarande är mycket tillgänglig för hackattacker. Så se till att din standardplattform är väl skyddad mot SQL-injektionsattacker. Visst om du använder anpassat arbete måste du vara uppmärksam på webbadresser där dessa typer av parametrar ingår. Se så till att ingångsparametern är korrekt kontrollerad för överensstämmelse med "förväntad" ingång innan den används i en SQL-fråga.

Top