기본적으로 UnsafeHeaderParsing을 활성화하는 것이 바람직합니까?

Question

이것은 다소 주관적인 질문이지만, 이것을하기위한 찬성/반대 의견을 듣고 싶습니다. Quick and Dirty Feed Parser이라는 오픈 소스 프로젝트를 관리하며 프로젝트의 목적은 가능한 한 원활하게 .NET에서 RSS 및 Atom 피드를 사용하는 것입니다.

내가 프로젝트 초기에 실행 한 문제 중 하나는 내가 테스트 케이스 (즉, Hacker News RSS feed)로 사용했던 피드 중 일부가 부적절하게 형식화 된 HTTP 헤더를 사용하고 .NET의 HttpWebRequest 클래스가 사용되었다는 것입니다. 1.1 이상에서는 GET 요청에서이 헤더 중 하나를받을 때마다 즉시 "안전하지 않은 헤더"예외가 발생합니다.

This change was added in order to put a stop to split-response attacks that were raising security issues at the time .NET 1.1 was released.

내 문제는 - 따라서 "useUnsafeHeader"구성 옵션을 프로그래밍 방식으로 사용할 수 있지만 해당 응용 프로그램의 컨텍스트에서 모든 HttpWebRequests를 통해 수행됩니다. QD 피드 파서가 유효한 피드를 사용할 수 없다는 불만을 제기 한 사용자가 있습니다.이 헤더 문제는 이유입니다.

지금 당장은 라이브러리를 사용하는 개발자가 안전하지 않은 헤더 구문 분석을 사용하도록 설정해야합니다. 대부분의 사람들이 이것이 문제라는 것을 인식하지 못하고 나를 위해 지원 오버 헤드를 생성합니다. .

기본적으로 안전하지 않은 헤더 구문 분석을 사용하도록 설정 한 빠른 피드 및 더티 피드 파서를 사용하면 보안 사용 권한이있는 사용자가 보안 공격을 사용하지 못하게 할 수 있지만 보안 공격에 대해 잘 모르는 사용자는 열지 않습니다. . 여기서 가장 좋은 옵션은 무엇입니까?

Answer 1

"안전하지 않음"은 약간 극단적입니다. 나는이 설정을 다르게 명명했을 것이다. 문제가있는 서버가 HTTP RFC를 정확히 따르지 않는 헤더를 내보낼 때 문제가 발생합니다. 예를 들어 RFC에서는 CR 문자 뒤에 LF 문자가 와야한다고 말합니다. 따라서 LF가 없으면 "안전하지 않은"헤더를 허용하지 않으면 실행을하게됩니다.

실제로 많은 HTTP 클라이언트는 가능한 한 많은 서버와 통신하기 위해 이러한 사소한 위반 사항을 무시합니다. 이것이 브라우저 나 RSS 리더가 "안전하지 않은"헤더에 대해 불평하지 않는 이유입니다. 헤더가 가짜 일지라도 .NET 클라이언트 라이브러리는 강력합니다. 예를 들어, 악의적 인 공격자가 라인 피드를 생략하면 서버를 크래시 할 수 없습니다. :-) 그래서 여기에 큰 안전 문제는 없습니다. 예를 들어 HTML 헤더 이름을 사용하여 벙어리 것들을 HTML (공격자가 HTML에 XSS 공격을 주입 할 수있게 할 수도 있음)에 직접 내보내는 것이 아니라면 말입니다.

HTTP 헤더를 응용 프로그램에 제공되는 다른 사용자가 제출 한 데이터 (예 : 쿼리 문자열, POST 데이터 등)처럼 신뢰할 수없는 것으로 간주하는 한, 확인해야합니다 앱에 '안전하지 않은'헤더를 허용합니다.