Hva er et rce-angrep (Ekstern Kjøring Av Kode)?
Ekstern Kjøring Av Kode brukes Til å avsløre en form for sårbarhet som kan utnyttes når brukerinndata injiseres i en fil eller streng, og hele pakken kjøres på parseren av programmeringsspråket. Dette er ikke typen oppførsel som vises av utvikleren av webapplikasjonen. Et Angrep Med Ekstern Kjøring Av Kode kan føre til et fullskala angrep som vil kompromittere en hel webapplikasjon og webserveren. Du bør også merke seg at nesten alle programmeringsspråk har forskjellige kodevalueringsfunksjoner.
en kodeevaluering kan også forekomme hvis du tillater at brukerinndata får tilgang til funksjoner som evaluerer kode i samme programmeringsspråk. Denne typen tiltak kan med hensikt implementeres for å få tilgang til de matematiske funksjonene i programmeringsspråket eller ved et uhell fordi den brukerstyrte inngangen er designet av utvikleren for å være inne i noen av disse funksjonene. Det er ikke tilrådelig å utføre denne handlingslinjen. Mange synes det er skadelig å selv bruke kode evaluering.
Eksempel På Kode
La oss ta en titt på et eksempel på et kodevalueringsangrep.
Det kan virke som en bedre ide å ha dynamisk genererte variable navn for hver bruker og lagre registreringsdatoen. Dette er et eksempel på hvordan DU kan gjøre DET gjort I PHP
eval("$$user = '$regdate');As long as the username is controlled by the user's input, an attacker may create a name like this:x = 'y';phpinfo();//PHP-koden som genereres vil likne dette:
$x = 'y';phpinfo();// = 2016';du kan nå se at variabelen er referert til som x, men har verdien av y. Når angriperen kan tildele en annen verdi til variabelen, vil han kunne opprette en ny kommando ved hjelp av et semikolon (;). Han kan nå fylle ut resten f strengen. På denne måten vil han ikke få noen syntaksfeil i sitt arbeid. Så snart han utfører denne koden, vil utgangen av phpinfo vises på siden. Du bør alltid huske at DET er mulig I PHP og andre språk med funksjoner som kan vurdere innspill.
Ordne Ekstern Kjøring Av Kode Etter Opprinnelse
flertallet AV de fremtredende RCE-svakhetene skyldes visse grunnleggende årsaker som kan følges tilbake til utgangspunktet. Grupperingen Av Ekstern Kjøring Av Kode ved begynnelse undersøkes som følger.
Dynamisk Kjøring Av Kode
Dynamisk Kjøring av Kode er den mest anerkjente grunnårsaken som ber om et angrep på kjøring av kode. Mange programmeringsdialekter er planlagt i en slik grad at de kan produsere kode med en annen kode og utføre den med en gang. Denne ideen er en fantastisk som håndterer ulike komplekse problemer. Vær det som mulig, en ondskapsfull angriper kan kontrollere denne ideen for å skaffe SEG TILGANG og kapasitet.
vanligvis er koden som produseres raskt avhengig av bestemt klientinngang. Vanligvis inneholder koden informasjonen som har blitt husket for en bestemt struktur. Når en ondartet angriper forstår at den kraftige koden alder vil utnytte visse opplysninger, det kan gjøre en betydelig kode som en type tilgang til å skille programmet. Hvis kundens bidrag ikke undersøkes, vil koden bli utført på sitt mål.
når du velger å se nøye, er dynamisk kodeutførelse ansvarlig for to typer RCE-baserte overgrep; umiddelbar og kretsende.
Direkte
når man håndterer en illustrasjon av direkte unik hyllestutførelse, innser aggressoren at tilbakemeldingen deres vil bli brukt til å produsere kode.
Indirekte
på en avvikende måte er det bekymret for den kraftige kodealderen med klientinnganger. Klientinngangen er vanligvis underlagt minst ett lag. En del av lagene kan være ansvarlige for å endre bidraget før det kommer opp med dynamisk kodealder. Dess, dynamisk kode alder kan være en påfølgende innvirkning og ikke umiddelbar utnyttelse av info. Det er grunnen til at det ikke kan være klart for klienten som gir info som vil fylle ut som en strukturblokk i en kode skrap som ville bli utført fjernt.
Deserialisering
Deserialisering er en utrolig guide for å skildre den nåværende omstendigheten. Ingen kraftig kode alder bør oppstå under deserialisering. Midlertidig er dette situasjonen som skjer når det serialiserte objektet inneholder grove informasjonsfelt eller objekter av sammenlignbar type. Ting blir mer forvirret når elementene i artikkelen er serialisert. Deserialisering vil også inkludere en viss grad av dynamisk kodealder.
det kan virke som kraftige dialekter er de eneste som påvirkes av arbeidsserialisering. Forutsatt at dette er sant, vil problemet være svært begrenset. Vær det som mulig, denne situasjonen er også svært nyttig i statiske dialekter. Det er vanskeligere å oppnå med det statiske språket, men det er absolutt ikke mulig.
Intermittent, gjennomføring av denne ideen styrer deserialization-produsert mellomledd kapasiteter. Alder objekter ved kjøring er bare tenkelig med dynamisk kode alder. Dette innebærer at hvis informasjonen som vil bli deserialisert er gjort i en oppfordring gjort fjernt, kan en ondskapsfull angriper kommandere og justere den. Rundt planlagte kodebiter kan også bli kjent med stunt den kraftige kodealderen for å utføre kapasiteten når den er innlemmet som et stykke av deserialiseringen.
Minnesikkerhet
En annen grunnleggende årsak til RCE-angrep identifiserer med minnesikkerhet eller API-sikkerhet. Memory wellbeing refererer til motvirkningen av kode fra å komme til grunnleggende deler av minnet som det ikke instate. Det er vanlig å forvente at mangel på minnesikkerhet vil resultere i uautorisert informasjonstilgang. I alle fall er arbeidsrammen og utstyret avhengig av minne for å lagre kjørbar kode. Metadata som identifiserer med kjøring av kode, holdes i minnet. Tilgang til dette stykket av minnet kan spørre ACE og RCE. På denne måten, hva er en del av årsakene til minne velvære problemer?
feil i produktets plan
Feil i produktkonfigurasjonen er en type minne velvære svakhet som skjer der det er en planlegging feil i en bestemt skjult del. Midlertidig kan mangeldelen være en kompilator, oversetter, virtuell maskin eller til og med arbeidsrammepartiet eller biblioteket. Det er forskjellige blemishes i denne klassen. En del av innlemmelsen;
Buffer Overflow
Buffer overflow i tillegg referert til som buffer overread, kan brukes til å referere til en grunnleggende og berømt metode som brukes til å bryte minne velvære. Dette angrepet utnytter en bestemt planfeil eller en feil for å holde kontakten med minnecellene som ligger mot slutten av minneputen. Støtten vil bli hentet tilbake fra en autentisk samtale til offentlig API. Likevel refererer cradle bare til et startsted trussel brukes til å registrere de faktiske minnestedene til en bestemt artikkel eller programteller. Deres adskillelse fra vuggen er bemerkelsesverdig eller kan utvilsomt spekuleres. Undersøkelse av koden når den er tilgjengelig eller feilsøking av hele programutførelsen ved kjøretid, kan ende opp med å være nyttig for en aggressor som trenger å se på relative stillinger.
dette innebærer at en vugge flom ville tillate til en viss grad utilgjengelig minne å bli endret. Vuggen kan bli funnet i plasseringsrommet til en annen maskin, og den vil bli endret ved å ringe en fjern API. Dette vil gjøre adgang til minnet til den eksterne maskinen. Det er mange måter å utnytte denne typen tilgang til å lage en rce dobbelthandel. Det er en generell mistanke om at forutsatt at det er en pute flom svakhet, er ET RCE-basert angrep ikke av kortene. Dette innebærer at kodeeiere er avhengig av å raskt fikse deres støtteflom før ET RCE-angrep skjer.
Utstyr Design Feil
Minne velvære overgrep kan også være på grunn av utstyr konfigurasjon blemishes. De er ikke så vanlige som programmeringsangrep og er mye vanskeligere å gjenkjenne. Likevel påvirker denne typen angrep enormt rammen.
Konsekvenser Av Sårbarhet For Ekstern Kodeevaluering
en angriper som kan utføre Et Eksternt Kodebasert angrep på et system, vil kunne utføre andre kommandoer ved å utnytte programmeringsspråket eller webserveren. På mange programmeringsspråk kan angriperen kommandere systemet til å skrive, lese eller slette filer. Det kan også være mulig å koble til ulike databaser med angrepet systemet.
Hvorfor Starter Angripere rce-angrep?
selv om det ikke er noen spesiell grunn til at angripere velger Å utnytte RCE-utnyttelse for å angripe en webapplikasjon, er det ingen spesiell grunn. Det er bare at noen ondsinnede finner det enkelt å dra nytte av denne kodekjøringen for å få tilgang til systemene dine.
Hvordan Kan Du Forhindre Ekstern Kjøring Av Kode Angrep?
til å begynne med bør du unngå bruk av brukerinngang inne i evaluert kode. Det beste alternativet i denne situasjonen ville være å helt unngå å bruke funksjoner som eval. Det anses å være en form for dårlig praksis og kan lett unngås. Det anbefales også at du aldri skal la en bruker redigere innholdet i filer som kan ha blitt analysert av det aktuelle programmeringsspråket. Ofte, dette inkluderer å la en bruker opprette navn og filtyper som han ønsker å laste opp eller opprette i web-applikasjon.
Dette er noen av tingene du ikke bør gjøre for å unngå rce-baserte angrep. De inkluderer:
- Sanitizing brukerinngang. Ofte er dette vanskelig å oppnå fordi det er en stor mengde forhåndsinstallerte bypasser og restriksjoner.
- la en bruker bestemme eller opprette utvidelsen eller innholdet av filer som skal brukes på webserveren. Han / hun må bruke mange sikre rutiner ved håndtering av filopplastinger eller risikere at viktig informasjon faller i gale hender.
- Send alle brukerstyrte inndata til systemanrop eller evalueringsfunksjoner
- aktivt svartelisting av spesielle tegn eller funksjonsnavn. Dette bør unngås akkurat som å rense brukerinngang. Men det er utrolig vanskelig å implementere.