Hvad er Kodeinjektion, og hvordan du kan undgå det

kodeinjektionssårbarheder er et generelt udtryk, der beskriver sårbarheder, der kan udnyttes af en angriber til at injicere og udføre ondsindet kode.

denne sårbarhed opstår normalt på grund af manglen på ikke-tillid til datavalidering. Applikationer, der direkte evaluerer kode uden først at validere den, ville være sårbare over for denne type angreb.

Kodeinjektion forveksles undertiden med andre sårbarheder såsom og Kommandoinjektion. Det skal bemærkes, at Kodeinjektion er en anden type sårbarhed, hvorved en angriber injicerer kode i stedet for Operativsystemkommandoer. Det betyder, at med hensyn til kode injektion sårbarheder, angriberen er begrænset af Programmets sprog funktionalitet.

Angriberbegrænsninger

ved udnyttelse af sådanne sårbarheder er angribere begrænset af applikationens sprog (såsom PHP / Python) funktionalitet. I de fleste tilfælde kan angriberen dog muligvis udnytte tolkens funktionalitet til overgang fra Kodeinjektion til Kommandoinjektion.

for eksempel, hvis en angriber injicerer PHP-kode i en internetapplikation, vil angriberen være begrænset af den funktionalitet, der er tilgængelig af PHP-tolken. Når indsprøjtningsangrebet opstår, udfører PHP-tolken den injicerede kode og afhænger af tolkens funktionalitet, en angriber kan udnytte programudførelsesfunktioner, der er tilgængelige i PHP, såsom system() eller shell_eksec for at udføre systemkommandoer.

virkningen af en Kodeinjektion

virkningen, som et vellykket angreb ville have, kan variere afhængigt af flere faktorer, såsom det sprog, der bruges af applikationen, den funktionalitet, der er tilgængelig efter applikation osv.

men i de fleste tilfælde kan et vellykket angreb helt kompromittere fortroligheden, integriteten og tilgængeligheden af applikationen og dens data.

eksempel

Forestil dig en internetapplikation, der overfører data, der ikke er tillid til, såsom brugerens input til en PHP eval () – funktion. Funktionen eval () evaluerer simpelthen en streng som PHP-kode, så længe den har gyldig PHP-syntaks og slutter med et semikolon.

<?php

$ backup = “”;

$input = $_GET;

eval (“\$backup = \ $input;”);

?>

da applikationen overfører brugerens input til den farlige PHP eval () – funktion, og der ikke udføres nogen Validering, ville applikationen være sårbar over for Kodeinjektionsangreb.

en angriber kunne udnytte denne svaghed ved at levere input 1; phpinfo (); som vist nedenfor:

https://example.com/index.php?arg=1;https://example.com/index.php?arg=1; phpinfo();

Udfør os-systemkommandoer

efter at have verificeret sårbarheden, kunne en angriber fortsætte med at udføre systemkommandoer ved at udnytte tolkens funktioner, der tillader kommandoudførelse. I dette tilfælde anvendes funktionen system ().

https://example.com/index.php?arg=1;https://example.com/index.php?arg=1; system(‘hvem’);

kommandoen hvem udskriver brugernavnet på den aktuelle bruger, når den påberåbes. Dette betyder, at når applikationen

overfører brugerens input til eval () – funktionen, vil PHP-tolken udføre kommandoen hvem på

underliggende OS.

når angriberen kan udføre systemkommandoer, kan de fortsætte med at få en interaktiv skal på det sårbare

system og udføre andre angreb mod andre systemer inden for det kompromitterede systems interne netværk.

forebyggelse

uanset hvilket sprog der bruges, kan kodeinjektionssårbarheder undgås ved at følge de bedste fremgangsmåder

beskrevet nedenfor:

• undgå at evaluere data, der ikke er tillid til

◦ medmindre det er strengt nødvendigt, skal du ikke evaluere data, der ikke er tillid til, direkte ved hjælp af usikre funktioner såsom eval(). * Behandl alle data som ikke-tillid

bemærk, at ikke-tillid til data ikke kun henviser til de input, der leveres via HTML-formularer. Oplysninger, der kontrolleres af brugere, såsom cookies, http-anmodningsoverskrifter og uploadede filer, skal behandles som ikke-tillid.

• Valideringutillidte Data

◦ valider altid brugerinput på serversiden.

Karl hvis brugeren skal indsende input i et bestemt format som dato, Postnummer, numre, e-mail

adresse osv., skal du sørge for, at brugerens input matcher det forventede format.

Karl hvis applikationen forventer en værdi inden for et begrænset sæt indstillinger, skal du følge en hvidliste-tilgang og sikre, at

det indsendte input er en af de tilladte indstillinger.

• Harden tolken

◦ for eksempel bør PHP-tolkens funktionalitet begrænses til den minimale funktionalitet, der kræves for, at applikationen kan fungere. Dette kan gøre det meget vanskeligere for angribere at udføre systemkommandoer. For eksempel kan PHP-programudførelsesfunktionerne deaktiveres ved at ændre php.INI-fil.

• statisk analyse

◦ Udfør statiske analyseaktiviteter for at identificere sårbarheder relateret til usikker evaluering.

• VAPT

◦ udføre regelmæssige sårbarhedsvurderinger og Penetrationstestaktiviteter for at identificere og afbøde sådanne svagheder.