XSS + Session Hijacking

2017. 9. 25. 17:58Web



순서대로 진행을 해야하지만, 시간관계상 섞어놨다가

나중에 하이퍼링크를 만들겠습니다.




1. XSS란?

Cross - Site Script의 줄임말로 정의를 해보면 권한이 없는 유저임에도 불구하고, 사이트내에 악의적인 스크립트를 삽입하여 사용자의 (쿠키,세션)등을 탈취하거나, 의도하지않은 비정상적 행위를 하게끔 유도할 수 있는 취약점 입니다.




2. Session Hijacking 이란?

서버와 클라이언트 사이에서 이루어지는 통신에 낑겨서 클라이언트가 서버로 붙어있는 세션을 탈취해오는 기술입니다.

쉽게 표현하면 



사용자와 서버간의 요청과 응답을 하면서 통신을 하는과정에 

만약 Daum의 로그인을 했는데 다음 웹툰 페이지에 이동을하면 로그아웃이 되버리고, 댓글 달때마다 로그인을 해야하는 상황이라면, 매우 곤란하겠죠?



그래서 세션(Session)이란 것을 이용하여 음 이녀석이 아까 그로그인한 녀석이라고 기억하기위해 서버측에선

Session ID라는 것을 사용자에게 부여해줌과 동시에 서버는 그것을 기억해둡니다.

그러면 사용자도 그것을 저장하기위해 쿠키(Cookie)라는 것을 이용해 Session ID를 저장해둡니다.


공격자(악의적 목적을 가진 해커)는 그 사용자와 서버사이의 부여된 저 Session을 가로채서 해당 사용자의 권한으로 해당 사이트를 여행(?)을 할 수 있게됩니다.





자 요 두개를 합쳐서 쉽게 영상을 준비해봤습니다.







영상 설명


Attacker(공격자) - Windows 10

Attacker - Server(공격자 서버) - Kali Linux

Victim - Server (피해자 서버(사이트)) - Windows XP sp3



① 공격자 서버에서 php를 이용하여 함정을 설치



② 자유게시판에 공격자가 악의적인 목적으로 낚시성 글을 작성합니다.
html의 iframe 태그를 이용하여 공격자 서버로 게시글을 읽는 사용자의 세션(Cookie)를 탈취 합니다.


③ 피해자 (사이트 관리자) 입장으로 공격자가 작성한 해당 게시글을 열람 합니다.
게시글을 읽는 그 순간 
html의 div태그를 이용하여 작성한 style 속성에 display :none은 해당 태그자체를 숨기는 것 입니다.
때문에  피해자는 본인이 공격에 당한지 모른채 태연하게 답글을 다는 모습을 볼 수 있습니다.


④ 공격자는 공격자 서버(Kali Linux)로 이동하여 낚아채온 대어(관리자의 쿠키)를 확인하기 위해서
cookie.txt를 cat 명령어를 이용하여 열람합니다.
그리고 해당 세션 id를 복사합니다.

⑤ 4번에서 복사해둔 Session ID를 Chrome 확장프로그램인 
Edit This Cookie라는 Plugin을 이용하여 세션 변경을 시도합니다.

⑥ 세션을 변경하고 다른페이지를 이동하거나, Refresh(새로고침)을 시도하면, 
관리자의 계정으로 로그인이 바뀐것을 확인할 수 있습니다.

※ Session Hijacking으로 탈취한 계정은 로그인 시도를 하지않기 때문에, 로그인 시도 로그를 체킹하는 사이트라면 로그가 남지 않는것을 확인할 수 있습니다.


⑦ 공격자는 마지막으로 탈취한 계정(이하 관리자)을 이용하여 해당 계정의 권한으로 
인성질의 끝을 보여주기 위해 공지사항을 작성합니다.



대응 방안 - XSS

1. Client의 구문시도를 막기위한 JS(JavasScript)를 이용한 <, > 등의 구문을 Filtering 하여야합니다.


2. Server측면인 Backend에서도 클라이언트와 마찬가지로 구문필터링 및 게시글 댓글 검색 등이 넘어올때 전달하기전에 혹시나 스크립트 구문이 삽입되진않았는지 html태그가 삽입되진않았는지 검증 및 체크하는 로직을 구현하여야 합니다.

▶ 사용자가 Proxy 도구(Burp Suite, Paros 등)를 사용하여 업로드 및 전송 하는 그 순간에 탑재를 해서 보내버리면      사실 클라이언트상에서의 필터링은 무용지물이 되어버리기 때문입니다.


3. HTML구문(Tag)을 사용하지 못하도록 막는방법입니다. (1번이랑 같은말이면서 다릅니다.)

현재 티스토리에선 문제가없지만, Naver의 경우는 블로그에서도 Editor 2.0으로 변경되면서 HTML 편집에 자유도가 떨어지며 편집에 한계를 느끼게됩니다. (쥬륵)


4. 사용자의 입력할 수 있는 공간이 많은 사이트의 경우 주기적으로 체크하고 정기적 점검을 권장합니다.

 - 주로 input, form 태그가 존재하는 사이트는 XSS의 취약점 노출성이 존재하기 쉽습니다.





대응 방안 - Session Hijacking

1. 세션 만료를 최대 10분으로 설정합니다. (기본 권장이자 은행사이트에선 10분이 최대입니다.) 연장 버튼이 있거나,

특정 사이트들의 경우는 일부러 30분 1시간등을 사용하는 경우가 있어서 무조건 취약점이라고 판단하기엔 밋밋한(?) 부분입니다.


2. Session ID의 분배 방식에는 순차 방식과 Random 분포 방식이 존재합니다.

순차방식에서는 유추될 위험이있으므로, Random 분포 방식을 사용하여야 합니다.

순차방식을 사용할 경우 개인페이지에서 Session ID 끝자리가 333이길래 334로 올렸더니!!! 다른사람의 개인페이지가 노출되는 현상등을 쉽게 볼 수 있습니다.


3.  1:1 세션지속방법입니다.

예를들면 모바일게임을 스마트폰으로 접속한 후 PC에서 Nox, Memu, MoMo, BlueStack, GenyMotion 등등의 AppPlayer를 이용하여 스마트폰에서 접속중인 게임의 같은 계정으로 접속을 시도할 경우 스마트폰이 로그아웃이 되는 상황을 말합니다.

한 계정은 단 하나의 세션만을 가질 수 있도록 설정하는 방법입니다.


1 2 3 4 5 6