curl의 저자 Daniel은 23.9년 된 curl의 DOS 익스플로잇에 대해 블로그 에 글을 남겼습니다.
1998년 10월에 curl 4.9가 출시되었으며, curl 4.9는 HTTP 쿠키를 수신하고, 구문 분석하고, 후속 요청에서 쿠키를 올바르게 반환할 수 있는 "쿠키 엔진"이 있는 첫 번째 버전이었습니다.
물론 당시 curl의 청중은 적었고 curl 웹사이트에서 curl 버전 4.9가 300 다운로드에 도달했다고 발표한 것은 몇 달 후였습니다. 그리고 당시에는 쿠키에 대한 명확한 사양이 없었습니다. 쿠키가 작동하는 방식을 설명 하는 사양 은 Netscape 의 cookie_spec.
그 후 IETF(Internet Engineering Task Force)는 쿠키 사양을 만들기 위해 열심히 노력했지만 대부분 실패했습니다. 쿠키는 약간 특별하기 때문에 다양한 작성자, 코드베이스 및 웹사이트에 의해 구현되어 "하향식 사양"이 작동하는 방식을 근본적으로 변경합니다.
쿠키 RFC 6265 가 2011년에 게시 될 때까지 이것은 쿠키가 무엇이며 따라야 하는 내용을 설명하는 실제 쿠키 사양입니다. 그러나 이것은 또한 몇 가지 질문을 제기합니다. RFC 6265는 서버가 쿠키를 보내는 방법에 대한 필드 구문 과 클라이언트가 쿠키를 수락하는 매우 다른 구문을 제공합니다. 이중 구문은 두 가지 문제를 야기합니다.
- 구문 중 하나에 빠져서 구문이 모든 사용 사례에 유효하다고 가정하기 쉽기 때문에 사양을 읽기가 어렵습니다.
- 클라이언트가 실제로 쿠키를 수신하고 처리하는 방법을 결정하기 때문에 쿠키 전송 구문을 정의하는 것은 거의 사용되지 않습니다. 브라우저와 같은 기존의 대형 쿠키 파서는 허용하는 콘텐츠 형식이 상당히 자유로우며 서버가 RFC 사양의 구문을 따르는지 여부에 아무도 관심을 기울이지 않습니다.
쿠키는 시간이 지남 에 따라 계속 천천히 발전해 왔지만 HTTP 사양은 지난 수십 년 동안 여러 번 업데이트되었습니다. 게다가 HTTP 서버 구현은 더 엄격한 구문 분석 정책을 구현했습니다. 들어오는 HTTP 요청이 "불법"이거나 형식이 잘못된 것으로 보이면 HTTP 서버가 이를 조기에 거부하기 시작합니다. 이제 제어 코드가 있는 요청을 새 HTTP 서버로 보내려고 하면 서버는 요청을 거부하고 400 응답 코드를 반환합니다.
23살 버그
2022년 6월 말, curl은 curl과 관련된 의심스러운 보안 문제에 대한 보고를 받았으며, 이로 인해 curl이 CVE-2022-35252 를 발행했습니다 .
1998년 curl 쿠키 코드는 제어 코드가 포함된 쿠키를 허용하는 것으로 나타났습니다 . 제어 코드는 이름이나 콘텐츠의 일부일 수 있으며 사용자가 "쿠키 엔진"을 활성화하면 curl은 이러한 쿠키를 저장하고 후속 요청에서 반환합니다. 예를 들어:
쿠키 설정: name^a=content^b; 도메인=.example.com
^a 및 ^b는 제어 코드, 바이트 코드 1 및 2를 나타냅니다. 도메인이 쿠키를 다른 호스트로 표시할 수 있기 때문입니다. 따라서 쿠키는 도메인 내의 모든 호스트에 대한 요청에 포함됩니다. curl이 이러한 쿠키를 HTTP 서버에 보낼 때 나가는 요청에 다음과 같은 헤더 필드를 포함합니다.
쿠키: 이름^a=내용^b
반면 기본 구성된 서버는 400으로 응답합니다. 이러한 쿠키를 수신하는 스크립트 또는 응용 프로그램의 경우 쿠키가 계속 전송되는 한 추가 요청이 거부되어 서비스 거부 DOS 공격이 생성됩니다.
이 취약한 쿠키 코드는 버전 4.9(curl 프로젝트의 201일째)부터 curl에 있었고 버전 7.85.0(curl 프로젝트의 8930일째)까지 수정되지 않았으며, 그 사이에 8729일이 걸렸습니다(23.9년).
물론 다니엘에 따르면 이러한 쿠키 코드는 문제 없이 출시되었으며 대부분의 사용자 시간 동안 문제 없이 사용되었습니다. (내 머리를 찾지 않고는 내 냄비가 아닙니다) . 그리고 최신 버전의 curl은 RFC 6265bis 의 최신 초안 버전을 완전히 준수했습니다 .