hvad er et RCE-angreb?
fjernkørsel af kode bruges til at afsløre en form for sårbarhed, der kan udnyttes, når brugerinput injiceres i en fil eller streng, og hele pakken køres på parseren af programmeringssproget. Dette er ikke den type adfærd, der udstilles af udvikleren af internetapplikationen. Et eksternt Kodeudførelsesangreb kan føre til et angreb i fuld skala, der vil kompromittere en hel internetapplikation og internetserveren. Du skal også bemærke, at stort set alle programmeringssprog har forskellige kodeevalueringsfunktioner.
en kodeevaluering kan også forekomme, hvis du tillader brugerinput at få adgang til funktioner, der evaluerer kode på det samme programmeringssprog. Denne type foranstaltning kan med vilje implementeres for at få adgang til programmeringssprogets matematiske funktioner eller ved et uheld, fordi det brugerstyrede input er designet af udvikleren til at være inde i nogen af disse funktioner. Det er ikke tilrådeligt at udføre denne handlingslinje. Mange mennesker finder det ondsindet at endda bruge kode evaluering.
eksempel på kode
lad os se på et eksempel på et kodeevalueringsangreb.
det kan virke som en bedre ide at have dynamisk genererede variabelnavne for hver bruger og gemme deres Registreringsdato. Dette er et eksempel på, hvordan du kan gøre det er 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, der genereres, ligner dette:
$x = 'y';phpinfo();// = 2016';når angriberen kan tildele en anden værdi til variablen, vil han være i stand til at oprette en ny kommando ved hjælp af et semikolon (;). Han kan nu udfylde resten f strengen. På denne måde får han ingen syntaksfejl i sit arbejde. Så snart han udfører denne kode, vises output fra phpinfo på siden. Du skal altid huske, at det er muligt i PHP og andre sprog med funktioner, der kan vurdere input.
arrangere fjernkørsel af kode efter Oprindelse
størstedelen af de fremtrædende RCE-svagheder skyldes visse grundlæggende årsager, der kan følges tilbage til udgangspunktet. Grupperingen af Fjernkodeudførelse ved begyndelse undersøges som følger.
dynamisk kodekørsel
dynamisk kodekørsel er efter alt at dømme den mest anerkendte grundlæggende årsag, der beder om et kodeksekveringsangreb. Mange programmeringsdialekter er planlagt i en sådan grad, at de kan producere kode med en anden kode og udføre den med det samme. Denne ide er fantastisk, der håndterer forskellige komplekse problemer. Uanset hvad det er, kan en ondsindet angriber kontrollere denne ide for at erhverve RCE-adgang og kapacitet.
normalt afhænger den producerede kode hurtigt af visse klientinput. Koden indeholder sædvanligvis de oplysninger, der er blevet husket for en bestemt struktur. Når en ondartet aggressor forstår, at den magtfulde kodealder vil bruge visse oplysninger, det kan gøre en betydelig kode som en type adgang til at adskille applikationen. Hvis kundernes bidrag ikke undersøges, vil koden blive udført på sit mål.
på det tidspunkt, hvor du vælger at se nøje, er dynamisk kodeudførelse ansvarlig for to slags RCE-baserede overfald; øjeblikkelig og kredsløb.
direkte
når man styrer en illustration af direkte unik hyldestudførelse, indser aggressoren, at deres feedback ville blive brugt til at producere kode.
indirekte
på en afvigende måde er det bekymret for den magtfulde kodealder med klientindgange. Klientens input er typisk underlagt mindst et lag. En del af lagene kan være ansvarlige for at ændre bidraget, før det ender med dynamisk kodealder. Derudover, dynamisk kodealder kan være en efterfølgende indvirkning og ikke den øjeblikkelige anvendelse af informationen. Det er grunden til, at det måske ikke er klart for klienten, der giver de oplysninger, der vil udfylde som en strukturblok i et kodeskrot, der ville blive udført fjernt.
deserialisering
deserialisering er en utrolig guide til at skildre den nuværende omstændighed. Ingen kraftig kodealder burde forekomme under deserialisering. Intermitterende er dette den situation, der sker, når det serialiserede objekt indeholder rå informationsfelter eller objekter af en sammenlignelig slags. Ting bliver mere forvirrede, når artiklens elementer serialiseres. Deserialisering ville ligeledes inkorporere en vis grad af dynamisk kodealder.
det kan virke som om magtfulde dialekter er de eneste, der er påvirket af arbejdsserialisering. Forudsat at dette er sandt, ville spørgsmålet være meget begrænset. Uanset hvad det er, er denne situation også meget nyttig i statiske dialekter. Det er sværere at opnå med det statiske sprog, men det er bestemt ikke muligt.
intermitterende styrer udførelsen af denne ide deserialiseringsproducerede formidlingskapaciteter. Alder objekter på runtime er bare tænkelige med dynamisk kode alder. Dette indebærer, at hvis de oplysninger, der vil blive deserialiseret, fremsættes i en anmodning, der foretages fjernt, en ondsindet angriber kunne kommandere og justere den. Rundt omkring planlagte kodebits kunne ligeledes være bekendt med stunt den magtfulde kodealder til at udføre kapaciteten, når den er indarbejdet som et stykke af deserialiseringen.
Hukommelsessikkerhed
en mere grundlæggende årsag til RCE-angreb identificerer sig med hukommelsessikkerhed eller API-sikkerhed. Hukommelse velvære henviser til modvirkning af kode fra at komme til grundlæggende stykker hukommelse, som det ikke instate. Det er almindeligt at forvente, at manglende hukommelsessikkerhed ville resultere i uautoriseret adgang til oplysninger. Under alle omstændigheder afhænger arbejdsrammen og udstyret af hukommelsen for at gemme eksekverbar kode. Metadata, der identificerer med kodekørsel, opbevares i hukommelsen. Adgang til dette stykke hukommelse kan bede ACE og RCE. På denne måde, Hvad er en del af årsagerne til hukommelsesvelfærdsproblemer?
ufuldkommenhederne i produktets plan
ufuldkommenheder i produktkonfigurationen er en type hukommelsesvelfærdssvaghed, der sker, hvor der er en planlægningsfejl i en bestemt skjult del. Intermitterende kan mangelsdelen være en kompilator, oversætter, virtuel maskine eller endda arbejdsrammedelen eller biblioteket. Der er forskellige pletter i denne klasse. En del af inkorporeringen;
bufferoverløb
bufferoverløb, der desuden henvises til som bufferoverlæsning, kan bruges til at henvise til en grundlæggende og berømt metode, der bruges til at bryde hukommelsesvelfærd. Dette angreb drager fordel af en bestemt planfejl eller en fejl for at holde kontakten med hukommelsescellerne, der er placeret mod slutningen af hukommelsespuden. Støtten ville komme tilbage fra et autentisk opkald til offentlig API. Ikke desto mindre henviser cradle kun til en startsted trussel bruges til at registrere de faktiske hukommelsessteder for en bestemt artikel eller programtæller. Deres adskillelse fra vuggen er bemærkelsesværdig eller kan utvivlsomt spekuleres. Undersøgelse af koden, når den gøres tilgængelig eller fejlfinding af hele programudførelsen ved kørsel, kan ende med at være nyttig for en aggressor, der har brug for at undersøge relative positioner.
dette indebærer, at en vugge oversvømmelse ville tillade, at den til en vis grad utilgængelige hukommelse ændres. Vuggen kan findes i placeringen plads på en mere maskine, og det vil blive ændret ved at kalde en fjern API. Dette vil gøre adgang til hukommelsen på fjernmaskinen. Der er mange metoder til at udnytte denne form for adgang til at gøre en RCE dobbelt-handel. Der er en generel mistanke om, at forudsat at der er en pude oversvømmelse svaghed, er et RCE-baseret angreb ikke ude af kortene. Dette indebærer, at kodeindehavere påberåbes for straks at rette deres support oversvømmelser, før et RCE-angreb sker.
udstyr Design fejl
hukommelse velvære overfald kan ligeledes være på grund af udstyr konfiguration pletter. De er ikke så normale som programmeringsangreb og er meget sværere at genkende. Alligevel påvirker denne form for angreb enormt rammen.
virkninger af sårbarhed ved evaluering af Fjernkode
en angriber, der kan udføre et Fjernkodebaseret angreb på et system med succes, ville være i stand til at udføre andre kommandoer ved at drage fordel af programmeringssproget eller internetserveren. På mange programmeringssprog ville angriberen være i stand til at kommandere systemet til at skrive, læse eller slette filer. Det kan endda være muligt at oprette forbindelse til forskellige databaser med det angrebne system.
Hvorfor starter angribere RCE-angreb?
selvom der ikke er nogen særlig grund til, at angribere vælger at udnytte RCE-udnyttelse til at angribe en internetapplikation, er der ingen særlig grund. Det er bare, at nogle ondsindede finder det nemt at drage fordel af denne kodekørsel for at få adgang til dine systemer.
Hvordan Forhindrer Du Eksterne Kodeudførelsesangreb?
til at begynde med skal du undgå brug af brugerinput inde i evalueret kode. Den bedste mulighed i denne situation ville være helt at undgå at bruge funktioner som eval. Det anses for at være en form for dårlig praksis og kan let undgås. Det anbefales også, at du aldrig lader en bruger redigere indholdet af filer, der muligvis er blevet analyseret af det pågældende programmeringssprog. Ofte inkluderer dette at lade en bruger oprette det navn og filtypenavne, som han vil uploade eller oprette i internetapplikationen.
dette er nogle af de ting, du ikke bør gøre for at undgå RCE-baserede angreb. De omfatter:
- desinficering af brugerinput. Ofte er dette vanskeligt at opnå, fordi der er en stor mængde forudinstallerede bypasser og begrænsninger.
- lad en bruger bestemme eller oprette udvidelsen eller indholdet af filer, der skal bruges på internetserveren. Han / hun skal bruge mange sikre fremgangsmåder, når han håndterer filoverførsler eller risikerer, at vigtige oplysninger falder i de forkerte hænder.
- send ethvert brugerstyret input til systemtilbagekaldelser eller evalueringsfunktioner
- aktivt sortliste eventuelle specielle tegn eller funktionsnavne. Dette bør undgås ligesom desinficering af brugerinput. Men det er utroligt svært at gennemføre.