Een van de voordelen van een beveiligingsspecialist zijn, is het werken met tal van teams. Na een audit krijgen beveiligingsspecialisten de kans om samen te werken met databasebeheerders en analisten. Om een applicatie goed en veilig te laten werken, proberen deze teams om te gaan met beveiligingsproblemen die een gemeenschappelijke basis hebben. Dialogen tussen deze teams werpen enkele problemen op met echte IP.
Proxy en echte IP-concepten
De webapplicaties van tegenwoordig draaien op meerdere app-servers en databasesystemen. Stel je voor dat twee applicatieservers dezelfde broncode delen. Verzoeken van de gebruiker kunnen door een van deze servers worden ingewilligd, afhankelijk van de belastingssituatie. Het load balancing-mechanisme, dat HTTP-verzoeken voor de applicatieservers afhandelt, beslist welk verzoek naar welke applicatieserver wordt doorgestuurd. Dit roept een grote vraag op voor middleware-systeembeheerders en softwareontwikkelaars: wat is het echte IP-adres van de gebruiker?
Proxy's zijn verantwoordelijk voor het verzenden van gegevens tussen twee systemen. De load balancer is het mechanisme dat verantwoordelijk is voor de proxy. Met andere woorden, slechts één systeem communiceert met zowel de gebruiker als de applicatieserver. In termen van netwerkverkeer communiceren web A- of web B-servers altijd met het IP-adres van de load balancer. Hetzelfde kan gezegd worden voor gebruikers. Voor beveiligingsprofessionals veroorzaken load balancers ernstige problemen bij op tijd gebaseerde SQL-injectieaanvallen. Maar de belangrijkste focus hier is IP-spoofing.
X-Forwarded-For en IP-relatie
Overweeg de relatie tussen X-Forwarded-For, ontwikkelaar en middleware. Stel dat het de taak van de ontwikkelaar van een applicatie is om alle activiteiten, zoals foutieve wachtwoordpogingen van gebruikers, vast te leggen met hun IP-adressen. In eerste instantie zal de ontwikkelaar het IP-adres van de gebruiker bepalen wanneer aan het HTTP-verzoek wordt voldaan met de mogelijkheid geboden door de programmeertaal die hij gebruikt en zal proberen deze gegevens te blijven gebruiken in de sollicitatie.
Aangezien het IP-adres tijdens het ontwikkelingsproces vast blijft staan, zal het tijdens tests altijd hetzelfde adres zien, omdat over het algemeen gebruikerscomputers in bedrijfsnetwerken werken met statisch IP via MAC-adres. De unit voert enkele acceptatietesten uit; er zullen echter problemen mee zijn. De testunit geeft dit probleem door aan de softwareontwikkelaar.
In dit stadium kan de ontwikkelaar een controller in de ontwikkelomgeving schrijven en het HTTP-verzoek in onbewerkte vorm naar de applicatie zien verzonden, aangezien iedereen hetzelfde IP-adres heeft. Dit resulteert in het werken met X-Forwarded-For.
Header informatie genaamd X-Forwarded-For wordt verzonden naar de toepassingsserver. In dit stadium ziet de softwareontwikkelaar zijn IP-adres, dat hij beheert met ipconfig, niet de load balancer die hij in de logboeken ziet. Veel programmeurs denken dat ze dit probleem kunnen oplossen met een codeblok als dit:
functiekrijgIPadres() {
$ipKeys = reeks(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
voor elk ($ipKeys als $ sleutel) {
als (array_key_exists($key, $_SERVER) WAAR) {
voor elk (ontploffen(',', $_SERVER[$sleutel]) als $ip) {
$ip = trimmen($ip);
als (validate_ip($ip)) {
opbrengst $ip;
}
}
}
}
opbrengstis ingesteld($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: vals;
}
Dit is niet genoeg: de ontwikkelaar moet controleren of de binnenkomende waarde een geldig IP-adres is.
Alles hierboven behoorde tot het deel dat door de ontwikkelaar werd afgehandeld. Maar om een applicatie correct en veilig te laten werken, moeten teams - in theorie samenwerken, maar in realiteit, op extreme punten van elkaar verwijderd - probeer om te gaan met beveiligingskwetsbaarheden die een gemeenschappelijke basis. Probeer nu het probleem te bekijken vanuit het perspectief van de persoon die verantwoordelijk is voor de configuratie van de load balancer.
Systeembeheerders zouden kunnen denken dat ontwikkelaars informatie zoals X-Forwarded-For vastleggen omdat de gegevens in het HTTP-verzoek niet vertrouwd kunnen worden. Die beheerders verzenden vaak X-Forwarded-For; ze verzenden echter ook het TCP-bronadres van het systeem dat het verzoek heeft verzonden als een tweede headerwaarde. De True-Client-IP structuur is hier een goed voorbeeld van.
Als je al deze dingen samenvoegt, volgen twee verschillende eenheden verschillende paden voor hetzelfde probleem, ook wel client-IP-spoofing genoemd. Het resultaat is een cruciaal probleem waarbij IP-logging en IP-gebaseerde autorisatie niet werken.
Hoe wordt IP-spoofing van clients gedetecteerd in penetratietests?
De meeste penetratietesters gebruiken Firefox voor hun beveiligingscontroles. Ze configureren Firefox met een eenvoudige add-on, X-Forwarded-For: 127.0.0.1 voor alle HTTP-verzoeken. En dus neemt de mogelijkheid toe om dergelijke kwetsbaarheden in alle penetratietesten te detecteren. Het uitvoeren van een audit volgens de OWASP-checklist zorgt ervoor dat u op dergelijke kwetsbaarheden controleert. Om de X-Forwarded-For-kwetsbaarheid te detecteren, hebt u echter een module in de applicatie nodig die uw IP-adres of de ondernomen acties laat zien.
Hoe de X-Forwarded-For-kwetsbaarheid op te lossen
Organisaties hebben een verplicht beveiligd applicatie-ontwikkelingsdocument nodig voor alle softwareteams en outsourcingbedrijven. Als u bijvoorbeeld een IP-adres van een gebruiker nodig heeft, moet het bedrijf vooruit plannen en een regel maken over de header-informatie die het hier zal gebruiken. Anders zullen verschillende teams verschillende oplossingen produceren. Als een dergelijke situatie niet kan worden aangepakt, zal het uitbesteden van applicaties een rol gaan spelen, waardoor het moeilijk wordt om broncodes te meten. Over het algemeen willen bedrijven zo'n pad niet volgen.
Maar om dit probleem op te lossen, kunt u de volgende F5-regel gebruiken:
wanneer HTTP_REQUEST {
HTTP:: header verwijderen X-Forwarded-Voor
HTTP:: header invoegen X-Forwarded-Voor [IP:: remote_addr]
}
Dit verwijdert het veld X-Forwarded-For in het HTTP-verzoek van de buitenwereld. Vervolgens verzendt het het verzoek door het IP-adres toe te voegen van het systeem dat het verzoek heeft verzonden. Op die manier ontstaat er een betrouwbare lijst voor software die handelt volgens X-Forwarded-For.
Om samen te vatten, het grootste doel hier is om enkele controles uit te voeren op HTTP-verzoeken en om een betrouwbare omgeving te creëren. Het bovenstaande codeblok is een goed voorbeeld dat je hiervoor kunt gebruiken.
Kaders en documentatie voor cyberbeveiliging voor ondernemingen
De eenheden die onafhankelijk van elkaar lijken te zijn, zijn in feite delen van een geheel. Daarom moet alles systematisch werken. Tussen elke eenheid moeten de vooraf bepaalde regels worden toegepast. Als een dergelijk werkend systeem niet wordt aangenomen, kunnen er veel problemen optreden, zoals de X-Forwarded-For-kwetsbaarheid. Hiervoor moet alles van tevoren worden overwogen en moet een zo volledig mogelijke documentatie worden gebruikt.
En elke eenheid in dit grote systeem moet cyberbeveiligingskaders aannemen en implementeren. Uw uitgangspunt zou moeten zijn om de werklogica van deze raamwerken te onderzoeken en te leren.