PHP, Python 및 기타 웹사이트 애플리케이션은 원격 프록시 취약점(httpoxy)을 노출합니다.

[심천] Yuanchuanghui: 오후 5시 26분, 파티홀이 여러분을 기다리고 있습니다.”

이는 PHP, Go, Python 및 기타 언어의 CGI 애플리케이션을 대상으로 하는 취약점입니다.

httpoxy는 CGI 또는 CGI와 유사한 방식으로 실행되는 애플리케이션에 영향을 미치는 취약점 계열의 이름입니다. 쉽게 말하면 네임스페이스 충돌 문제입니다.

RFC 3875(CGI)는 HTTP 요청 Proxy헤더에서 환경 변수를 직접 채우는 HTTP_PROXY방법을 정의합니다.
HTTP_PROXY발신 에이전트를 구성하는 데 일반적으로 사용되는 환경 변수입니다.

이 결함으로 인해 원격 공격이 가능해졌습니다. PHP 또는 CGI 프로그램을 실행 중인 경우 프록시 헤더를 즉시 차단해야 합니다! 즉시! 구체적인 지침은 아래를 참조하세요. httpoxy는 서버측 웹 애플리케이션 취약점입니다. 이 코드를 서버측에 배포하지 않으면 걱정할 필요가 없습니다.

내 웹 애플리케이션에 이 취약점이 있으면 어떻게 되나요?

이 취약점을 악용하는 HTTP 클라이언트가 요청을 하면 다음을 수행할 수 있습니다.

웹 애플리케이션을 통해 다른 URL에 대한 요청을 프록시합니다.
지정된 원격 주소와 포트를 열도록 서버에 직접 요청
서버 자원을 낭비하고 공격자를 위해 지정된 자원에 접근

httpoxy 취약점은 악용하기가 매우 쉽습니다. 보안 담당자가 가능한 한 빨리 이 취약점을 스캔하고 신속하게 수정하기를 바랍니다.

어떤 것이 영향을 받나요?

보안 취약점은 다음과 같은 상황에서 존재할 수 있습니다.

코드는 HTTP_PROXY실제 또는 시뮬레이션 환경 변수가 되는 CGI 컨텍스트에서 실행됩니다.
HTTP_PROXY프록시 기능을 지원하는 신뢰할 수 있는 HTTP 클라이언트
클라이언트는 요청 내에서 HTTP(또는 HTTPS) 요청을 시작합니다.

다음 상황은 이 결함이 발견된 환경입니다.

언어	환경	HTTP 클라이언트
PHP	php-fpm mod_php	Guzzle 4+ 아르탁스
파이썬	wsgiref.handlers.CGIHandler Twisted.web.twcgi.CGIScript	요청
가다	넷/http/cgi	넷/http

확실히 결함이 확인되지 않은 언어와 환경이 많이 있습니다.

PHP

결함이 존재하는지 여부는 애플리케이션 코드와 PHP 라이브러리에 따라 다르지만 영향은 매우 광범위한 것으로 보입니다.
이 결함이 있는 라이브러리가 사용자 요청을 처리하는 과정에서 사용되는 한 악용될 수 있습니다.
이 결함이 있는 라이브러리를 사용하는 경우 결함은 모든 PHP 버전에 영향을 미칩니다.
- FastCGI 모드로 배포된 HHVM과 같은 대체 PHP 런타임 환경에도 영향을 미칠 수 있습니다.
Guzzle, Artax 등의 라이브러리가 영향을 받는 것으로 확인되었으며, 이 외에도 영향을 받는 라이브러리가 더 많을 수 있습니다.
- Guzzle 4.0.0rc2 이상 버전은 영향을 받고, Guzzle 3 이하 버전은 영향을 받지 않습니다.
- 다른 예로는 Composer의 StreamContextBuilder 유틸리티 클래스가 있습니다.

예를 들어, Drupal에서 Guzzle 6 모듈을 사용하여 아웃바운드 요청(예: 날씨 API 요청)을 시작하는 경우 모듈에서 시작된 요청에는 이 httpoxy 결함이 있습니다.

