퍼센트 로그인 URL (/ %)로 IIS 요청을 올바르게 처리

/programming//% 및 http://bing.com/% 와 같은 IIS 요청을 올바르게 가져와 400 잘못된 요청 페이지를 표시하지 않지만 사용자 정의 오류 페이지를 표시하는 모든 종류의 솔루션을 찾고 있습니다 . http://google.com/% 및 http://facebook.com/%의 방식과 유사합니다 (이러한 예제는 IIS에 있지 않음).

http://support.microsoft.com/kb/820129에 따라 적용 가능한 모든 http.sys 레지스트리 설정 (AllowRestrictedChars, PercentUAllowed)을 설정하려고 시도했지만 도움이되지 않았습니다. AllowRestrictedChars 및 사용자 정의 400 페이지를 설정하면 /programming//%12 와 같은 고정 URL이 있지만 / %는 아닙니다.

IIS 커널 수준에서 바로 차단됩니다. 테스트 로 IIS의 모든 모듈을 꺼내서 정적 페이지 처리기가 없었으며 여전히 400 오류 메시지가 표시되었습니다.

IIS를 사용하여 해결할 수 있다고 생각하지 않습니다. 언급 한 레지스트리 설정은 다른 유형의 제한된 문자를위한 것입니다. 그 기능을 바꿀 수있는 수단을 보지 못했습니다.

당신의 목표는 그것을 피하는 것입니까? 공격 범위가 넓어졌으며 불완전한 URL 이스케이프 시퀀스를 차단하여 합법적 인 방문자가 손실되는 것을 상상할 수 없습니다.

업데이트 2 : 여기에 세 가지 훌륭한 링크가 있습니다. IIS 팀의 Nazim Lala와 Wade Hilmo는 귀하의 질문에 대한 토론으로 이에 대해 블로그를 작성했습니다. 또한 Scott Hanselman은 .NET의 querystring 부분에 대한 훌륭한 게시물을 보유하고 있습니다.

• IIS에서 특수 문자 사용 -Nazim Lala
• IIS가 URL에서 문자를 차단하는 방법 -Wade Hilmo
• 악취 실험-Scott Hanselman

업데이트 : 나는 정식 답변을 얻기 위해 IIS 팀원과 확인했습니다. 그는 RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ) 에 따르면 %는 안전하지 않은 문자로 간주됩니다 .

관련 텍스트는 다음과 같습니다.

위험한:

여러 가지 이유로 문자가 안전하지 않을 수 있습니다. 공백 문자는 유효하지 않은 공백이 사라지고 URL이 전사되거나 조판되거나 워드 프로세싱 프로그램의 처리를받을 때 중요하지 않은 공백이 생길 수 있으므로 안전하지 않습니다. "<"및 ">"문자는 자유 텍스트에서 URL 주위의 구분자로 사용되므로 안전하지 않습니다. 따옴표 ( "" ")는 일부 시스템에서 URL을 구분하는 데 사용됩니다."# "문자는 안전하지 않으며 월드 와이드 웹 및 다른 시스템에서 조각 / 앵커에서 URL을 구분하는 데 사용되므로 항상 인코딩해야합니다 식별자 그게 따를 수 있습니다. 그것은 다른 문자를 인코딩하는 데 사용됩니다 때문에 문자 "%가"안전하지 않은 것입니다. 게이트웨이 및 기타 전송 에이전트가 때때로 이러한 문자를 수정하는 것으로 알려져 있기 때문에 다른 문자는 안전하지 않습니다. 이러한 문자는 "{", "}", "|", "\", "^", "~", "[", "]"및 "`"입니다.

안전하지 않은 모든 문자는 항상 URL 내에 인코딩해야합니다. 예를 들어, 일반적으로 조각 또는 앵커 식별자를 처리하지 않는 시스템의 경우에도 "#"문자를 URL 내에 인코딩해야합니다. 따라서 URL을 사용하는 다른 시스템에 URL을 복사 할 경우 문자를 변경할 필요가 없습니다. URL 인코딩

따라서 IIS는 공격 수준을 최소화하기위한 사전 보안 조치 인 코어 수준에서이를 사전에 차단합니다.

가능한 3 가지 방법을 생각할 수 있습니다

1. 일반적으로 발생하는 것보다 400 오류에 대한 사용자 지정 페이지를 가리 키도록 IIS 변경

2. 이것이 IIS의 특정 웹 사이트에 고유 한 경우 web.config에서 다음과 같이 할 수 있습니다.

   <customErrors defaultRedirect = "ErrorPage.aspx"mode = "On">
   <error statusCode = "400"redirect = "myCustom400Error.aspx"/>
   </ customErrors>

3. 들어오는 URL을 검사하고 처리하는 httpModule을 작성하십시오.

이 문제를 해결하는 유일한 방법은 IIS 커널보다 URL을 확인하는 것처럼 들립니다.

최종 사용자를 해당 URL로 전달하기 전에 스크립트를 통해 동적으로 생성 된 링크를 보내 링크를 확인해야합니다 ...

이를 막기 위해, 이것이 IIS가 원하는 방식으로 처리하지 못하는 유일한 상황이라는 것을 알고 있습니다. 따라서 제거 과정에서 처리되지 않은 요청이 있으면 그 원인을 알 수 있습니다.

맞춤 400 페이지에서 리퍼러를 확인하면 트래픽 소스를 좁히는 데 도움이됩니까?

IIS 포럼 의이 게시물 은 HTTP 400 (잘못된 요청)이 http.sys에 의해 차단되었으며 @Scott Forsyth-MVP가 원래 답변에 포함시킨 링크와 일치하는 IIS로 만들지 않음을 나타냅니다.

c : \ Windows \ System32 \ LogFiles \ HTTPERR \에서 이러한 요청의 로그를 볼 수 있습니다.

이러한 종류의 오류에 대해 사용자에게 다시 전송되는 응답 페이지를 구성 할 수 있는지 모르겠지만 Bing 조차도이 문제로 고통 받고 있기 때문에 불가능하거나 일부 시스템 해킹이 필요하다고 생각합니다.