요청 필터링 사용 방법

서론

URLScan은 이전 버전의 IIS에 애드-온 형태로 제공되던 보안 도구로 관리자들은 이 도구를 사용해서 웹 서버에 엄격한 보안 정책을 적용할 수 있었습니다. IIS 7에서는 URLScan의 모든 핵심적인 기능들이 요청 필터링이라는 모듈에 병합되었으며 숨겨진 네임스페이스라는 기능이 추가되었습니다. 본문에서는 요청 필터링이 제공하는 각각의 기능들에 대해서 알아보고 여러분의 환경에 적용 가능하도록 실제 상황에서의 예제를 살펴보겠습니다.

이중 인코딩 요청 필터링

기능 개요

이 기능은 이중 인코딩된 요청을 이용한 공격을 방지합니다. 이 시나리오는 공격자가 주의 깊게 만들어진 이중으로 인코딩된 교묘한 요청을 IIS로 전송하는 경우에 적용됩니다. 이런 공격이 발생하면 IIS는 요청이 유효한 경우에만 허용하고 그렇지 않다면 거부할 것입니다. 이 기능이 활성화되면 IIS는 해당 URL을 두 번 디코딩하는데, 만약 첫 번째 디코딩 결과와 두 번째 디코딩 결과가 다르다면 요청은 거부됩니다. 이 기능에 의해 요청이 거부되면 404.11 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 URLScan의 VerifyNormalization 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 서버로 전송되는 이중으로 인코딩된 요청을 결코 허용하지 않기를 원한다고 가정합니다. 이 시나리오를 반영하기 위해서 다음과 같은 구성 설정을 사용할 수 있습니다.

<configuration>
  <system.webServer> 
    <security>
      <requestFiltering allowDoubleEscaping="false" />
    </security>
  </system.webServer>
</configuration>

최상위 비트 설정 문자 필터링

기능 개요

이 기능은 IIS로 전달되는 비 ASCII 문자가 포함된 모든 요청들을 허용할지 또는 거부할지를 결정합니다. 이 기능에 의해서 요청이 거부되면 404.12 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 URLScan의 AllowHighBitCharacters 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 서버 전체에 걸쳐 최상위 비트가 설정된 문자들을 허용하지 않기를 바라지만, 오직 한 응용 프로그램에서는 이를 허용하기 원한다고 가정합니다. 이를 위해서 서버 관리자는 applicationHost.config 파일에는 allowHighBitCharacters="false"를 설정했으며, 비 ASCII 문자를 받아들이기 바라는 응용 프로그램의 루트 아래에는 web.config 파일을 생성했습니다. 다음의 구성 설정이 바로 그 web.config 파일에 사용된 설정입니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering allowHighBitCharacters="true" />
    </security>
  </system.webServer>
</configuration>

파일 확장자에 기반한 필터링

기능 개요

이 기능은 IIS가 서비스 할 수 있는 파일 확장자들의 집합을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.7 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 URLScan의 AllowExtensions 옵션과 DenyExtensions 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 ASP 파일은 서비스되지 않지만 그 외의 모든 파일들은 서비스되기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 allowUnlisted 옵션을 "true"로 설정하고, 명시적으로 서비스되지 않기를 바라는 ASP 파일을 위해 다음과 같은 파일 확장자 항목을 정의합니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <fileExtensions allowUnlisted="true">
          <add fileExtension=".asp" allowed="false" />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

요청 제한에 기반한 필터링

기능 개요

이 기능은 다음 세 가지 기능들의 조합으로 이루어집니다.

• maxAllowedContentLength – Content-Length 요청 헤더값의 최대 크기를 지정합니다.
• maxUrl – 쿼리스트링을 제외한 URL의 최대 길이를 지정합니다.
• maxQueryString – 쿼리스트링의 최대 길이를 지정합니다.

이 기능에 의해서 요청이 거부되면 다음과 같은 오류 코드가 로그에 기록됩니다.

• 404.13 콘텐츠가 너무 큰 경우
• 404.14 URL이 너무 긴 경우
• 404.15 쿼리스트링이 너무 긴 경우

URLScan의 동일한 기능

이 각각의 기능들은 URLScan의 다음 기능들과 동일합니다.

• maxAllowedContentLength
• maxUrl
• maxQueryString

실제 예제