파이썬

Python 코드는 CGI 모드로 배포할 때만 결함이 있습니다. 일반적으로 결함이 있는 코드는 다음과 같은 wsgiref.handlers.CGIHandlerCGI 컨트롤러를 사용합니다.
- 일반적인 방법으로 배포된 Python 웹 애플리케이션은 영향을 받지 않으므로(대부분의 사람들은 WSGI 또는 FastCGI를 사용하며 이 두 가지는 영향을 받지 않음) PHP보다 영향을 받는 Python 애플리케이션이 훨씬 적습니다.
- os.environ은 CGI 데이터에 의해 오염되지 않으므로 wsgi는 영향을 받지 않습니다.
결함이 있는 요청 라이브러리는 신뢰하고 사용해야 하며 os.environ['HTTP_PROXY']내용 확인을 수행하지 않습니다.

가다

영향을 받으려면 Go 코드를 CGI에 배포해야 합니다. 일반적으로 영향을 받는 코드는 net/http/cgi패키지를 사용합니다.
- Python과 마찬가지로 이는 Go를 웹 애플리케이션으로 배포하는 일반적인 방법이 아닙니다. 그래서 영향을 받는 경우가 거의 없습니다.
- 이에 비해 Go net/http/fcgi패키지는 실제 환경 변수를 설정하지 않으므로 영향을 받지 않습니다.
결함이 있는 버전은 콘텐츠 확인 없이 net/http신뢰되어야 하며 나가는 요청에 사용되어야 합니다.HTTP_PROXY

지금 고쳐

Proxy가장 좋은 해결책은 요청 헤더가 애플리케이션을 공격하기 전에 조기에 차단하는 것입니다. 쉽고 안전합니다.

Proxy요청 헤더는 IETF에서 정의되지 않고 IANA의 메시지 헤더 레지스트리 에도 나열되지 않기 때문에 안전하다고 합니다 . 이는 이 헤더의 사용이 비표준이며 임시적으로 사용되지 않음을 나타냅니다.
표준을 준수하는 HTTP 클라이언트 및 서버는 이 헤더를 읽거나 보내면 안 됩니다.
요청에서 이 헤더를 제거하거나 헤더를 완전히 사용하여 요청을 차단할 수 있습니다.
업스트림에서 패치를 릴리스하지 않으면 이 문제를 직접 해결할 수 있습니다.
- 들어오는 HTTP 요청을 확인하면 결함이 있는 여러 애플리케이션을 한 번에 수정할 수 있습니다.
- 역방향 프록시 및 애플리케이션 방화벽 뒤의 애플리케이션 선별 Proxy요청 헤더는 안전합니다.

요청 헤더를 차단하는 방법은 Proxy구성에 따라 다릅니다. 가장 쉬운 방법은 웹 애플리케이션 방화벽에서 이 헤더를 차단하거나 Apache 및 Nginx에서 직접 차단하는 것입니다. 이를 수행하는 방법에 대한 몇 가지 지침은 다음과 같습니다.

Nginx/FastCGI

다음 문을 사용하여 PHP-FPM 및 PHP-PM에 전달된 요청 헤더를 차단합니다. 이 문은 fastcgi.conf 또는 fastcgi_param(사용하는 구성 파일에 따라 다름)에 배치할 수 있습니다.

fastcgi_param HTTP_PROXY "";

PHP는 FastCGI 모드에서 결함이 있습니다(그러나 Nginx FastCGI를 사용하는 대부분의 다른 언어는 영향을 받지 않습니다).

아파치

Apache 및 Tomcat과 같은 다른 Apache 소프트웨어 프로젝트에 미치는 영향의 구체적인 범위는 Apache Software Foundation의 공식 발표를 참조하는 것이 좋습니다 . 다음은 몇 가지 주요 메시지입니다.

