url 내의 double excape sequence : 요구 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요구를 거부하도록 설정됩니다.

url 내의 double excape sequence : 요구 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요구를 거부하도록 설정됩니다.

ASP로.NET MVC 어플리케이션에서는 다음과 같은 URL을 구현하려고 합니다.

/product/syslog/for+syslog

디폴트 설정으로 애플리케이션을 실행하려고 하면, 404.11 응답 코드로 다음의 메세지가 표시됩니다.

HTTP 오류 404.11 - 찾을 수 없음

요구 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요구를 거부하도록 설정되어 있습니다.

이 에러를 회피하려면 , Web.config 에 다음의 코드를 실장합니다.

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

저는 지금 것도 있습니다.404.11

제가 궁금한 것은 이 구현으로 인해 어떤 보안상의 구멍이 뚫릴지 궁금하다는 것입니다.

제 나,, b b b b b b b b b b b b b b b b b b b b b b b b b 。.Net Framework 4.0아래를 달리고 있습니다.IIS 7.5.

여는 보안 구멍은 코드 주입(HTML 주입, JavaScript 주입 또는 SQL 주입)과 관련이 있습니다.

기본 설정에서는 일반적인 주입 전략이 작동하지 않도록 하여 공격으로부터 반효율적으로 보호합니다.기본 보안이 삭제될수록 URL, GET 요청 쿼리 스트링, POST 요청 데이터, HTTP 헤더 등을 통해 제공되는 입력에 대해 생각해야 합니다.

들어 SQL을 으로 id액션 메서드의 파라미터는 다음과 같습니다.

public ActionResult Tags(string id)
{
    var sql = "SELECT * FROM Tags Where tagName = '" + id + "'";
    // DO STUFF...
}

(... 이는 권장되지 않습니다)에 의해 설정된 기본 보호입니다.NET 프레임워크에 의해, 유저가 다음의 URL 를 요구하는 등, 보다 위험한 시나리오의 일부가 정지하는 일이 있습니다.

/product/tags/1%27;drop%20table%20Tags;%20--

전체적인 아이디어는 url의 모든 부분과 액션 메서드에 대한 기타 입력을 가능한 위협으로 취급하는 것입니다.기본 보안 설정은 이러한 보호의 일부를 제공합니다.디폴트 시큐러티 설정을 변경할 때마다, 수동으로 처리할 필요가 있는 잠재적인 문제가 조금 더 발생할 가능성이 있습니다.

이런 식으로 SQL 쿼리를 작성하지 않을 것으로 생각합니다.그러나 사용자 입력을 데이터베이스에 저장한 후 나중에 표시할 때 더 교묘하게 처리됩니다.악성 사용자는 인코딩되지 않은 상태로 전송되는 JavaScript 또는 HTML을 데이터베이스에 저장할 수 있으며, 이는 시스템의 다른 사용자를 위협합니다.

보안 리스크

★★allowDoubleEscaping 말은 이 말에만 됩니다.path(cs-uri-stem) 및 OWASP Double Encoding에서 가장 잘 설명됩니다.이 기술은 요청을 두 번 인코딩하는 URL을 통해 보안 제어를 회피하기 위해 사용됩니다.URL을 예로 들어 보겠습니다.

/product/tags/for+families --> /product/tags/for%2Bfamilies --> /product/tags/for%252Bfamilies

보안 해 보겠습니다./product/tags/for+families에 대한 요청이 도착합니다./product/tags/for%252Bfamilies이는 앞서 말한 보안 제어에 의해 체크되지 않은 동일한 리소스입니다.보안 컨트롤의 일반 용어는 인증된 사용자 요구, SQLi 확인 등 모든 것이 될 수 있기 때문에 사용했습니다.

IIS가 차단되는 이유

플러스 기호(+)는 RFC 2396에 따라 예약된 문자입니다.

많은 URI에는 특정 특수 문자로 구성되거나 구분된 구성 요소가 포함되어 있습니다.이러한 문자는 URI 컴포넌트 내에서의 사용이 예약된 목적에 한정되어 있기 때문에 "예약 완료"라고 불립니다.URI 컴포넌트의 데이터가 예약된 목적과 경합하는 경우 URI를 형성하기 전에 경합하는 데이터를 이스케이프해야 합니다.

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |

                "$" | ","

Wade Hilmo는 "IIS가 URL에서 문자를 차단하는 방법"이라는 제목의 훌륭한 게시물이 있습니다.많은 정보와 배경 정보가 제공되고 있습니다.플러스 기호 전용 부품은 다음과 같습니다.

따라서 DoubleEscaping/VerifyNormalization을 허용하는 것은 매우 간단한 것 같습니다.왜 혼동을 일으킨다고 했을까요?이 문제는 URL에 '+' 문자가 표시되는 경우입니다.'+' 문자는 '%'를 포함하지 않으므로 이스케이프되지 않은 것 같습니다.또한 RFC 2396에서는 이스케이프 형식(%2b)일 때 URL에 포함할 수 있는 예약된 문자로 명시되어 있습니다.그러나 allow Double Escaping이 기본값 false로 설정되어 있기 때문에 이스케이프 형식에서도 차단합니다.그 이유는 과거입니다.HTTP의 초창기에는 '+' 문자가 공백 문자의 줄임말로 간주되었습니다.일부 정규화자는 '+'가 포함된 URL을 지정하면 공백으로 변환됩니다.이 때문에, URL 에서는 「+」를 표준이 아닌 것으로 간주하고 있습니다.이 「+」처리를 호출하는 RFC에 대한 참조는 찾을 수 없었습니다만, Web 상에서는 이 「+」처리를 이력 동작이라고 하는 참조가 많이 있습니다.

