반응형

 

Cross-Site Scripting

 

Cross-site scripting (XSS) attacks exploit vulnerabilities in Web page validation by injecting client-side script code. Common vulnerabilities that make your Web applications susceptible to cross-site scripting attacks include failing to properly validate input, failing to encode output, and trusting the data retrieved from a shared database. To protect your application against cross-site scripting attacks, assume that all input is malicious. Constrain and validate all input. Encode all output that could, potentially, include HTML characters. This includes data read from files and databases.

 

게시판이나 웹 메일 등에 악의적인 스크립트를 삽입하여 비정상적인 페이지가 보이게 해 타 사용자의 사용을 방해하거나 쿠키 및 기타 개인정보를 특정 사이트로 전송하는 등의 공격

Ref: http://msdn.microsoft.com/en-us/library/ms998274.aspx

 

XSS는 다음과 같은 공격을 가능 하게 한다.

- 쿠키 절도, 계정 하이재킹으로 이어질 수 있는 세션 쿠키의 절도를 포함

- 피해 웹 사이트 / 어플리케이션에 대한 키 입력의 감시

- 웹사이트에서 특정 사용자인 것처럼 행동. 가령 Window Live Mail에 대한 한 XSS 공격은 공격자가 이메일을 읽고 전달할 수 있으며, 새로운 일정을 설정할 수 있습니다.

 

IE 8 자체 XSS 필터

XSS 필터 - 동작 원리

XSS 필터는 브라우저를 통하는 모든 요청 / 응답을 들여다 볼 수 있는 IE8 구성 요소로서 동작합니다. 필터가 크로스-사이트 요청에서 XSS처럼 보이는 것을 발견한 경우, 필터는 그 공격을 확인하여 만일 서버의 응답에서 그것이 다시 발견되면 무력화합니다. 사용자에게 물어보거나 하지는 않습니다. IE는 단순히 악의적인 스크립트의 실행을 차단합니다.

 

브라우저에 다음 처럼 주소를 입력 한다.

http://www.google.co.kr/search?complete=1&hl=ko&q=xss&btnG=Google+%EA%B2%80%EC%83%89&lr=&aq=<script>alert('hello');</script>

 

아래 IE 8 자체 XSS 필터가 적용 된 화면이다.

 

 

Ref: http://blogs.msdn.com/ie8kr/archive/2009/03/17/ie8-4-xss.aspx

 

MSDN에도 소개 되어 있듯이 XSS를 방지 하는 가장 중요한 대응 책은 다음 두 가지 이다.

  • Constrain input. (입력 값 검사)
  • Encode output. (출력 값 Encode)

 

How To: Prevent Cross-Site Scripting in ASP.NET(http://msdn.microsoft.com/en-us/library/ms998274.aspx) 를 살펴 보면 아래와 같이 Cross-Site Scripting을 방지 하는 다섯 가지 Step을 소개 한다.

  • Step 1. Check that ASP.NET request validation is enabled.
  • Step 2. Review ASP.NET code that generates HTML output.
  • Step 3. Determine whether HTML output includes input parameters.
  • Step 4. Review potentially dangerous HTML tags and attributes.
  • Step 5. Evaluate countermeasures.

 

1.     Check That ASP.NET Request Validation Is Enabled

( ASP.NET Request 검사가 활성화 되어 있는지 확인 하라 )

예제 페이지: RequestValidationEnabled.aspx

Web.config

<pages validateRequest="false" enableSessionState="false">

<pages validateRequest="true" enableSessionState="false">

 

필요 시 개별 페이지에 ValidateRequest 속성을 false로 줍니다.

개별 페이지

<%@ Page Language="C#" ValidateRequest="false" %>

 

2.     Determine Whether HTML Output Includes Input Parameters

(입력 파라미터에 HTML 출력 값이 포함 될지 여부를 결정 하라)

예제 페이지: HTMLOutputIncludesInputParameters.aspx

 

3.     Review Potentially Dangerous HTML Tags and Attributes

HtmlEncode to ensure the inserted text is safe.

(삽입 될 텍스트의 안전함이 보장 될 수 있도록 잠재적으로 위험한 HTML 태그나 속성을 HTML Encode 하는 것을 확인 하라.)

예제 페이지: DangerousHTMLTagsAndAttributes.aspx

-      Potentially Dangerous HTML Tags

(잠재적으로 위험한 HTML 태그)

<applet>  <body>  <embed>  <frame> <script> <frameset> <html> <iframe> <img> <style> <layer> <link>  <ilayer> <meta>  <object>

 

이러한 태그를 통하여 다음처럼 공격에 이용된다.

<img src="javascript:alert('hello');">

<img src="java&#010;script:alert('hello');">

<img src="java&#X0A;script:alert('hello');">

<style TYPE="text/javascript">

  alert('hello');

</style>

 

4.     Use the HttpOnly Cookie Option

(HttoOnly 쿠키 옵션을 사용 하라)

Internet Explorer 6 Service Pack 1 and later supports an HttpOnly cookie attribute, which prevents client-side scripts from accessing a cookie from the document.cookie property.

Instead, the script returns an empty string. The cookie is still sent to the server whenever the user browses to a Web site in the current domain.

The System.Net.Cookie class in Microsoft .NET Framework version 2.0 supports an HttpOnly property. The HttpOnly property is always set to true by Forms authentication.

Earlier versions of the .NET Framework (versions 1.0 and 1.1) require that you add code similar to the following to the Application_EndRequest event handler in your application Global.asax file to explicitly set the HttpOnly attribute.

( 인터넷 익스플로러 서비스팩 1 이후 버전 부터 HttpOnly 속성을 지원한다. 이 속성은 document.cookie 속성과 같이 클라이언트 단 스크립트로 쿠키에 접근 하는 것을 방지 한다. 이 속성을 사용 하면 스크립트는 쿠키 값 대신 공백 문자열을 반환 한다. 쿠키는현재 도메인 하에  여전히 사용자 브라우저에서 서버로 전송 된다.  .NET Framework  2.0부터 System.Net.Cookie 클래스는 HttpOnly 속성을 지원한다. 또한 폼 인증 쿠키는 항상 HttpOnly 속성 값이 true로 설정 된다. 1.0, 1.1과 같은 초기 버전의 .NET Framework에서는 Global.asax 파일의 Application_EndRequest 이벤트 핸들러에 유사한 코드를 추가 함으로써 명시적으로  HttpOnly 속성을 지정 할수가 있었다. 코드는 아래와 같다.)

 

protected void Application_EndRequest(Object sender, EventArgs e)

    {

        //.NET 2.0은 기본적으로 속성 True

        // 아래 코드는 1.1 이하 코드에서

        string authCookie = FormsAuthentication.FormsCookieName;

        foreach (string sCookie in Response.Cookies)

        {

            if (sCookie.Equals(authCookie))

            {

                Response.Cookies[sCookie].Path += ";HttpOnly";

            }

        }

    }

 

 

또한 사용자 데이터를 쿠키에 담고 싶다면 다음 처럼 FormsAuthenticationTicket 을 생성 할때 사용자 데이터를 넘겨 인증 쿠키에 추가 한다. 이렇게 처리 하면 기본적으로 HttpOnly 속성이 쿠키에 할당 될 뿐 아니라 개발자가 해당 데이터를 암호화 할 필요가 없다.

 

 

  StringBuilder userData = new StringBuilder();

  userData  = 필요한 데이터를 할당 한다.;

 

            FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, member.MemberGuid, DateTime.Now, DateTime.Now.AddMinutes(300), false, userData.ToString());

 

            string encTicket = FormsAuthentication.Encrypt(ticket);

 

            HttpContext.Current.Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket));

  

 

