CRLF 주입 이해: 웹 애플리케이션 취약점 및 완화

홈 » 사이버 보안 » 애플리케이션 보안 » CRLF 주입 이해: 웹 애플리케이션 취약점 및 완화

CRLF(Carriage Return Line Feed) 주입은 공격자가 HTTP 응답에 악성 CRLF 문자를 주입할 수 있을 때 발생하는 웹 애플리케이션 취약점입니다. 이 취약점은 HTTP 헤더 삽입, HTTP 응답 분할, 세션 고정, XSS(교차 사이트 스크립팅), 캐시 중독 등 다양한 보안 문제를 일으킬 수 있습니다.

CRLF 주입을 이해하기 위해 용어를 분석해 보겠습니다.

캐리지 리턴(CR):커서가 현재 행의 처음으로 돌아가도록 지시하는 제어 문자(ASCII 코드 13)입니다.

줄 바꿈(LF):커서가 다음 줄로 이동하도록 지시하는 제어 문자(ASCII 코드 10)입니다.

HTTP의 맥락에서 CRLF는 CR 및 LF 문자("\r\n")의 시퀀스를 나타냅니다. 이러한 문자는 HTTP 프로토콜에서 줄을 구분하는 데 사용됩니다.

CRLF 주입 취약점은 사용자 제어 데이터(입력)가 HTTP 응답 구성에 사용되기 전에 적절하게 삭제되거나 검증되지 않을 때 발생합니다. 공격자는 HTTP 응답을 조작할 목적으로 사용자 입력에 CRLF 문자를 삽입하여 이 취약점을 악용합니다.

CRLF 주입은 다양한 보안 문제를 악용하기 위해 일련의 취약점의 일부로 사용될 수 있습니다. CRLF 주입과 함께 활용할 수 있는 몇 가지 일반적인 체인 취약점은 다음과 같습니다.

CRLF 주입은 부적절한 입력 유효성 검사 또는 안전하지 않은 사용자 입력 연결과 같은 다른 취약점과 결합되어 HTTP 응답 분할 공격을 수행할 수 있습니다. 공격자는 CRLF 문자를 삽입하여 응답 헤더를 조작하고 잠재적으로 응답을 여러 부분으로 분할하여 캐시 중독, 세션 고정 또는 XSS(교차 사이트 스크립팅)와 같은 다양한 보안 문제를 일으킬 수 있습니다.

예:

코드 세그먼트가 HTTP 요청에서 사용자의 이메일 주소를 읽고 이를 HTTP 응답의 쿠키 헤더로 설정하는 다른 예를 고려해 보겠습니다.

이 예에서 애플리케이션은 요청에 제출된 이메일 주소를 가져와 HTTP 응답에서 "user_email"이라는 쿠키로 설정합니다.

요청에 이메일 주소 "[email protected]"이 제출되었다고 가정합니다. 이 쿠키를 포함하는 HTTP 응답은 다음과 같습니다.

입력(“[email protected]”)이 유해한 문자가 없는 유효한 이메일 주소이기 때문에 이 응답은 의도된 형식을 유지합니다.

이제 공격자가 CRLF 문자가 포함된 악성 이메일 주소를 제출하면 어떤 일이 발생하는지 생각해 보겠습니다.

"email" 매개변수의 값은 "john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a"입니다. 애플리케이션이 이 입력을 처리하고 쿠키를 설정하면 HTTP 응답은 다음과 같이 조작될 수 있습니다.

이 경우 공격자는 이메일 매개변수에 CRLF 문자("%0d%0a")를 주입하여 응답에 "Set-Cookie" 헤더를 추가로 삽입했습니다. 공격자는 "true" 값으로 "admin"이라는 또 다른 쿠키를 효과적으로 설정했습니다. 이는 권한 상승이나 기타 보안 관련 공격에 사용될 수 있습니다.

CRLF 주입은 크로스 사이트 스크립팅 공격의 디딤돌로 사용될 수 있습니다. 응답을 조작하기 위해 CRLF 문자를 삽입함으로써 공격자는 다른 사용자의 컨텍스트에서 실행될 수 있는 악성 스크립트를 도입하여 세션 하이재킹, 데이터 도용 또는 기타 형태의 무단 액세스로 이어질 수 있습니다.

예:

CRLF를 XSS(교차 사이트 스크립팅)로 에스컬레이션하는 페이로드를 생성해 보겠습니다.

웹 애플리케이션에서 VAPT(취약성 평가 및 침투 테스트)를 수행하는 동안 잠재적인 CRLF(캐리지 리턴 라인 피드) 취약점을 발견했습니다. 개념 증명을 통해 CRLF 취약점 탐지 및 악용에 대한 설명을 찾아보세요.

주석을 추가하면 불필요한 헤더와 내용이 모두 주석에 포함됩니다. 응답에 Content-Type:text/html 헤더가 있으므로 HTML 주석이 사용됩니다.