XSS(Cross Site Scripting)- CSS라고도 씀
<br>
<br>
1. 개요
<br>
<br>
오늘날 인터넷이 발달됨에 따라 Web Security에 대한 문제가 크게 이슈화 되고 있다.
<br>
그리고 뛰어난 방화벽이나 IDS등의 개발로 예전에 비해서는 네트워크나 운영체제 자체의 보안이 점점 강화되어 가고 있다.
<br>
그래서 최근의 크래킹 사건은 열려있는 80번 포트등을 이용해 정상적인 접근을 가장해서 공격이 가해지던지 아니면 웹 어플리케이션 자체의 버그를 이용한 웹해킹
<br>
등이 실제 많이 이루어지고 있다.
<br>
<br>
이는 기존의 방화벽이나 IDS로 차단하기가 쉽지 않고 공격 기법들도 크게 어렵지 않으면서 버그들이 수없이 존재하기 때문에 보안 전문가들의 우려를 낳고 있다.
<br>
<br>
그 중 많이 쓰이는 기법인 XSS와 윈도우 IIS서버를 이용한 공격방법등
<br>
에 대해 알아보고 이에 대한 방어에 대해 알아보기로 하자.
<br>
<br>
<br>
2. 기본 개념
<br>
<br>
해커의 입장에서 하나의 타겟 서버가 있을 때 어떤 방식과 과정으로 침
<br>
투를 하여 공격을 하는지 알아보겠다.
<br>
우선 해킹기법들에 대해서 간단히 알아 보겠다.
<br>
<br>
(1) XSS(Cross Site Scripting)
<br>
<br>
WEB(World Wide Web) 브라우져를 이용해 웹사이트를 방문하다가 보
<br>
면 주소를 잘못 입력하여 “이 페이지를 찾을 수 없습니다” 라는 에러
<br>
페이지를 자주 볼 수 있을 것이다.
<br>
<br>
다음과 같이 URL을 입력해 보았다고 가정해 보자.
<br>
<br>
<a href="http://www.empas.com/melong.html" target=nlink>http://www.empas.com/melong.html</a>
<br>
<br>
실제 melong.html이라는 문서가 존재하지 않기 때문에 웹사이트는
<br>
다음과 같은 에러 메시지를 리턴시키게 될 것이다.
<br>
<br>
<HTML>
<br>
스크립트 파일과 코드 파일을 열 수가 없습니다.
<br>
파일: /home/httpd/www/babo.html HTTP/1.1 200 OK Date: Tue, 09 Mar 2004 03:39:04 GMT Server: Apache Connection: close Transfer-Encoding: chunked Content-Type: text/html c00
<br>
</HTML>
<br>
<br>
여기서 melong.html 이라는 페이지는 본인이 임의로 입력한 페이지임을
<br>
기억해보자.
<br>
<br>
Cross Site Scripting은 위의 경우에 적용시킬 시 melong.html에 악의적인 스크립트를 포함시켜서 웹서버가 공격 대상자의 브라우저로 악의적인 스크립트나 HTML이 포함되어 있는 페이지를 보내도록 유도하는 기법이다.
<br>
(XSS는 CSS라도고 하는데 Cascading Style Sheets 와 혼동이 되기도 하
<br>
기 때문에 전문가들은 크로스 사이트 스크립팅을 주로 XSS로 표기한다.)
<br>
<br>
얼마전에 발표되었던 Ms 익스플로러의 버그였던 URL 스푸핑의 기법도
<br>
XSS공격을 위한 가짜 사이트로의 유도를 위한 것이었음을 볼 때 XSS공격
<br>
의 위험성을 잘 인지할 수 있을 것이다.
<br>
<br>
URL 스푸핑이란 선의적인 사이트를 악의적인 사이트나 음란 사이트로 연
<br>
결할때 주로 사용되며 웹 브라우저에 사용자가 그 링크를 클릭했을 때 고
<br>
의로 악의적인 사용자가 꾸며놓은 원본 site와 똑같은 곳으로 가게 되어
<br>
사용자를 속이는 방법이다.
<br>
<br>
<a href="<a href="http://www.microsoft.com0x01@root.pe.kr/" target=nlink>http://www.microsoft.com0x01@root.pe.kr/</a>">url 스푸핑</a>
<br>
<br>
 url 스푸핑을 클릭하게 되면 사용자는 주소창에 www.microsoft.com
