[Web] XSS (Cross-Site Scripting)

1. XSS 정의

 공격자가 보낸 코드를, 그 페이지를 열람한 다른 유저에게 스크립트로 실행시키는 것을 크로스사이트스크립트(XSS : Cross-Site Scripting)라고 한다. 유저의 입력데이터를 표시하는 형식으로 되어 있는 게시판과 같은 Web어플리케이션에 발생하기 쉬운 취약성이다.

 Web어플리케이션에서 입력 데이터의 충분한 검증이 이루어지지 않을 때, 공격자는 악의가 있는 코드를 다른 유저가 열람하는 장소에 배치할 수 가 있다. 그 페이지를 열람한 다른 유저는, 그 스크립트를 신뢰할 수 있는 것인지 아닌지를 판단할 방법이 없기 때문에 그대로 실행해 버린다.

 XSS의 문제의 핵심은 동적 페이지에서 보여지는 페이지에 신뢰할 수 없는 내용이 들어갈 수 있다는 점이다. XSS가 발생하면 서버나 클라이언트 양쪽 모두 이 문제가 발생했는지에 대해 인지하기 어렵고, 따라서 방어하기도 힘들다.

 

XSS의 타겟은 변조된 웹페이지에 방문하는 피해자의 웹 브라우저이며, 변조된 페이지 자체는 브로커에 불과하다.

 

2. XSS 공격대상

 ① 대상 스크립트나 언어

    다음과 같은 스크립트나 언어가 공격 대상이 된다.

    - JavaScript

    - VBScript

    - ActiveX

    - HTML

    - Flash

 

② 취약한 코드

  다음과 같은 코드들에서 주로 XSS를 찾을 수 있다. 사실 특정한 유형이 있는건 아니지만 에

러 메시지 출력 부분이나 게시판 아니면 사용자의 정보를 입력해 다시 보여주는 부분 등이 주

로 취약한 부분이 될 경우가 많다. 특히 사용자 등이 웹 사이트의 고객 불만 센터 등을 이용

할 수 있게 해 두었을 경우 XSS을 바로 관리자에게 날릴 수 있는 최악의 사태가 벌어지기도

한다.

  - CGI scripts

 - search engines

 - interactive bulletin boards

 - custom error pages

 

이러한 코드의 다음과 같은 입력 부분에 XSS가 주로 발생한다. 웹 사이트를 서베이할

때에 공격자들이 눈여겨 보는 부분이다.

 

 - URL parameters

 - Form elements

 - Cookies

 - Databases queries

 

3. XSS 공격 방법

 XSS은 반사된 XSS와 저장된 XSS으로 분류한다.

 

① Reflected XSS (반사된 XSS)

 반사된 XSS는 매개변수를 통해 입력을 받아서 다시 출력해주는 로직이 있을 때 발생한다.

 기본적인 공격 단계는 아래와 같다.