이는 소스 코드에 접근할 수 없는 소프트웨어를 구매하는 기업들에게는 매우 일반적인 상황입니다. 코드에 내제된 취약성이 발견됐을 때, 그 영향을 받는 코드를 갱신하는 것이 매우 어려울 수도 있습니다. 이런 취약성들은 대부분 응용 프로그램으로 전송되는 URL이나 쿼리스트링이 단지 '너무 커서' 또는 '콘텐츠가 너무 많아서' 발생하는 경우가 대부분입니다. 서버 관리자가 안전한 최대값을 결정할 수 있다면, 응용 프로그램의 이진 파일들을 수정하지 않고서도 다음과 같은 구성 설정을 사용해서 그 제한값을 적용할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="30000000" maxUrl="260" maxQueryString="25" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

HTTP 동사 필터링

기능 개요

이 기능은 IIS가 요청으로 받아들일 동사들의 목록을 정의할 수 있게 해줍니다. 이 기능에 의해서 요청이 거부되면 404.6 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 URLScan의 UseAllowVerbs 옵션, AllowVerbs 옵션, 그리고 DenyVerbs 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 오직 하나의 동사, 즉 GET 동사만 허용하기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 먼저 구성 설정 파일에 allowUnlisted="false" 옵션을 설정해서 명시적으로 지정하지 않은 모든 동사를 허용하지 않도록 설정합니다. 그리고, 그 다음에 허용하고자 하는 동사들의 목록을 명시적으로 지정합니다. 이 예제에서는 오직 GET 동사만을 허용합니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <verbs allowUnlisted="false">
          <add verb="GET" allowed="true" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

URL 문자열 시퀀스에 기반한 필터링

기능 개요

이 기능은 IIS가 거부할 문자열 시퀀스의 목록을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.5 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 URLScan의 DenyUrlSequences 옵션의 기능과 동일합니다.

실제 예제

이 기능은 매우 강력합니다. 만약, IIS에 의해 서비스 되지 않기를 바라는 어떤 문자열 시퀀스가 있다면, 그 문자열 시퀀스를 다음과 같이 구성 설정에 추가할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <denyUrlSequences>
          <add sequence=".."/>
        </denyUrlSequences>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration> 

이 예제에서는 '..' 시퀀스를 거부합니다. 그러나, 보다 현실적인 시나리오의 사례는 이미 폐업한 판매자로부터 구매한 응용 프로그램을 갖고 있으며, 특수한 시퀀스의 문자열이 이 응용 프로그램으로 전송되었을 때 문제가 발생할 수 있다는 사실을 발견한 경우입니다. 이 기능을 사용하면 해당 응용 프로그램의 코드를 수정하지 않고서도 단순히 거부 목록에 URL 시퀀스를 추가하는 것만으로 응용 프로그램을 보호할 수 있습니다.

숨겨진 네임스페이스 필터링

기능 개요

이 기능은 '서비스 가능한' 네임스페이스를 (또는 URL 구역을) 정의할 수 있도록 해줍니다. 이 기능에 의해서 요청이 거부되면 404.8 오류 코드가 로그에 기록됩니다.

URLScan의 동일한 기능

이 기능은 IIS 7에서 새롭게 제공되는 기능으로 URLScan에는 존재하지 않습니다.

실제 예제

이해를 돕기 위해서 서버에 다음과 같은 두 개의 URL이 존재하는 경우의 예제를 생각해 보겠습니다.

• http://site.com/bin
• http://site.com/binary

원하는 것은 binary 디렉터리의 콘텐츠들은 서비스를 허용하지만 bin 디렉터리의 콘텐츠들은 서비스를 허용되지 않는 것입니다. 그러나, 만약 URL 시퀀스 필터링 기능을 사용해서 "bin" 시퀀스를 거부하도록 설정한다면 결국 두 URL 모두 거부되고 말 것입니다. 다음과 같은 구성 설정을 사용해서 오직 bin 디렉터리에 대한 접근만을 거부하고 binary 디렉터리 하위에 존재하는 콘텐츠에 대한 접근은 계속해서 허용하도록 지정할 수 있습니다.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <hiddenSegments>
          <add segment="BIN" />
        </hiddenSegments>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

요약

이전 버전의 IIS에서 관리자들은 URLScan을 사용해서 전역적인 수준의 보안 정책을 정의하고 자신들이 관리하는 시스템에 이를 적용할 수 있었습니다. IIS 7에서 관리자들은 전역적인 수준뿐만 아니라 각각의 URL들을 대상으로 동일한 정책을 적용할 수 있게 되었으며, 새롭고 풍부한 기능의 대체 모델이 제공하는 이점들을 이용할 수도 있습니다.

본문에서는 요청이 거부될 때 요청 필터링이 리턴하는 몇 가지 새로운 오류 코드를 살펴봤습니다. 다음은 모든 IIS로그 오류 코드를 정리한 간단한 참조 목록입니다.