인증 쿠키에 할당 된 사용자 데이터는 다음 처럼 가져 온다.

 

 

 if (HttpContext.Current.Request.IsAuthenticated)

 {

            FormsIdentity id = (FormsIdentity)HttpContext.Current.User.Identity;

            FormsAuthenticationTicket ticket = id.Ticket;

            string memberData = ticket.UserData.;

 

 

5.     Use the <frame> Security Attribute (frame에 Security 속성을 사용 하라)

Internet Explorer 6 and later support a new security attribute for the <frame> and <iframe> elements. You can use the security attribute to apply the user's Restricted Sites Internet Explorer security zone settings to an individual frame or iframe. By default, the Restricted Sites zone does not support script execution.

If you use the security attribute, it must be set to "restricted" as shown in the following.

(IE 6을 포함 한 이후 버전에는 frameiframe 개체에 security 속성을 지원 한다. 이 security 속성을 사용 하여 각각의 frame 과 iframe에 사용자 제한 적인 보안 영역을 설정 할 수 있다. 기본값으로 이 제한된 사이트 영역은 스크립트 실행을 제한한다.  security 속성을 사용 하기 위해서는 아래 처럼  속성 값을 "restricted" 로 설정 하여야 한다.)

<frame security="restricted" src="http://www.somesite.com/somepage.htm"></frame>

 

 

AntiXssLibrary 적용

http://msdn.microsoft.com/en-us/library/aa973813.aspx

 

The Microsoft Security Development Lifecycle (SDL) 팀에서는 모든 관리 코드 온라인 서비스에서 Anti-XSS 라이브러리 사용을 의무화하고 있습니다.

 

Benefits of the Microsoft SDL

Reducing the number of software vulnerabilities

The SDL has played a critical role in embedding security and privacy into Microsoft software and culture, leading to measurable and widely recognized security improvements in flagship products such as Windows Vista and SQL Server.

Reducing the total cost of development

The SDL reduces the “total cost of development” by finding and eliminating vulnerabilities early. According to the National Institute of Standards and Technology (NIST), eliminating vulnerabilities in the design stage can cost 30 times less than fixing them post release.

 

첨부된 파일이나 아래 참조 사이트를 확인 하여 보면 Microsoft.Security.Application.AntiXss.HtmlEncode(string) 처럼 사용 하는 것을 알 수 있는데 .NET Framework에서 제공 하는 Encode 방식과 차이점은 잘 모르겠다.

 

단. JavaScriptEncode와 같은 추가 적인 Encode 방식도 지원 한다.

 

Ref: http://msdn.microsoft.com/en-us/security/cc448177.aspx

 

예제 페이지:

Default.aspx

HtmlEncode_Example1.aspx

HtmlEncode_Example3.aspx

HtmlAttributeEncode_Example1.aspx

JavaScriptEncode_Example1.aspx

UrlEncode_Example1.aspx

 

첨부 된  SampleApplication.zip 파일에 예제 페이지 및 Anti-XSS 라이브러리 샘플이 포함 되어 있다.

 

반응형

+ Recent posts