9. Security Considerations

이 섹션은 개발자, 정보 제공자에게 정보를 제공하기 위한 것이다. HTTP 메시지와 관련된 알려진 보안 고려사항 사용자 구문, 구문 분석 및 라우팅. HTTP에 대한 보안 고려 사항 의미론 및 페이로드는 [RFC7231]에서 다루었다.

9.1 Establish Authority

HTTP는 권위 있는 응답의 개념에 의존한다. 공유 캐시와 같이 권한 없는 소스의 응답을 제공하는 것은 성능과 가용성을 향상시키는 데 유용하지만, 소스가 신뢰할 수 있거나 신뢰할 수 없는 응답을 안전하게 사용할 수 있는 범위까지만 유용하다.

DNS 보안 확장(DNSSEC, [RFC4033])은 신뢰성을 향상시키는 한 가지 방법이다.

"https" scheme(Section 2.7.2)은 협상된 TLS 커넥션이 보안되고 통신 서버의 ID가 대상 URI의 권한 구성 요소와 일치하는지 클라이언트가 적절하게 검증하는 경우, 권한 확립에 대한 이러한 잠재적 공격의 상당수를 방지할 수 있다.

9.2 Risks of Intermediaries

사용자들은 중개자들이 중개자를 운영하는 사람들보다 더 신뢰할 수 없다는 것을 알아야 한다; HTTP 자체는 이 문제를 해결할 수 없다.

9.3 Attacks via Protocol Element Length

HTTP는 대부분 텍스트, 문자 구분 필드를 사용하기 때문에, 파서들은 종종 매우 긴(또는 매우 느린) 데이터 스트림을 전송하는 것에 기반한 공격에 취약하다.

수신자는 요청 메서드, 응답 상태 구문, 헤더 필드 이름, 숫자 값 및 본문 청크를 포함한 기타 프로토콜 요소를 처리하는 범위를 신중하게 제한해야 한다. 이러한 처리를 제한하지 않을 경 우 버퍼 오버플로, 산술 오버플로 또는 denial-of-service 공격에 대한 취약성이 증가할 수 있다.

9.4 Response Splitting

Response splitting (a.k.a, CRLF injection)은 HTTP 메시지 프레임의 line-based 특성과 영속적 커넥션에 대한 응답에 대한 요청의 순서 커넥션을 이용하는 웹 사용에 대한 다양한 공격에 사용되는 일반적인 기술이다[Klein].

9.5 Request Smuggling

Request smuggling([Linhart])은 다양한 수신자 간의 프로토콜 구문 분석의 차이를 이용하여 겉 으로 보기에는 무해한 요청 내에서 추가 요청(다른 경우 정책에 의해 차단되거나 비활성화될 수 있음)을 숨기는 기술이다.

9.6 Message Integrity

9.7 Message Confidentiality

HTTP는 메시지 기밀성이 필요할 때 메시지 기밀성을 제공하기 위해 기본적인 전송 프로토콜에 의존한다.

9.8 Privacy of Server Log Information

HTTP 로그 정보는 본질적으로 기밀이며, 취급은 종종 법과 규정에 의해 제한된다. 로그 정보 를 안전하게 저장하고 분석을 위해 적절한 지침을 따라야 한다.

Previous8. IANA Considerations Next10. Acknowledgedments

Last updated 3 years ago