지금까지의 경험으로 IIS 로그가 기록될 때 요청 공간은 플러스 기호로 대체된다는 것을 알고 있습니다.이름에 플러스 기호가 있으면 로그를 해석할 때 혼란이 발생할 수 있습니다.

솔루션

이를 수정하는 방법에는 세 가지가 있으며 플러스 기호를 사용하는 방법에는 두 가지가 있습니다.

1. allowDoubleEscaping=true- 이렇게 하면 웹 사이트/어플리케이션 전체에서 이중 이스케이프가 가능합니다.내용에 따라서는, 최소한으로 말하면 바람직하지 않을 수도 있습니다.다음 명령어는 다음과 같이 설정합니다.allowDoubleEscaping=true.

   appcmd.exe set config "Default Web Site" -section:system.webServer/security/requestFiltering /allowDoubleEscaping:True
   

2. alwaysAllowedUrls- 요청 필터링은 화이트리스트 접근 방식을 제공합니다.이 URL 경로를 항상 에 추가함으로써AllowedUrls. 요청은 다른 요청 필터링 설정에 의해 확인되지 않고 IIS 요청 파이프라인에서 계속됩니다.여기서 우려되는 점은 요청 필터링이 다음 항목에 대한 요청을 확인하지 않는다는 것입니다.

• 요구 제한: max Content Length, max Url, max Query String
• 동사들
• 쿼리 - 쿼리 문자열 매개 변수가 확인되지 않습니다.
• 더블 이스케이프
• 고비트 문자
• 요구 필터링 규칙
• 요청 헤더 제한

다음 명령어는 다음을 추가합니다./product/tags/for+families로.alwaysAllowedUrls를 참조하십시오.

    appcmd.exe set config "Default Web Site" -section:system.webServer/security/requestFiltering /+"alwaysAllowedUrls.[url='/product/tags/for+families']"

3. 이름 변경 - 가능한 경우 파일/폴더/컨트롤러 등의 이름을 변경합니다.이것이 가장 쉬운 해결책입니다.

이것을 위해 작업을 했습니다.따라서 (IIS)의 URL에 괄호 문자열을 넣고 싶을 때는 더티:{;", "/", "?", ":", "@", "=", "+", "$", "}"를 청소하고 싶을 때는 다시 더티로 만들어 사용해야 합니다.

여기 제 코드가 있습니다.누군가에게 도움이 되었으면 합니다.

 public static string cleanUpEncription(string encriptedstring)
        {
            string[] dirtyCharacters = { ";", "/", "?", ":", "@", "&", "=", "+", "$", "," };
            string[] cleanCharacters = { "p2n3t4G5l6m","s1l2a3s4h","q1e2st3i4o5n" ,"T22p14nt2s", "a9t" , "a2n3nd","e1q2ua88l","p22l33u1ws","d0l1ar5","c0m8a1a"};

            foreach (string dirtyCharacter in dirtyCharacters)
            {
                encriptedstring=encriptedstring.Replace(dirtyCharacter, cleanCharacters[Array.IndexOf(dirtyCharacters, dirtyCharacter)]);
            }
            return encriptedstring;
        }

        public static string MakeItDirtyAgain(string encriptedString)
        {
            string[] dirtyCharacters = { ";", "/", "?", ":", "@", "&", "=", "+", "$", "," };
            string[] cleanCharacters = { "p2n3t4G5l6m", "s1l2a3s4h", "q1e2st3i4o5n", "T22p14nt2s", "a9t", "a2n3nd", "e1q2ua88l", "p22l33u1ws", "d0l1ar5", "c0m8a1a" };
            foreach (string symbol in cleanCharacters)
            {
                encriptedString = encriptedString.Replace(symbol, dirtyCharacters[Array.IndexOf(cleanCharacters,symbol)]);
            }
            return encriptedString;
        }

암호화된 문자열을 구분하여 인코딩합니다.

return HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes("string"));

암호화된 문자열을 구분하여 디코딩합니다.

string x = Encoding.UTF8.GetString(HttpServerUtility.UrlTokenDecode(id));

MVC 앱에서 API를 호출하다가 우연히 알게 되었습니다.보안 구멍을 여는 대신 경로를 수정했습니다.

우선, 이 설정을 무효로 하지 않는 것을 추천합니다.애플리케이션/리소스의 설계를 변경하는 것이 보다 적절합니다(예: 경로 인코딩, 헤더 또는 본문 내 데이터 전달).

오래된 글이지만 Http Utility를 사용하여 API 호출에서 이 오류를 해결할 수 있는 방법을 공유하려고 합니다.시스템의 UrlPathEncode 메서드.웹.

콜 발신에는 RestSharp 를 사용하고 있기 때문에, 이 예에서는 RestRequest 를 사용하고 있습니다.

var tags = new[] { "for", "family" };
var apiRequest = new RestRequest($"product/tags/{HttpUtility.UrlPathEncode(string.Join("+", tags))}");

그러면 다음과 같은 경로가 생성됩니다.

/제품/태그/%2 패밀리

또한 사용자의 입력을 기반으로 동적 쿼리를 작성하지 마십시오.항상 SqlParameter를 사용해야 합니다.또, 시큐러티의 관점에서는, 주입 공격을 막기 위해서, 적절한 인코딩으로 값을 반환하는 것이 매우 중요합니다.

언급URL : https://stackoverflow.com/questions/7739233/double-escape-sequence-inside-a-url-the-request-filtering-module-is-configured