En av fördelarna med att vara säkerhetsspecialist är att arbeta med många team. Efter en revision får säkerhetsspecialister möjlighet att arbeta med databasadministratörer och analytiker. För att en applikation ska fungera korrekt och säkert försöker dessa team hantera säkerhetsbrister som har en gemensam grund. Dialoger mellan dessa team väcker vissa problem med verklig IP.
Proxy och riktiga IP-koncept
Dagens webbapplikationer körs på flera appservrar och databassystem. Föreställ dig två applikationsservrar som delar samma källkod. Förfrågningar från användaren är redo att tillgodoses av någon av dessa servrar beroende på belastningssituationen. Lastbalanseringsmekanismen, som hanterar HTTP-förfrågningar framför applikationsservrarna, bestämmer vilken begäran som ska vidarebefordras till vilken applikationsserver. Detta ställer en stor fråga för systemadministratörer och programvaruutvecklare: vad är användarens riktiga IP-adress?
Ombud är ansvariga för att överföra data mellan två system. Lastbalanseraren är den mekanism som ansvarar för proxyn. Med andra ord, bara ett system kommunicerar med både användaren och applikationsservern. När det gäller nätverkstrafik kommunicerar webb A- eller webb B-servrar alltid med lastbalanserarens IP-adress. Detsamma kan sägas om användare. För säkerhetspersonal orsakar lastbalanserare allvarliga problem i tidsbaserade SQL-injektionsattacker. Men huvudfokus här är IP-spoofing.
X-Forwarded-For och IP-relation
Tänk på förhållandet mellan X-Forwarded-For, utvecklare och middleware. Låt oss till exempel säga att uppgiften för utvecklaren av en applikation är att registrera alla aktiviteter, såsom felaktiga lösenordsförsök av användare, med deras IP-adresser. Till en början kommer utvecklaren att bestämma IP-adressen för användaren när HTTP-förfrågan uppfylls med möjlighet som erbjuds av det programmeringsspråk han använder och kommer att försöka fortsätta använda dessa data i Ansökan.
Eftersom dess IP-adress kommer att fixas under hela utvecklingsprocessen, kommer den alltid att se samma adress under tester eftersom användardatorer i allmänhet företagsnätverk fungerar med statisk IP över MAC-adressen. Enheten kommer att utföra några acceptanstester; dock kommer det att finnas problem med dessa. Testenheten kommer att vidarebefordra detta problem till mjukvaruutvecklaren.
I det här skedet kan utvecklaren skriva en kontroller i utvecklingsmiljön och se HTTP-förfrågan som skickas till applikationen i rå form, eftersom alla har samma IP-adress. Detta kommer att resultera i att arbeta med X-Forwarded-For.
Rubrikinformation kallas X-Forwarded-For kommer att skickas till applikationsservern. I det här skedet kommer mjukvaruutvecklaren att se sin IP-adress, som de kontrollerar med ipconfig, inte lastbalanseraren de ser i loggarna. Många programmerare tror att de kan lösa detta problem med ett kodblock som detta:
fungeragetIPaddress() {
$ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
för varje ($ipKeys som $key) {
om (array_key_exists($key, $_SERVER) Sann) {
för varje (explodera(',', $_SERVER[$nyckel]) som $ip) {
$ip = trim($ip);
om (validate_ip($ip)) {
lämna tillbaka $ip;
}
}
}
}
lämna tillbakaisset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: falsk;
}
Detta kommer inte att räcka – utvecklaren måste kontrollera om det inkommande värdet är en giltig IP-adress.
Allt ovan tillhörde den del som hanteras av utvecklaren. Men för att en applikation ska fungera korrekt och säkert, arbetar team tillsammans i teorin, men i verkligheten, vid extrema punkter från varandra – försök att hantera säkerhetsbrister som har en gemensam grund. Försök nu att se på frågan ur perspektivet av den person som är ansvarig för konfigurationen av lastbalanseraren.
Systemadministratörer kanske tror att utvecklare registrerar information som X-Forwarded-For eftersom data i HTTP-förfrågan inte kan litas på. Dessa administratörer sänder ofta X-Forwarded-For; emellertid överför de också TCP-källadressen för systemet som skickade begäran som ett andra huvudvärde. True-Client-IP-strukturen är ett bra exempel på detta.
När du sätter ihop alla dessa saker följer två olika enheter olika vägar för samma problem, känd som klient-IP-spoofing. Resultatet är ett kritiskt problem där ingen IP-loggning och IP-baserad auktorisering fungerar.
Hur upptäcks klientens IP-förfalskning i penetrationstester?
De flesta penetrationstestare använder Firefox för sina säkerhetskontroller. De konfigurerar Firefox med ett enkelt tillägg, X-Forwarded-For: 127.0.0.1 för alla HTTP-förfrågningar. Och så ökar möjligheten att upptäcka sådana sårbarheter i alla penetrationstester. Utföra en revision enligt OWASP checklista ser till att du kontrollerar sådana sårbarheter. För att upptäcka sårbarheten X-Forwarded-For behöver du dock en modul i applikationen som visar din IP-adress eller de åtgärder som vidtagits.
Hur man löser X-Forwarded-For-sårbarheten
Organisationer behöver ett obligatoriskt dokument för säker applikationsutveckling för alla mjukvaruteam och outsourcingföretag. Till exempel, om du behöver en användar-IP-adress, bör företaget planera i förväg och göra det till en regel om rubrikinformationen det kommer att använda här. Annars kommer olika team att ta fram olika lösningar. Om en sådan situation inte kan hanteras kommer outsourcingapplikationer att träda i kraft, vilket gör det svårt att mäta källkoder. Företag vill generellt inte gå en sådan väg.
Men för att lösa detta problem kan du använda följande F5-regel:
när HTTP_REQUEST {
HTTP:: header remove X-Forwarded-För
HTTP:: header infoga X-Forwarded-För [IP:: remote_addr]
}
Detta tar bort fältet X-Forwarded-For i HTTP-förfrågan från omvärlden. Sedan sänder den förfrågan genom att lägga till IP-adressen för systemet som skickade förfrågan till den. På så sätt skapas en tillförlitlig lista för programvara som agerar enligt X-Forwarded-For.
För att sammanfatta, det största målet här är att utföra vissa kontroller av HTTP-förfrågningar och att skapa en pålitlig miljö. Kodblocket ovan är ett bra exempel som du kan använda för detta.
Ramar och dokumentation för cybersäkerhet för företag
De enheter som verkar vara oberoende av varandra är faktiskt delar av en helhet. Därför måste allt fungera systematiskt. De i förväg fastställda reglerna ska tillämpas mellan varje enhet. Om ett sådant fungerande system inte antas kan många problem som X-Forwarded-For sårbarheten uppstå. För detta bör allt övervägas i förväg och så omfattande dokumentation som möjligt bör användas.
Och varje enhet i detta stora system måste anta och implementera ramverk för cybersäkerhet. Din utgångspunkt bör vara att undersöka och lära dig arbetslogiken i dessa ramverk.
