Hva Er Kodeinjeksjon Og Hvordan Du Kan Unngå Det

kodeinjeksjonssårbarheter er et generelt begrep som beskriver sårbarheter som kan utnyttes av en angriper til å injisere og utføre skadelig kode.

dette sikkerhetsproblemet oppstår vanligvis på grunn av mangel på uklarert datavalidering. Programmer som direkte evaluerer kode uten å validere det først, vil være sårbare for denne typen angrep.

Kodeinjeksjon er noen ganger forvekslet med andre sårbarheter som Og Command Injection. Det bør bemerkes At Kodeinjeksjon er en annen type sårbarhet, der en angriper injiserer kode i stedet for Operativsystemkommandoer. Dette betyr at med Hensyn Til Kodeinjeksjonssårbarheter, er angriperen begrenset av programmets språkfunksjonalitet.

Angriperbegrensninger

når du utnytter slike sårbarheter, er angriperne begrenset av programmets språk (FOR EKSEMPEL PHP / Python) funksjonalitet. I de fleste tilfeller kan imidlertid angriperen være i stand til å utnytte tolkens funksjonalitet til overgang fra Kodeinjeksjon til Kommandoinjeksjon.

for eksempel, hvis en angriper injiserer PHP-kode i et webprogram, vil angriperen være begrenset av FUNKSJONALITETEN SOM ER tilgjengelig AV PHP-tolken. NÅR injeksjonsangrepet oppstår, VIL PHP-tolken utføre den injiserte koden og avhenge av tolkens funksjonalitet, en angriper kan utnytte programutførelsesfunksjoner som er tilgjengelige i PHP som system () eller shell_exec for å utføre systemkommandoer.

Virkningen Av En Kodeinjeksjon

virkningen som et vellykket angrep ville ha, kan variere avhengig av flere faktorer som språket som brukes av programmet, funksjonaliteten som er tilgjengelig av programmet, etc.

i de fleste tilfeller kan imidlertid et vellykket angrep fullstendig kompromittere konfidensialiteten, integriteten og tilgjengeligheten til applikasjonen og dens data.

Eksempel

Tenk deg et webprogram som overfører uklarerte data, for eksempel brukerens inngang til EN PHP eval () – funksjon. Eval () – funksjonen evaluerer bare en streng SOM PHP-kode så lenge den har gyldig PHP-syntaks og slutter med et semikolon.

<?php

$sikkerhetskopiering = “”;

$input = $ _GET;

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

?>

Siden programmet passerer brukerens innspill til den farlige PHP eval () – funksjonen, og det er ingen validering blir utført, vil programmet være utsatt For Kode Injeksjon angrep.

en angriper kan utnytte denne svakheten ved å levere inngangen 1; phpinfo (); som vist nedenfor:

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

Utfør OS-systemkommandoer

etter å ha bekreftet sikkerhetsproblemet, kan en angriper fortsette med å utføre systemkommandoer ved å utnytte tolkens funksjoner som tillater kommandoutførelse. I dette tilfellet brukes system () – funksjonen.

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

kommandoen whoami skriver ut brukernavnet til gjeldende bruker når det startes. Dette betyr at NÅR programmet

passerer brukerens inngang til eval () – funksjonen, VIL PHP tolken utføre whoami-kommandoen på

underliggende OS.

når angriperen kan utføre systemkommandoer, kan de fortsette med å få et interaktivt skall på det sårbare

– systemet og utføre andre angrep mot andre systemer innenfor det kompromitterte systemets interne nettverk.

Forebygging

uansett hvilket språk Som brukes, Kan sårbarheter for Kodeinjeksjon unngås ved å følge anbefalte fremgangsmåter

beskrevet nedenfor:

• Unngå å evaluere uklarerte data

◦ med mindre det er strengt nødvendig, må du ikke evaluere uklarerte data direkte ved hjelp av usikre funksjoner som eval(). * Behandle alle data som uklarerte

◦ Merk at uklarerte data ikke bare refererer til inngangene som er gitt via HTML-skjemaer. Informasjon som kontrolleres av brukere som informasjonskapsler, HTTP-forespørselshoder og opplastede filer, skal behandles som uklarert.

• ValidateUntrusted Data

◦ valider alltid brukerinngang på serversiden.

◦ hvis brukeren skal sende inn innspill i et bestemt format som dato, postnummer, tall, e-post

adresse, etc, må du kontrollere at brukerens innspill samsvarer med forventet format.

◦ hvis søknaden forventer en verdi innenfor et begrenset utvalg av alternativer, følg en hviteliste-tilnærming og sørg for at

innsendte inndata er en av de tillatte alternativene.

• Herd tolken

◦ FOR EKSEMPEL BØR PHP tolk funksjonalitet være begrenset til minimum funksjonalitet som kreves for at programmet skal fungere. Dette kan gjøre det mye vanskeligere for angripere å utføre systemkommandoer. FOR eksempel KAN PHP-programutførelsesfunksjonene deaktiveres ved å endre php.ini-fil.

• Statisk Analyse

◦ Utfør statiske analyseaktiviteter for å identifisere sårbarheter knyttet til usikker evaluering.

• VAPT

◦ Utføre regelmessig Sårbarhetsvurdering og Penetrasjonstesting for å identifisere og redusere slike svakheter.