it-gundan.com

HTTP 메소드를 이용하는 방법

nikto , nessus , nmapw3af 와 같은 많은 보안 스캐너가 HEAD, GET과 같은 특정 HTTP 메소드를 표시하는 경우가 있습니다. , POST, PUT, DELETE, TRACE, OPTIONS, CONNECT 등은 공격에 취약합니다.

이 헤더는 무엇을하며 어떻게 활용 될 수 있습니까?

POST 또는 GET 주입 (예 : 필드 변경)과 같은 일반적인 익스플로잇보다 더 창의적인 것을 찾고 있습니다. 귀하의 답변에 일반적인 사용법의 간단한 예가 나와 있는지 이해하는 데 도움이 될 것입니다 헤더의 익스플로잇 기술과 비교 한 헤더.

58
Digital fire

이러한 방법 중 일부는 일반적으로 노출하기에 위험하며 일부는 프로덕션 환경에서 불필요하며 추가 공격 영역으로 간주 될 수 있습니다. 그래도 필요하지 않기 때문에 차단할 가치가 있습니다.

  • HEAD, GET, POST, CONNECT-이것들은 적어도 HTTP Method 자체만큼 안전합니다. 물론, 요청 자체에는 악성 매개 변수가있을 수 있지만 메소드와는 별개입니다.이 매개 변수는 일반적으로 사용하도록 설정해야하는 유일한 매개 변수입니다 (아래 예외는 예외).
  • PUT, [email protected]이 언급했듯이 이러한 방법은 원래 파일 관리 작업으로 사용되었습니다.
    일부 웹 서버는 여전히 원래 형식으로 이들을 지원합니다. 즉, 서버의 파일 시스템에서 파일을 임의로 변경하거나 삭제할 수 있습니다. 분명히, 이것이 활성화되면 위험한 공격에 노출됩니다.
    파일 접근 권한은 very 엄격하게 제한되어야합니다. 이러한 방법을 반드시 활성화해야합니다. 그러나 어쨌든 요즘에는 필요한 경우이 기능을 지원하기 위해 사용할 수있는 간단한 스크립트가 있습니다 (정적 웹 사이트 인 경우 실제 응용 프로그램 인 경우 직접 코딩하십시오).
    참고 : 이러한 방법 (PUT 및 DELETE)을 활성화하는 유효한 시나리오는 RESTful API 또는 서비스를 엄격하게 개발하는 경우입니다. 그러나이 경우 메소드는 웹 서버가 아닌 애플리케이션 코드에 의해 처리됩니다.

  • 옵션-이것은 진단 방법으로, 주로 디버깅 등에 유용한 메시지를 반환합니다. 이 메시지는 기본적으로 웹 서버에서 활성화 된 HTTP 메소드를보고합니다. 실제로, 이것은 오늘날 합법적 인 목적으로 거의 사용되지 않지만, 잠재적 인 공격자에게 little 약간의 도움을줍니다 : 다른 구멍을 찾는 지름길로 간주 될 수 있습니다.
    이제 그 자체로는 실제로 취약점이 아닙니다. 그러나 실제로 사용하지 않기 때문에 공격 영역에 영향을 미치며 이상적으로는 비활성화해야합니다.
    참고 : 위의 내용에도 불구하고 OPTIONS 방법 IS 오늘날 몇 가지 합법적 인 목적으로 사용됩니다. 예를 들어 some REST API에는 OPTIONS 요청이 필요합니다. CORS 비행 전 요청 등이 필요하므로 OPTIONS를 활성화해야하는 시나리오가 있지만 기본적으로 "필요하지 않으면 비활성화"해야합니다.

  • TRACE-이것은 놀라운 것입니다 ... 다시 말하지만, @Jeff가 언급 한 진단 방법은 응답 본문에서 전체 HTTP 요청을 반환합니다. 여기에는 요청 본문뿐만 아니라 요청 헤더도 포함됩니다 (예 : 쿠키, 인증 헤더 등.
    놀랄 일도 아니지만, 고전적인 XST (Cross-Site Tracing) 공격과 같이 잘못 사용될 수 있습니다. 여기서 XSS 벡터는 HttpOnly 쿠키, 권한 부여 헤더, 등. definitely 비활성화해야합니다.

  • ALL OTHERS 를 언급하는 다른 방법 세트가 있습니다. 일부 웹 서버의 경우 특정 HTTP 메소드를 활성화/비활성화/제한하려면 구성 파일에서 명시 적으로 설정하십시오. 그러나 기본값을 설정하지 않으면 웹 서버에서 구현 한 특정 액세스 제어를 무시하고 추가 방법을 "주입"할 수 있습니다. 예를 들어 OWASP에 대한 추가 정보 를 참조하십시오.

46
AviD

PUT 방법을 사용하면 서버의 모든 파일을 업로드 할 수 있습니다. XSS (Cross Site Scripting)를 수행하는 데 사용할 수 있습니다. 오늘 저는이 공격을 수행 했으므로 여기에 내 경험으로 답장을 보내십시오. 이를 수행하는 방법은 아래에 설명되어 있습니다.

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here) 

서버는“파일이 성공적으로 생성되었습니다”라는 201 상태 코드로 응답합니다.

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

이제 업로드 된 XSS.html 파일을 브라우저에서 액세스 할 수 있습니다. 이 페이지에 액세스하자마자 XSS 팝업이 표시됩니다.

마찬가지로, 이것은 아직 시도하지 않았지만 Command Injection을 수행하기 위해 추가로 악용 될 수 있습니다. 응용 프로그램이 XML을 사용하는 경우 XML 외부 엔터티 공격도 수행 할 수 있습니다. Havent도 아직이 작업을 수행했습니다. 디렉토리 탐색 공격도 가능합니다.

4
Dan Rad

TRACE에 대한 주요 경고는 traceroute가 패킷의 라우팅을 분리하는 방식과 유사한 HTTP 요청의 라우팅을 분리하도록 설계되었다는 것입니다. 중요한 차이점은 TRACE 명령에는 백엔드 작업과 수신 한 내용의 공개가 포함된다는 것입니다. 프론트 엔드가 API 키 또는 백엔드와 유사한 것을 제공하는 경우 문제가 될 수 있습니다.

TRACE에 대한 자세한 내용과 다른 헤더에 대한 설명은 RFC 2616 을 참조하십시오.

3
Jeff Ferland