이중 이스케이프가 위험합니까?

136

/ search / <searchterm>을 통해 물건을 검색 할 수있는 경로가있는 ASP.NET MVC 응용 프로그램이 있습니다.

"search / abc"를 제공하면 잘 작동하지만 "/ search / a + b + c"(올바로 URL 인코딩)를 제공하면 IIS7은 HTTP 오류 404.11로 요청을 거부합니다 ( 요청 필터링 모듈은 이중 이스케이프 시퀀스가 포함 된 요청 ). 우선, 왜 이렇게합니까? URL의 일부이지만 쿼리 문자열의 일부가 아닌 경우에만 오류가 발생하는 것 같습니다 (/ transmit? q = a + b + c는 정상적으로 작동합니다).

이제 web.config의 보안 섹션에서 이중 이스케이프 요청을 활성화 할 수 있지만 그 의미를 이해하지 못하고 서버가 요청 "a + b + c"를 거부하지 않는 이유는 무엇입니까? URL의 일부이지만 쿼리 문자열의 일부로 허용합니다.

누군가 설명하고 조언을 해줄 수 있습니까?

c# asp.net-mvc iis-7

— 알렉스
소스

7

또한 Server.Url Path Encode 를 호출하는 더 올바른 옵션을 시도하고 /search/a%2520b%2520c마크 업으로 끝나서 "위험한 Request.Path 값이 클라이언트에서 감지되었습니다 (%)"오류가 발생했습니다. 당신은 그것을 이길 수 없어 보인다.

— Zhaph-벤 Duguid

158

편집 : 관련 섹션에 강조를 추가했습니다.

기본적으로 IIS는 편집증이 심합니다. uri 디코딩 된 데이터 (예 : 문자열 연결을 통한 로컬 파일 시스템 URI 생성)에 대해 특히 현명하지 않은 작업을 수행하지 않는 경우이 검사를 안전하게 비활성화 할 수 있습니다.

확인을 비활성화하려면 다음을 수행하십시오 ( here ) : (이중 탈출에 대한 내용은 아래의 내 의견 참조).

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true"/>
    </security>
</system.webServer>

더하기 기호가 검색 입력에서 유효한 문자 인 경우 IIS가 URI 경로에서 이러한 입력을 처리 할 수 있도록 "allowDoubleEscaping"을 활성화 해야 합니다.

마지막으로, 해결 방법이 제한되어 있다면 매우 간단합니다. 단순히 '+'를 피하고 대신 '% 20'을 사용하십시오. 어쨌든 공백을 인코딩하기 위해 '+'기호를 사용하는 것은 유효한 URL 인코딩 이 아니라 제한된 프로토콜 세트에만 적용되며 이전 버전과의 호환성을 위해 광범위하게 지원 될 수 있습니다. 정규화 목적으로 만 사용하는 경우 공간을 '% 20'으로 인코딩하는 것이 좋습니다. 그리고 이것은 IIS7 문제를 멋지게 회피합니다 (이는 % 25ab와 같은 다른 시퀀스에서 여전히 발생할 수 있습니다).

— 이몬 네르 본
소스

3

확인을 비활성화합니다. 번거롭고 대부분의 앱에 추가 보안을 제공하지 않습니다.

— Eamon Nerbonne

3

이중 이스케이프를 비활성화하는 것이 안전하다는 링크 / 참조가 있습니까? 또한이 보안 조치로 정확히 어떤 일이 방지됩니까?

— Alex

15

uri가 이중 이스케이프 인 경우, 이스케이프 처리되지 않은 uri 구성 요소는 자체적으로 예약 된 문자를 포함 할 수 있으므로 이스케이프 처리되지 않은 uri 자체는 유효한 URI가 될 수 있습니다. 즉, 이스케이프 처리되지 않은 URI 문자열을 사용하여 새 URI, 특히 파일 시스템 경로를 구성하고 새 경로를 올바르게 이스케이프하지 않으면 경로 삽입을 허용 할 수 있습니다. 경로 주입을 통해 공격자는 프로그램이 속하지 않아야하는 데이터를 처리하도록하거나 실제로 두 개의 URI가 실제로 동일하지만 단순히 다르게 인코딩 될 때 서로 다르다고 생각하도록 혼동 할 수 있습니다.

— Eamon Nerbonne

2

blogs.iis.net/thomad/archive/2007/12/17/…

— VdesmedT

4

@Stijn : 예 : 안전 합니다. 이 모든 검사는 버그가있는 코드로 잘못 해석 될 수있는 요청을 필터링하는 것입니다 (문자열 연결을 통해 그리고 적절한 인코딩없이 Uri를 이중 디코딩 또는 빌드하는 경우 특히). 어떤 종류의 처리도 수행하지 않으므로 사용자가 거의 자동으로 안전합니다. 모든 버그는 IIS의 기본 파일 제공 코드에 있어야하며, 지금까지 매우 철저하게 테스트를 거쳤다 고 가정 할 수 있습니다. 다시 말하지만,이 검사는 환상적이지 않습니다. 디코딩 된 인코딩 된 URI 처럼 보일 수 있습니다 .

— Eamon Nerbonne

2

질문 의 " 무엇을해야할까요 "부분 과 관련된 Eamon Nerbonne의 답변 에 몇 가지 정보 를 추가 하고 싶습니다 (이유를 설명하지 않음). 당신은 쉽게 특정 응용 프로그램의 설정을 변경할 수 있습니다

관리자 권한으로 콘솔 열기 (시작-cmd-마우스 오른쪽 단추 클릭, 관리자 권한으로 실행)
다음을 입력하십시오 ( http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls- 포함 .aspx ) :
```
%windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true
```
(당신은 대체 예 수 YOURSITENAME와를 Default Web Site기본 웹 사이트에이 규칙을 적용하기위한)
준비 됐어요

예를 들면 :

첫째로 같은 문제가있었습니다.
위에서 언급 한 텍스트를 입력 :
이제 예상대로 작동합니다.

— 피터
소스

1

'/ search / a / b / c'와 같은 검색 URL이 있다고 생각하십니까?

당신은 같은 경로를 설정해야합니다

search/{*path}

그런 다음 작업의 경로 문자열에서 검색 값을 추출하십시오.

HTHs
찰스

— 찰리 노
소스

문제는 다른 URL 인코딩 문자 ( '/'자체 포함)가 검색의 일부가 될 수 있다는 것입니다.

— Alex

실제로 검색의 일부인 '/'를 모두 '% 2F'로 인코딩 할 수 없습니까?

— Charlino

0

IIS 7.5에서 응용 프로그램에서 Server.TransferRequest ()를 수행 하여이 문제가 발생했습니다.

파일 이름을 인코딩하면 이중 이스케이프 문제가 발생했지만 인코딩하지 않으면 "잠재적으로 위험한 Request.Path" 오류가 발생합니다.

Server.TranferRequest ()에 전달한 URL에 빈 프로토콜이라도 프로토콜을 넣으면 문제가 해결되었습니다.

작동하지 않습니다 :

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

공장:

context.Server.TransferRequest("://folder/bar%20bar.jpg");

— mhenry1384
소스