Een stukje uitleg over de HTTP_PROXY vulnerability die op https://httpoxy.org/ gemeld is.

Je site is vulnerable indien aan de volgende criteria wordt voldaan:

• Je hebt een webapplicatie die zelf webaanroepen doet; bijvoorbeeld communicatie met een payment provider of interne backend (d.m.v. python-requests, curl, http_get, etc…).
• De webserver laat de Proxy header door als HTTP_PROXY. Dit is standaard zo.
• De HTTP_PROXY header komt tussen de environment variabelen. Dit is niet zo onder bijvoorbeeld python met uwsgi, maar wel bij CGI applicaties en ook bij php-fpm en apache-mod_php!
• De interne webaanroepen worden gedaan door een applicatie/library die HTTP_PROXY uit de environment gebruikt om de proxy te kiezen. Curl is een tijd geleden gefixt (leest nu http_proxy i.p.v. HTTP_PROXY), maar python-requests leest ’m wel, net als PHP-GuzzleHttp en de Golang builtin http library en vermoedelijk veel meer libraries.

Als aan die voorwaarden voldaan is, kan de aanvaller een Proxy-header toevoegen aan z’n webrequest, waardoor de interne aanroepen via de door de aanvaller gekozen proxy lopen. In het ergste geval krijgt die zo de authenticatiegegevens tussen jouw website en een derde partij — bijvoorbeeld betalingsverwerking — of kan die die data naar hartelust aanpassen — bijvoorbeeld doen alsof een aankoop betaald is.

Proactief de Proxy header te strippen zoals voorgesteld in het document zal bij praktisch als onze klanten een prima oplossing zijn. Wij gebruiken die header nergens actief. In sommige gevallen is dat ook de enige correcte oplossing. We vermoeden dat applicatie-libraries zoals python-requests de weg van curl gaan volgen en de HTTP_PROXY variabele deprecaten. Maar dat is een langzaam proces, dus nu geen oplossing.

Het probleem is overigens ook al gemitigate als je een outbound firewall op je server hebt. Normaal hoeft je server uitgaand nergens bij op poort 80/443, behalve bij je apt-mirror. Hetzelfde geldt voor de andere poorten overigens, je weet waar je DNS en NTP server zit, en bij de rest hoef je niet te zijn, tenzij expliciet gewhitelist.