En af fordelene ved at være sikkerhedsspecialist er at arbejde med adskillige teams. Efter en revision vil sikkerhedsspecialister have mulighed for at arbejde med databaseadministratorer og analytikere. For at en applikation skal fungere korrekt og sikkert, forsøger disse teams at håndtere sikkerhedssårbarheder, der har et fælles grundlag. Dialoger mellem disse teams rejser nogle problemer med ægte IP.
Proxy og ægte IP-koncepter
Nutidens webapplikationer kører på flere app-servere og databasesystemer. Forestil dig to applikationsservere, der deler den samme kildekode. Anmodninger fra brugeren er klar til at blive imødekommet af en af disse servere afhængigt af belastningssituationen. Belastningsbalanceringsmekanismen, som håndterer HTTP-anmodninger foran applikationsserverne, bestemmer hvilken anmodning, der skal videresendes til hvilken applikationsserver. Dette stiller et stort spørgsmål til middleware-systemadministratorer og softwareudviklere: hvad er brugerens rigtige IP-adresse?
Fuldmægtige er ansvarlige for at overføre data mellem to systemer. Loadbalanceren er den mekanisme, der er ansvarlig for proxyen. Med andre ord kommunikerer kun ét system med både brugeren og applikationsserveren. Med hensyn til netværkstrafik kommunikerer web A- eller web B-servere altid med load balancerens IP-adresse. Det samme kan siges om brugerne. For sikkerhedsprofessionelle forårsager belastningsbalancere alvorlige problemer i tidsbaserede SQL-injektionsangreb. Men hovedfokus her er IP-spoofing.
X-Forwarded-For og IP-forhold
Overvej forholdet mellem X-Forwarded-For, udvikler og middleware. Lad os f.eks. sige, at opgaven for udvikleren af en applikation er at registrere alle aktiviteter, såsom forkerte adgangskodeforsøg fra brugere, med deres IP-adresser. I første omgang vil udvikleren bestemme brugerens IP-adresse, når HTTP-anmodningen opfyldes med mulighed givet af det programmeringssprog, han bruger, og vil forsøge at fortsætte med at bruge disse data i Ansøgning.
Da dens IP-adresse vil være fast under hele udviklingsprocessen, vil den altid se den samme adresse under tests, fordi generelt bruger computere i virksomhedsnetværk arbejder med statisk IP over MAC-adressen. Enheden vil udføre nogle accepttests; dog vil der være problemer med disse. Testenheden videresender dette problem til softwareudvikleren.
På dette stadium kan udvikleren skrive en controller i udviklingsmiljøet og se HTTP-anmodningen sendes til applikationen i rå form, da alle har den samme IP-adresse. Dette vil resultere i at arbejde med X-Forwarded-For.
Overskriftsoplysninger kaldet X-Forwarded-For vil blive sendt til applikationsserveren. På dette tidspunkt vil softwareudvikleren se deres IP-adresse, som de kontrollerer med ipconfig, ikke den load balancer, de ser i logfilerne. Mange programmører tror, at de kan løse dette problem med en kodeblok som denne:
fungerefå IP-adresse() {
$ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
for hver ($ipKeys som $nøgle) {
hvis (array_key_exists($key, $_SERVER) rigtigt) {
for hver (eksplodere(',', $_SERVER[$key]) som $ip) {
$ip = trim($ip);
hvis (validate_ip($ip)) {
Vend tilbage $ip;
}
}
}
}
Vend tilbageisset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: falsk;
}
Dette vil ikke være nok - udvikleren skal kontrollere, om den indgående værdi er en gyldig IP-adresse.
Alt ovenfor tilhørte den del, der varetages af udvikleren. Men for at en applikation skal fungere korrekt og sikkert, skal teams arbejde sammen i teorien, men i virkeligheden, på ekstreme punkter fra hinanden – prøv at håndtere sikkerhedssårbarheder, der har en fælles grundlag. Prøv nu at se på problemet fra perspektivet af den person, der er ansvarlig for konfigurationen af belastningsbalanceren.
Systemadministratorer tror måske, at udviklere registrerer oplysninger såsom X-Forwarded-For, fordi data i HTTP-anmodningen ikke kan stole på. Disse administratorer sender ofte X-Forwarded-For; de transmitterer dog også TCP-kildeadressen for det system, der sendte anmodningen, som en anden headerværdi. True-Client-IP-strukturen er et godt eksempel på dette.
Når du sætter alle disse ting sammen, følger to forskellige enheder forskellige veje for det samme problem, kendt som klient IP-spoofing. Resultatet er et kritisk problem, hvor ingen IP-logning og IP-baseret godkendelse vil fungere.
Hvordan opdages klient-IP-spoofing i penetrationstests?
De fleste penetrationstestere bruger Firefox til deres sikkerhedstjek. De konfigurerer Firefox med en simpel tilføjelse, X-Forwarded-For: 127.0.0.1 til alle HTTP-anmodninger. Så muligheden for at opdage sådanne sårbarheder i alle penetrationstests øges. Udførelse af revision iht OWASP tjekliste sikrer, at du tjekker for sådanne sårbarheder. For at opdage X-Forwarded-For sårbarheden skal du dog have et modul i applikationen, der viser din IP-adresse eller de handlinger, der er foretaget.
Sådan løses X-Forwarded-For sårbarheden
Organisationer har brug for et obligatorisk dokument til sikker applikationsudvikling til alle softwareteams og outsourcingvirksomheder. Hvis du f.eks. har brug for en bruger-IP-adresse, bør virksomheden planlægge og gøre det til en regel om de headeroplysninger, den vil bruge her. Ellers vil forskellige teams producere forskellige løsninger. Hvis en sådan situation ikke kan håndteres, vil outsourcing af applikationer komme i spil, hvilket gør det vanskeligt at måle kildekoder. Generelt ønsker virksomheder ikke at følge en sådan vej.
Men for at løse dette problem kan du bruge følgende F5-regel:
når HTTP_REQUEST {
HTTP:: header fjern X-Forwarded-Til
HTTP:: header indsæt X-Forwarded-Til [IP:: remote_addr]
}
Dette fjerner feltet X-Forwarded-For i HTTP-anmodningen fra omverdenen. Derefter sender den anmodningen ved at tilføje IP-adressen på det system, der sendte anmodningen til den. På den måde skabes en pålidelig liste for software, der fungerer efter X-Forwarded-For.
For at opsummere er det største mål her at udføre nogle kontroller på HTTP-anmodninger og at skabe et pålideligt miljø. Kodeblokken ovenfor er et godt eksempel du kan bruge til dette.
Cybersikkerhedsrammer og dokumentation for virksomheder
De enheder, der ser ud til at være uafhængige af hinanden, er faktisk dele af en helhed. Derfor skal alt arbejde systematisk. De på forhånd fastsatte regler skal anvendes mellem hver enhed. Hvis et sådant arbejdssystem ikke er vedtaget, kan der opstå mange problemer såsom X-Forwarded-For sårbarheden. Hertil bør alt overvejes på forhånd, og der bør anvendes så omfattende dokumentation som muligt.
Og hver enhed i dette store system skal vedtage og implementere cybersikkerhedsrammer. Dit udgangspunkt bør være at undersøge og lære arbejdslogikken i disse rammer.