(사진 참고 : http://cafe.naver.com/secuholic - By. Hyunmini)

 

이처럼 자바스크립트 코드를 삽입하여 사용자가 클릭하도록 유도하면 클라이언트의 브라우저에서 임의의 자바스크립트 코드를 실행 시켜, 공격자가 원하는 정보를 얻을 수 있다.

② Stored XSS (저장된 XSS) 

         (사진 참고 : http://cafe.naver.com/secuholic - By. Hyunmini)

 

저장된 XSS는 게시판의 게시물 등 사용자와 상호작용하여 서버측에 저장되는 어플리케이션에서 발생하는 취약점 이다. 예를 들어 게시판의 게시물에 악성 스크립트와 함께 클라이언트가 혹 하는 게시물을 등록해 두면, 다른 사용자가 그 게시물을 클릭할 시 해당 스크립트가 실행되는 것이다.

 

이러한 XSS는 임의의 자바스크립트 코드를 희생자의 브라우저에서 실행되도록 할 수 있게 해주며, 그로 인해 아래와 같은 수많은 악성 행위를 허용하게 된다.

 

 - 세션 갈취

 - 사설 네트워크 IP 확인

 - 브라우저 히스토리 훔치기

 - 키 로거

 - 클립보드 모니터링

 - 포트 스캐닝

 - 로그인되어 있는 사이트 확인

   등등

 

또한 이러한 XSS를 이용한 웹웜도 공개되어 있으며, 희생자 브라우저를 마음대로 컨트롤 할 수 있는 XSS Shell도 존재 한다.

 

위에서 보듯이 XSS는 복잡성과 프로그래밍 기술 측면을 고려할 때 공격자에게 최상의 공격 수단이다. 자바스크립트를 조금만 알면 텍스트 편집기를 이용해 쉽게 공격코드를 작성할 수 있다. 또 윈도우, 리눅스 인터넷 익스플로러, 사파리, 오페라 등을 모두 공격할 수 있는 범용 페이로드를 작성하기도 쉽다. 웹 브라우저는 웹사이트의 사용자 경험과 HTML 출력을 담당하는 범용 플랫폼이지만 악성 문자로 조작된 웹 페이지에 방문할 때는 범용 공격 대상이 될 수도 있다.

 

4. 보안 검증

 목표는 어플리케이션 안의 모든 매개변수들이 유효한지 또는 HTML 페이지 안에 포함되기 전에 암호화되는지를 검증하는 것이다.

 

 자동화적인 접근 방법

자동화된 침투 테스트 도구들은 매개변수 삽입을 매갤 한 반사된 XSS를 탐지하는 능력은 있으나 지속적으로   XSS를 찾는 데는 종종 실패한다. 특히, 삽입된 XSS 벡터의 결과를 권한 확인을 통해 방어되고 있다면 더더욱 그렇다. ( 예를 들면, 사용자에 의해 관리자가 나중에서야 볼 수 있는 악의적인 데이터를 입력 하였을 때 등)

 

 수동적인 접근 방법

통합된 검증과 암호화 메커니즘을 사용한다면, 가장 효율적인 보안 검증 방법은 코드를 확인하는 것이다. 만약 분산하여 구현되어 있다면 검증을 하는데 상당히 많은 시간이 걸릴 것이다. 대부분의 어플리케이션의 공격 범위가 상당히 크기 때문에 테스트를 하는데 많은 시간이 걸린다.

 

5. 기본 대책

 ① ASP Script

    사용자의 입력에 대해 Server.HTMLEncode 함수를 사용하여 HTML 태그를 비활성화 시킨

    다

   

‘ Server.HTMLEncode함수를 사용하여 HTML태그를 변환 합니다.

<%=Server.HTMLEncode(“<script>alert<”XSS Test”);<script>”) %>

‘ 위의 결과 Tag들이 비활성화가 된다.

 

② JSP Script

 HTML 코드의 시작을 알리는 ‘<’에 대해서 &lt;으로 변환시킨다.

            

/% less than (<) character 를 &lt; 으로 변환시킵니다. %/

String userinput=request.getParameter(“keyword”);

User_input=user_input.replaceAl(“”,”\”);

 

③ PHP Script

PHP의 내장함수가운데 입력 문자열에 대해서 HTML코드를 변환시켜주는 htmlentities() 를

사용하여 XSS를 막는다.

 

<?

$str = “A ‘quote’ is <b>bold</b>

Echo htm;entities($str);

// 출력: A ‘quote’ is &lt;b&gt;bold&lt;/b&gt;

?>

 

 

6. 대비 및 방어책

 

개발자 입장에서~

 ① 악의 적인 명령어 실행 (XSS) 취약점

- 사용자 입력값에 대해 유효성 검증한다.

- <script> 문자열이 들어오면 <xxscript>나 다른 문자로 변환한다.- <script> 태그 외에 다양한 기법을 이용해 공격하기 때문에 필터링 할 것들을 정해서 막는 Negative 방식 보다 입력 가능한 문자만 정한 뒤 그 외 정의된 문자가 아닐 경우에 필터링을 제한 하는Positive방식이 더 효율적이다.

 

② 취약한 세션 관리

- 인증정보는 Cookie보다는, Session을 사용하는 것이 안전하다.

- Cookie를 사용할 경우 반드시 암호화하고, 위/변조 여부를 체크한다.

 

③ JAVA

  - <bean:write …> 같은 Struts 결과값 방식을 사용한다. 또는 <c:out …> 내에 기본적으로

     JSTL escapeXML=”true” 속성을 사용한다. 중첩되지 않는 <%= … %>을 사용하지 않는

     다. (이것은 적당한 결과값 암호화 방식에서 벗어난다.

  

④ .NET

  - MSDN으로부터 자유롭게 사용이 가능한 Microsoft Anti-XSS 라이브러리 1.5를 사용한

    다.

    이 라이브러리를 사용하지 않고 요청된 대상 usename.Text = Request.QueryString

   (“username”)을 직접적으로 폼 필드 데이터에 할당하지 않는다. .NET은 자동적으로 암호

   화된 출력 데이터를 조정한다.

 

⑤ PHP

  - 출력 값이 htmlentities() / htmlspecialchars()를 통과하였는지 확인한다.

     또는 OWASP PHP ANTI-XSS 라이브러리를 사용한다.

 

 사용자 입장에서 ~

 일반 사용자들은 XSS취약점에 거의 무방비 상태이다. 자신이 자주 접속하는 동호회 게시판이나 e-메일에 누가 언제 어떻게XSS취약점을 이용해서 악성 스크립트 코드를 숨겨놓았을지 전혀 알 수 없기 때문이다.

일반 사용자들이 XSS취약점에 대응하는 방법은 다음과 같다.

 

① e-메일이나 링크가 있으면 링크를 바로 클릭하여 이동하지 말고 직접 URL에 주소를 입력

   하여 사이트를 방문한다. 상당히 불편할수 있지만 URL 스푸핑이나 XSS공격에 대응할 수

  있다.

 

② 인터넷 익스플로러의 최신 패치를 적용하여 인터넷 익스플로러 자체의 취약점으로 인한

    공격에 미리 대응한다. (IE8 부터는 Anti-XSS 기능을 탐재하고있다.)

 

③ 웹 브라우저의 인터넷 옵션에서 개인 정보 등급을 상향 조절하여 불필요한 쿠키 값을 전송

    하지 않게 한다.

(보안 설정을 가장 높게 설정하면 쿠키 값이 필요한 사이트에서 서비스를 사용하기 힘든

  경우가 발생할 수 있기 때문에 보안 설정을 최상위로 높이는 것을 추천하지 않는다.)