Apache HTTP 서버를 사용하여 mod_cgiGo 또는 Python으로 작성된 스크립트를 실행하면 해당 스크립트가 영향을 받습니다( HTTP_PROXY환경 변수는 "실제"임). mod_phpPHP 스크립트에서 사용되기 때문에 이 결함도 존재합니다.

mod_headers 모듈을 사용하는 경우 Proxy다음 구성을 사용하여 요청을 추가로 처리하기 전에 요청 헤더를 설정 해제할 수 있습니다 .

RequestHeader unset Proxy early

mod_security 모듈을 사용하는 경우 SecRule규칙을 사용하여 요청 헤더가 있는 요청을 거부 할 수 있습니다 Proxy. 다음은 예입니다. SecRuleEngine켜져 있는지 확인하세요. 본인의 상황에 맞게 조절하시면 됩니다.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

마지막으로 Apache Traffic Server를 사용하는 경우 자체에는 영향을 받지 않습니다. 그러나 이를 사용하여 프록시 요청 헤더를 제거하여 그 뒤에 있는 다른 서비스를 보호할 수 있습니다. 자세한 내용은 ASF 지침을 참조하세요 .

HAProxy

다음 구성을 통해 요청 헤더를 제거합니다.

http-request del-header Proxy

광택

이 헤더를 취소하려면 기존 vcl_recv 섹션에 넣으십시오.

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD 중계

이 헤더를 제거하려면 다음 명령문을 사용하십시오. 기존 필터 안에 넣으십시오.

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd （<= 1.4.40）

헤더가 포함된 요청을 반송합니다 Proxy.

다음 내용으로 파일을 만들고 /path/to/deny-proxy.lualighttpd에 대해 읽기 전용으로 만듭니다.

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

lighttpd.conf모듈을 로드 mod_magnet하고 위의 Lua 코드를 실행하도록 수정하세요 .

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (개발 중)

요청에서 Proxy헤더를 제거합니다. 여기 에 다음 명령문을 추가합니다 lighttpd.conf.

req_header.remove "Proxy";

클라이언트 측 PHP 수정은 효과가 없습니다.

결함을 해결할 수 있는 사용자 측 수정 방법은 없으므로 걱정하지 마세요.

을 사용하면 반환된 값에 unset($_SERVER['HTTP_PROXY'])영향을 미치지 않으므로 getenv()쓸모가 없습니다.
사용해 putenv('HTTP_PROXY=')도 효과가 없습니다(putenv는 요청 헤더가 아닌 실제 환경 변수의 값에만 영향을 줄 수 있음)

httpoxy의 역사

이 취약점은 15년 전에 처음 발견되었습니다.

2001년 3월 Randal L. Schwartz는 libwww-perl에서 이 결함을 발견하고 수정했습니다.

2001년 4월 Cris Bailiff는 컬에서 이 결함을 발견하고 수정했습니다.

이 결함은 2012년 7월 Ruby 팀의 Akira Tanaka가 구현 중 발견했습니다 Net::HTTP.HTTP_PROXY

이 결함은 2013년 11월 nginx 메일링 리스트에 언급되었습니다. 발견자인 조나단 매튜스(Jonathan Matthews)는 확신하지 못했지만 그가 옳았다는 것이 밝혀졌습니다.

Stefan Fritsch는 2015년 2월 Apache httpd-dev 메일링 리스트에서 이를 언급했습니다.

이 결함은 2016년 7월 Vend 보안팀의 Scott Geary가 발견했으며, 이는 PHP와 같은 많은 최신 프로그래밍 언어 및 라이브러리에 영향을 미칩니다.

그래서 이 결함은 수년 동안 잠복해 있었고, 많은 사람들이 다양한 측면에서 그 존재를 발견했지만, 그것이 다른 언어와 라이브러리에 미치는 영향을 고려하지 않았습니다. 보안 연구원들은 이 목적을 위해 특별히 웹사이트를 개설했습니다: https://httpoxy.org/ 여기서 자세한 내용을 확인할 수 있습니다.