0. 개요
HTTP 요청에 들어있는 파라미터가 HTTP 응답헤더에 포함되어 사용자에게 다시 전달될 때,
입력값에 CR이나 LF같은 개행문자가 존재하면 HTTP가 2개 이상으로 분리될 수 있으며
이때 공격자는 개행문자를 이용하여 첫 번째 응답을 종료시키고
두 번재 응답에 악의적인 코드를 주입하여 XSS 및 캐시 훼손(Cache Poisoning)공격 등을 수행할 수 있다.
1. 보안 대책
- 요청 파라키터의 값을 HTTP 응답헤더 (ex: Set-Cookie 등)에 포함시킬 경우 CR, LF와 같은 개행문자를 제거한다.
- 외부 입력 값을 쿠키 및 HTTP 헤더정보로 사용하는 경우, HTTP 응답분할 취약점을 가지지 않도록 필터링하여 사용한다.
2. 진단 방법
- response 헤더에 변수가 사용되는지 확인한다.
- 외부 입력값을 변수로 사용하는지 확인한다.
- 개행문자를 필터링한 후 사용하는지 확인한다.
3. 코드 예시
# 1 - HTTP 응답분할 - 안전하지 않은 코드 예시(JAVA)
* 응답 헤더에는 요청/응답이 생성된 날짜 및 시간, 요청 생성에 사용된 브라우저 및 기타 정보와 같은 요청에 대한 정보, 실제 메시지의 컨텐크 길이, 언어 인코딩 등과 같은 HTTP 본문에 대한 정보가 들어있다.
사용자가 로그인할 때 입력한 아이디는 쿠키에 존재하게 되고 이 외부 입력값이 HTTP 응답헤더에 사용된다.
이때 응답 헤더와 응답 바디를 나누는 부분이 개행문자이기 때문에
위의 코드와 같이 응답 헤더를 개행문자에 대한 필터링 없이 사용하면
공격자가 외부 입력값에 악의적으로 개행문자를 삽입하여 개발자가 의도하지 않은 HTTP 응답문을 삽입할 수 있게된다.
정상적인 경우 | 응답헤더 + 공백 + 응답바디 | |
정상적이지 않은 경우 | 외부 입력값에 아이디 + 공백값 + 거짓된 본문에 대한 정보(본문 데이터가 0이다. 등등) + 공백값 + 새로운 헤더 생성 + 공백값 + 스크립트 형태의 공격 문구 |
응답헤더 + 공백 + 응답헤더 + 공백 + 응답바디(공격) + ... |
따라서 외부 입력값에 대해 개행문자를 필터링하여 취약점을 극복하도록 하자.
# 1 + HTTP 응답분할 - 안전한 코드 예시(JAVA)
외부 입력값에 대해 null 여부를 체크하고, 응답이 여러 개로 나눠지는 것을 방지하기 위해
개행문자를 제거하고 응답헤더의 값으로 사용한다.
4. 해당 취약점 CASE
- 검증없이 입력값을 헤더에 설정할 경우
- 검증없이 입력값을 쿠키에 설정할 경우
#. 참고 블로그
https://prokyhsigma.tistory.com/48?category=848515
'about Security > SECURE CODING' 카테고리의 다른 글
[보안 기능] 취약한 암호화 알고리즘 사용 (4등급) (0) | 2021.08.07 |
---|---|
[입력 데이터 검증 및 표현] 정수형 오버플로우 (4등급) (0) | 2021.08.07 |
[입력 데이터 검증 및 표현] 위험한 형식 파일 업로드 (3등급) (0) | 2021.08.07 |
[캡슐화] 제거되지 않고 남은 디버그 코드 (3등급) (0) | 2021.08.07 |
[보안기능] 중요정보 평문저장 (3등급) (0) | 2021.08.07 |
댓글