<br>
으로 연결되는 것을 보는 동시에 사실상 root.pe.kr로 이동을 하게
<br>
되는 것이다. (0X01이라는 포워딩문자를 볼 수 있다.)
<br>
<br>
XSS가 적용된 간단한 실예를 들어보겠다.
<br>
<br>
A라는 사람이 HACKER의 웹사이트를 클릭해서 살펴보다가 shoping.com
<br>
이라는 자신이 평소 이용하던 쇼핑물 사이트에 관심을 가지게 되어 shoping.com을 클릭하고선 자신의 아이디와 비밀번호를 넣고 엔터키를
<br>
누른다. 별 문제없이 모든 일이 순조롭게 진행되는 듯 하지만, 사실은
<br>
여기까지의 A가 입력한 정보가 HACKER에게로 전송이 되는 것이다.
<br>
<br>
- XSS의 원리
<br>
<br>
: 공격자가 악의적인 스크립트를 서버에 보내면 이 스크립트는 합법적인
<br>
서버로부터 온 합법적인 스크립트의 권한으로 실행된다.
<br>
서버는 Melong.html이라는 스크립트를 사용자의 브라우저로 명령어를
<br>
리턴시킬 것이고 브라우저는 이 스크립트를 실행 할 것이다.
<br>
위의 예를 보면 HACKER는 shoping.com 과 똑같은 정상적인 페이지로
<br>
위장하기 위해서 HTML과 스크립팅을 사용한 것이다.
<br>
<br>
: Melong.html 대신,
<br>
: <script>alert(‎‘crack’)</script>
<br>
을 사용하면 script 안의 내용이 브라우져에서 실행되는 것이다.
<br>
HACKER는 이 스크립트에 URL 스푸핑을 이용하던지, 불법적인 프로그
<br>
램을 심어놓을 수 있다.
<br>
<br>
또한, document.cookie‎를 추출하여 사용자의 정보를 빼오는 것이 가능하
<br>
다.
<br>
<br>
웹 스크립트들이 실행되는 게시판의 경우, 무척이나 취약할 수 있다는 것을
<br>
예상할 수 있을 것이다.
<br>
<br>
3. 모의 공격 예
<br>
<br>
hotmail 웹서버를 공격할 수 있는 xss 기법을 연구해보자.
<br>
<br>
또한 아울러서 여기서 제공되는 안티바이러스 기능을 우회할 수 있는
<br>
<br>
기법도 생각해 보기로 하자.
<br>
<br>
본인은 타인의 메일서버를 공격할 계획을 가지고 있기로 가정한다.
<br>
<br>
그러기 위해서는 ActiveX 의 도움이 필요한데 상대방이 이것을 브라우저에서 사용불
<br>
<br>
가로 해놓았거나 "모질라"를 사용하게 된다면 문제가 발생할 것이다.
<br>
<br>
다음의 내용이 시스템을 점검해본 결과이다.
<br>
<br>
1. xss 버그 존재 발견 - good
<br>
2. 코드삽입같은 쿠키공격 불가 - bad
<br>
3. 스크립트코드 사용가능 - good
<br>
4. IP 기반의 세션 트래킹 방식 존재여부 불확실 - bad
<br>
5. 공격대상 클라이언트의 출력방향 전환 가능 - good
<br>
6. 공격에 사용된 코드(ActiveX, XML, http request 등등) 이 브라우저에 독립적인 경항 - bad
<br>
<br>
위의 결과를 종합해보니 공격할 수 있는 유일한 길은 자바스크립트 뿐이었다.
<br>
<br>
이번의 경우는 xss 공격의 전형적인 기법인 HTML 삽입법이 통할것 같지 않았다.
<br>
<br>
첨부파일이 열리는 곳으로 부터 URL 을 볼때 세션 식별자와 메세지 식별자를 볼 수가 있다.
<br>
<br>
여기서 우리가 보낸 같은 메세지로 리퀘스트를 보낼 수가 있게 되는 것이다.
<br>
<br>
같은 메세지(같은 식별자는 )는 많은 첨부파일들을 가질 수 있다.
<br>
<br>
그렇기 때문에 같은 메세지에 다른 첨부파일을 가진 리퀘스트를 만들어낼 수 있다.
<br>
<br>
왜 그럴까낭..?~
<br>
<br>
HTTP 리퀘스트의 약간을 수정함으로써 안티바이러스 기능을 통과할 수 있다고 상상해보라...
<br>
<br>
xss 코드를 보낼때 사용한 것과 같은 첨부파일을 사용할 수는 없을 것이다.
<br>
<br>
왜냐하면 상대방의 브라우저에서 직접 열리게 되기 때문에 안티바이러스에 감지가 된다.
<br>
<br>
그래서 다른 첨부파일(같은 메세지가 있는)을 여는 xss 코드를 위조해 보냄으로써 이 안티바이러스 기능이 실행되는 것을 막을 수 있다.
<br>
<br>
자 그럼 예제를 보도록 하자.
<br>
<br>
다음의 예제는 hotmail 로부터 첨부파일을 갖기 위한 URL 이다.
<br>
<br>
=====
<br>
<a href="http://by7fd.bay7.hotmail.msn.com/cgi-bin/g" target=nlink>http://by7fd.bay7.hotmail.msn.com/cgi-bin/g</a>
<br>
...
<br>
..
<br>
중략
<br>
..
<br>
...
<br>
3&vscan=scan
<br>
=====
<br>
<br>
위의 예제에서 "vscan=scan" 부분을 제거한다.
<br>
<br>
그러며 안티바이러스 기능이 실행되지 않게 된다.
<br>
<br>
그런 다음 두개의 첨부파일이 있는 메일을 공격대상자에게 보낸다.
<br>
<br>
첫번째 파일은 다음과 같다.
<br>
<br>
=====
<br>
<html>
<br>
<script>
<br>
str1=document.URL
<br>
str2=str1.slice(55,110)
<br>
splitString = str2.split("&")
<br>
str3=splitString
<br>
...
<br>
..
<br>
중략
<br>
..
<br>
...
<br>
001&a="+str3+"&mimepart=4")
<br>
</script>
<br>
</html>
<br>
=====
<br>
<br>
두번째 파일은 EICAR 같은 바이러스 테스팅 파일이 될 것이다.
<br>
<br>
공격 대상자가 첫번째 파일을 열때 안티바이러스 기능이 아무 이상 없다는 메세지를 보낼 것이다.
<br>
<br>
그러나 파일을 다운로드 받으려고 하면 온라인 상에서 아직 열려있는 상태이기 때문에 xss 코드가 실행이 되면서 다음과 같은 작업에 들어가게 될 것이다.
<br>
<br>
- 세션 ID 와 메세지 ID 를 추출해 낸다.
<br>
<br>
- 두번째 파일을 가리키면서 안티바이러스 기능을 실행시키지 않고 새로운 윈도가 열리게 된다.
<br>
<br>
그럼 상대방은 무엇을 보게 될까 ?
<br>
<br>
그들은 바이러스 경고없이 파일을 다운로드할 수 있다는 것을 볼 수 있게된다.
<br>
<br>
그리고 hotmail 로 부터 다운로드 되는 것을 보게 될 것이다.
<br>
<br>
아주 예민한 사용자들은 뭔가 수상함을 눈치챌 것이지만 이것도 안티바이러스 기능이 실행될때 나오는 것과 유사한 페이지를 이용하여 속일 수 있을 것이다.
<br>
<br>
이에 비추어 이런 결론을 내릴 수 있다.
<br>
<br>
- xss 가 hotmail 에 존재하고 있다.
<br>
- hotmail 안티바이러스 소프트웨어는 xss 기법을 이용하여 쉽게 피해갈 수 있다.
<br>
- hotmail 사용자들은 현재 상당히 위험한 상태에 놓여 있다.
<br>
<br>
<br>
4. 결론
<br>
<br>
<br>
xss의 경우, 사용자는 확실하게 믿을수 있는 Site에서의 링크가 아니라면 링크된 곳을 클릭하여 다른 site로 가지 말고, 직접 브라우저의 주소창에다가 URL을 쳐서 이동하는 것이 안전하다.
<br>
<br>
그리고 해당 메인 site의 갬색기능을 통하여 콘텐츠를 찾는 것이 안전하다.
<br>
이렇게 한다면 90%는 공격에서 방어가 될 것이다.
<br>
<br>
또한 XSS는 E-mail이나 첨부파일을 열 때 자동으로 실행되는 경우가 많으
<br>
므로 수상쩍은 메일은 절대 열지도 실행 시키지 말아야 한다.
<br>
자바스크립트 기능을 해제시켜 놓거나 cookie 보안 세팅을 high로 해 놓는
<br>
것도 하나의 방법이 될 수 있다.
<br>
<br>
익스플로러의 경우 MS사에서 익스플로러 최신 보안패치를 적용시켜야 할 것이다.
<br>
<!-- -->
