URL 내부의 이중 이스케이프 시퀀스 : 요청 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요청을 거부하도록 구성됩니다.

URL 내부의 이중 이스케이프 시퀀스 : 요청 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요청을 거부하도록 구성됩니다.

---

내 ASP.NET MVC 응용 프로그램에서 아래와 같은 URL을 구현하려고합니다.

/ product / tags / for + families

기본 구성으로 애플리케이션을 실행하려고하면 404.11 응답 코드와 함께이 메시지가 표시됩니다.

HTTP 오류 404.11-찾을 수 없음

요청 필터링 모듈은 이중 이스케이프 시퀀스를 포함하는 요청을 거부하도록 구성됩니다.

내 web.config 내에서 아래 코드를 구현하여이 오류를 해결할 수 있습니다.

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

그래서 지금 나는 어떤 404.11.

제가 궁금한 것은이 구현으로 어떤 종류의 보안 허점을 열고 있는지입니다.

BTW, 내 응용 프로그램은 아래 .Net Framework 4.0와에서 실행 IIS 7.5.

---

공개 할 수있는 보안 허점은 HTML 삽입, JavaScript 삽입 또는 SQL 삽입과 같은 코드 삽입과 관련이 있습니다.

기본 설정은 일반적인 주입 전략이 작동하지 않도록하여 반 효율적으로 공격으로부터 사용자를 보호합니다. 더 많은 기본 보안을 제거할수록 URL, GET 요청 쿼리 문자열, POST 요청 데이터, HTTP 헤더 등을 통해 제공된 입력으로 수행 할 작업에 대해 더 많이 생각해야합니다.

예를 들어 다음 id과 같이 작업 메서드 의 매개 변수를 기반으로 동적 SQL 쿼리를 빌드하는 경우 :

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

.NET 전용 보안 제어가 있다고 가정합니다 /product/tags/for+families. /product/tags/for%252Bfamilies앞서 언급 한 보안 제어에 의해 확인되지 않았지만 동일한 리소스 인 요청이 도착 합니다. 인증 된 사용자 요구, SQLi 확인 등과 같은 모든 것이 될 수 있기 때문에 보안 제어라는 일반화 된 용어를 사용했습니다.

IIS가 차단되는 이유는 무엇입니까?

더하기 기호 (+)는 RFC2396에 따라 예약 된 문자입니다 .

많은 URI에는 특정 특수 문자로 구성되거나 구분되는 구성 요소가 포함됩니다. 이러한 문자는 URI 구성 요소 내에서 사용이 예약 된 용도로 제한되기 때문에 "예약 됨"이라고합니다. URI 구성 요소의 데이터가 예약 된 목적과 충돌하는 경우 충돌하는 데이터는 URI를 형성하기 전에 이스케이프되어야합니다.

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

Wade Hilmo는 IIS가 URL에서 문자를 차단하는 방법 이라는 제목의 훌륭한 게시물을 보유하고 있습니다. 많은 정보와 배경이 제공됩니다. 더하기 기호에 해당하는 부분은 다음과 같습니다.

따라서 allowDoubleEscaping / VerifyNormalization은 매우 간단 해 보입니다. 왜 혼란을 일으킨다 고 말 했나요? URL에 '+'문자가 표시되는 경우가 문제입니다. '+'문자는 '%'를 포함하지 않기 때문에 이스케이프 된 것처럼 보이지 않습니다. 또한 RFC 2396은 이스케이프 형식 (% 2b) 일 때 URL에 포함될 수있는 예약 된 문자로 표시합니다. 그러나 allowDoubleEscaping을 기본값 인 false로 설정하면 이스케이프 된 형식에서도 차단됩니다. 그 이유는 역사적입니다. HTTP 초기에는 '+'문자가 공백 문자의 속기로 간주되었습니다. 일부 표준 변환기는 '+'가 포함 된 URL이 주어지면이를 공백으로 변환합니다. 이러한 이유로 '+'는 URL에서 비표준으로 간주됩니다. 이 '+'처리를 호출하는 RFC에 대한 참조를 찾을 수 없었습니다.

내 경험으로 볼 때 IIS가 기록 할 때 요청 공간이 더하기 기호로 대체된다는 것을 알고 있습니다. 이름에 더하기 기호가 있으면 로그를 구문 분석 할 때 혼동을 일으킬 수 있습니다.

해결책

이 문제를 해결하는 세 가지 방법과 더하기 기호를 계속 사용하는 두 가지 방법이 있습니다.

1. allowDoubleEscaping=true-이렇게하면 전체 웹 사이트 / 애플리케이션에 대해 이중 이스케이프가 허용됩니다. 내용에 따라서는 말하지 않는 것이 바람직하지 않을 수 있습니다. 다음 명령이 설정 allowDoubleEscaping=true됩니다.

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

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

   • 요청 제한 : maxContentLength, maxUrl, maxQueryString
   • 동사
   • 쿼리-쿼리 문자열 매개 변수가 확인되지 않습니다.
   • Double Escaping
   • High Bit Characters
   • Request Filtering Rules
   • Request Header Limits

   The following command will add /product/tags/for+families to alwaysAllowedUrls on the Default Web Site.

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

3. Rename - yes, just rename the file/folder/controller/etc. if possible. This is the easiest solution.

---

I have made a work arround for this . so when you want to put the encripted string inside the url for(IIS) you have to clean it from dirty :{ ";", "/", "?", ":", "@", "&", "=", "+", "$", "," }; and when you want to decript it and use it again , you have to make it dirty again before decript it (to get the wanted result) .

Here is my code , i hope it helps somebody :

 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;
        }

---

So I ran into this when I was calling an API from an MVC app. Instead of opening the security hole, I modified my path.

First off, I recommend NOT disabling this setting. It is more appropriate to modify the design of the application/resource (e.g. encode the path, pass the data in a header or in the body).

Although this is an older post, I thought I would share how you could resolve this error if you are receiving this from a call to an API by using HttpUtility.UrlPathEncode method in System.Web.

I use RestSharp for making calls out, so my example is using the RestRequest:

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

This produces a path equal to:

/product/tags/for%2Bfamilies

On another note, do NOT build a dynamic query based on a user's inputs. You SHOULD always use a SqlParameter. Also, it is extremely important from a security perspective to return the values with the appropriate encoding to prevent injection attacks.

~Cheers

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