En av fordelene med å være sikkerhetsspesialist er å jobbe med en rekke team. Etter en revisjon vil sikkerhetsspesialister ha mulighet til å jobbe med databaseadministratorer og analytikere. For at en applikasjon skal fungere riktig og sikkert, prøver disse teamene å håndtere sikkerhetssårbarheter som har et felles grunnlag. Dialoger mellom disse teamene reiser noen problemer med ekte IP.
Proxy og ekte IP-konsepter
Dagens nettapplikasjoner kjører på flere appservere og databasesystemer. Se for deg to applikasjonsservere som deler samme kildekode. Forespørsler fra brukeren er klare til å bli møtt av en av disse serverne avhengig av belastningssituasjonen. Lastbalanseringsmekanismen, som håndterer HTTP-forespørsler foran applikasjonsserverne, bestemmer hvilken forespørsel som skal videresendes til hvilken applikasjonsserver. Dette stiller et stort spørsmål for mellomvaresystemadministratorer og programvareutviklere: hva er brukerens virkelige IP-adresse?
Fullmakter har ansvaret for å overføre data mellom to systemer. Lastbalanseren er mekanismen som har ansvaret for proxyen. Med andre ord, bare ett system kommuniserer med både brukeren og applikasjonsserveren. Når det gjelder nettverkstrafikk, kommuniserer web A- eller web B-servere alltid med lastbalanserens IP-adresse. Det samme kan sies om brukere. For sikkerhetseksperter forårsaker lastbalansere alvorlige problemer i tidsbaserte SQL-injeksjonsangrep. Men Hovedfokus her er IP-spoofing.
X-Forwarded-For og IP-forhold
Vurder forholdet mellom X-Forwarded-For, utvikler og mellomvare. La oss for eksempel si at oppgaven til utvikleren av en applikasjon er å registrere alle aktiviteter, for eksempel feil passordforsøk fra brukere, med deres IP-adresser. Først vil utvikleren bestemme IP-adressen til brukeren når HTTP-forespørselen blir møtt med mulighet gitt av programmeringsspråket han bruker og vil prøve å fortsette å bruke disse dataene i applikasjon.
Siden IP-adressen vil bli fikset gjennom hele utviklingsprosessen, vil den alltid se den samme adressen under tester fordi vanligvis brukerdatamaskiner i bedriftsnettverk fungerer med statisk IP over MAC-adressen. Enheten vil utføre noen aksept tester; det vil imidlertid være problemer med disse. Testenheten vil videresende dette problemet til programvareutvikleren.
På dette stadiet kan utvikleren skrive en kontroller i utviklingsmiljøet og se HTTP-forespørselen overført til applikasjonen i råform, siden alle har samme IP-adresse. Dette vil resultere i arbeid med X-Forwarded-For.
Overskriftsinformasjon kalt X-Forwarded-For vil bli sendt til applikasjonsserveren. På dette stadiet vil programvareutvikleren se IP-adressen sin, som de kontrollerer med ipconfig, ikke lastbalanseren de ser i loggene. Mange programmerere tror at de kan løse dette problemet med en kodeblokk som dette:
funksjonfå 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 $key) {
hvis (array_key_exists($key, $_SERVER) ekte) {
for hver (eksplodere(',', $_SERVER[$key]) som $ip) {
$ip = trim($ip);
hvis (validate_ip($ip)) {
komme tilbake $ip;
}
}
}
}
komme tilbakeisset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: falsk;
}
Dette vil ikke være nok – utvikleren må sjekke om den innkommende verdien er en gyldig IP-adresse.
Alt ovenfor tilhørte den delen som ble håndtert av utbygger. Men for at en applikasjon skal fungere riktig og sikkert, jobber team – sammen i teorien, men i virkeligheten, på ekstreme punkter fra hverandre – prøv å håndtere sikkerhetssårbarheter som har en felles grunnlag. Prøv nå å se på problemet fra perspektivet til personen som er ansvarlig for konfigurasjonen av lastbalanseren.
Systemadministratorer tror kanskje at utviklere registrerer informasjon som X-Forwarded-For fordi data i HTTP-forespørselen ikke kan stoles på. Disse administratorene sender ofte X-Forwarded-For; imidlertid overfører de også TCP-kildeadressen til systemet som sendte forespørselen som en andre overskriftsverdi. True-Client-IP-strukturen er et godt eksempel på dette.
Når du setter alle disse tingene sammen, følger to forskjellige enheter forskjellige veier for det samme problemet, kjent som klient-IP-spoofing. Resultatet er et kritisk problem der ingen IP-logging og IP-basert autorisasjon vil fungere.
Hvordan oppdages klient-IP-spoofing i penetrasjonstester?
De fleste penetrasjonstestere bruker Firefox for sikkerhetskontrollene sine. De konfigurerer Firefox med et enkelt tillegg, X-Forwarded-For: 127.0.0.1 for alle HTTP-forespørsler. Og dermed øker muligheten for å oppdage slike sårbarheter i alle penetrasjonstester. Utføre revisjon i henhold til OWASP Sjekkliste sikrer at du sjekker for slike sårbarheter. For å oppdage X-Forwarded-For-sårbarheten trenger du imidlertid en modul i applikasjonen som viser IP-adressen din eller handlingene som er utført.
Slik løser du X-Forwarded-For-sårbarheten
Organisasjoner trenger et obligatorisk dokument for sikker applikasjonsutvikling for alle programvareteam og outsourcingselskaper. Hvis du for eksempel trenger en bruker-IP-adresse, bør selskapet planlegge og gjøre det til en regel om overskriftsinformasjonen den skal bruke her. Ellers vil ulike team produsere ulike løsninger. Hvis en slik situasjon ikke kan håndteres, vil outsourcing-applikasjoner spille inn, noe som gjør det vanskelig å måle kildekoder. Generelt ønsker ikke bedrifter å gå en slik vei.
Men for å løse dette problemet kan du bruke følgende F5-regel:
når HTTP_REQUEST {
HTTP:: header fjern X-Forwarded-Til
HTTP:: header sett inn X-Forwarded-Til [IP:: remote_addr]
}
Dette fjerner X-Forwarded-For-feltet i HTTP-forespørselen fra omverdenen. Deretter overfører den forespørselen ved å legge til IP-adressen til systemet som sendte forespørselen til den. På den måten opprettes en pålitelig liste for programvare som fungerer i henhold til X-Forwarded-For.
For å oppsummere er det største målet her å utføre noen kontroller på HTTP-forespørsler og å skape et pålitelig miljø. Kodeblokken ovenfor er et godt eksempel du kan bruke til dette.
Nettsikkerhetsrammer og dokumentasjon for bedrifter
Enhetene som ser ut til å være uavhengige av hverandre er faktisk deler av en helhet. Derfor må alt fungere systematisk. Reglene fastsatt på forhånd skal gjelde mellom hver enhet. Hvis et slikt fungerende system ikke blir tatt i bruk, kan mange problemer som X-Forwarded-For-sårbarheten oppstå. For dette bør alt vurderes på forhånd og dokumentasjon så omfattende som mulig bør brukes.
Og hver enhet i dette store systemet må ta i bruk og implementere cybersikkerhetsrammer. Ditt utgangspunkt bør være å undersøke og lære arbeidslogikken til disse rammeverkene.