**************************************************************************************************
제목 : Cross-Site Scripting Vulnerabilities
원문 : http://www.cert.org/archive/pdf/cross_site_scripting.pdf
저자 : Jason Rafail, CERT® Coordination Center
번역 : 매맞는아이 (sn1995ar at hotmail.com - 잘못된 곳 있으면 댓글 바람)
*****************************************************************************************************/
당신은 언젠가 web site의 주소를 잘못 쳐서 “Error - page name could not be found” ,
“The page you requested: page name does not exist” 같은 메세지를 본 적이 있을 것이다.
그리고 거기서 단 1초도 머뭇거리지 않고 다른 곳으로 갈 것이다.
(당신이 주소를 정확히 쳤거나 다른 사이트로 갔더라도 말이다.)
그런일은 종종 일어난다. 죽은 link도 많고.. 잘못 연결된 link도 많기 때문이다.
하지만, 당신이 위의 두 가지 경우처럼 에러메시지를 보게 된다면..
당신은 보안 취약점을 목격하는 것이다.
당신이 다음의 유효한 URL로 접속했다고 치자 :
http://www.example.com/FILENAME.html
만약 "FILENAME.html"이 존재하지 않는다면, web site는 다음과 같은 에러 메시지를 보여 줄 것이다.
<HTML> 404 page does not exist: FILENAME.html
....
</HTML>
"FILENAME.html"은 당신이 입력한 것이라는 걸 주목해라.
web site는 당신의 브라우져를 통해 돌려주는 page안에 그것을 포함하고 있다.
이것은 해롭지 않을지 모른다. 하지만 인기있는 경매 사이트를 둘러보고 있다고 생각하자.
('auction.example.com'이라고 하자.)
당신은 누군가 만들어 논 경매를 리스트를 보고 있다. 그리고 똑같은 사람이 팔고 있는 아이템을 좀 더 보고 싶다고 치자.
(그 사람을 "bad guy"라고 가정하자. 그리고 그를 "BG12345"라고 부르자.)
당신은 다른 site의 "BG12345"의 web site link를 클릭할 것이다. 그리고 그가 경매하는 목록을 둘러보고 있다.
그리곤 맘에 드는 page의 link를 클릭 할 것이다. 그럼 'auction.example.com'에서는 그 아이템을 보여 줄 것이다.
조금 더 밑에는 이름과 비밀번호를 입력하는 창이 있다.
당신은 모든 정보를 입력하고 "수락" 버튼을 누를 것이다.
모든 것이 잘 된 것처럼 보인다. 하지만 실제로 당신이 써 넣은 그 정보는 "BG12345"에게 전달된다.
어떻게 이런 일이 벌어질 수 있을까?
그 이유는 'auction.example.com'에 "cross-site scripting(CSS)" 라 불리는 취약점이 있기 때문이다.
CSS 취약점은 유효한 사용자의 입력이 client의 web-browser에 돌려주기 전의 site의 fauilure가 원인이 된다.
CSS는 합밥적인 web server에서 침입자 악의 있는 script나 HTML을 공격할 browser로 page를 보내는 것이다.
악의있는 script는 합법적인 web server에서 합법적인 script의 취급을 받으며 실행된다.
위에서 본 두 가지 에러 메세지는 그런 상황의 예가 된다.
만약 page name을 입력하는 대신 HTML이나 script tag를 입력하게 된다면..
server는 그 명령을 당신의 bowser에 보여 줄 것이다.
당신의 brower는 'auction.example.com'의 HTML이나 script tag를 사실이라 생각할 것이다.
그리고 script를 실행 할 것이다. 모든 것이 정상으로 보일 것이다.
"BG12345" 역시 당신을 속이기 위해 똑같은 방법을 사용했다.
"BG12345"의 경매 site link를 클릭했다면 그 link는 공격자가 꾸민 page로 간다.
그 link가 경매 site를 정확히 흉내냈다면 아래의 예와 같이 보일 것이다.
하지만 "수락" 버튼을 눌렀다면 당신이 입력한 정보들이 "BG12345"로 가게 된다.
그럼 "BG12345"는 당신의 계정에 접속이 가능하고 정보도 바꿀 수 있다.
최악의 상황에는 신용카드 정보도 볼 수 있다.
과연 "BG12345"는 어떻게 했단 말인가?
"BG12345"의 web site는 밑에와 같은 'auction.example.com'의 link를 제공한다.
<A HREF="http://auction.example.com/<script>alert('hello')</script>">Click Here</a>
"FILENAME.html"은 'auction.example.com'에서 다음과 같이 인식된다.
<script>alert('hello')</script>
그럼 'auction.example.com'은 일반적인 routine으로 생각하고 다음과 같은 error page를 보내준다.
<HTML> 404 page not found: <script>alert('hello')</script>
....
</HTML>
결과적으로 "BG12345"는 'auction.example.com'에서 보내주는 page에 JabaScript 프로그램을 "주입'했다.
JabaScript는 'auction.example.com'에 의해 실행된다. 그리고 event를 발생할 것이다.
그리도 "BG12345"가 link에 넣은 script의 효력때문에 "BG12345"와의 소통도 계속된다.
(이것이 CSS 취약점이 web page를 통해 공격되어질 수 있는 이유이다.)
비슷한 문제들이 많이 있다. 'bank.example.com'도 똑같다.
그럼 어떻게 해야 될까?
* 가장 좋은 방법은 필요없는 scripting은 불가능하게 하는 것이다.
하지만 그것은 악의 있는 HTML의 실행을 막지는 못한다.
신뢰하지 못하는 site나 알려지지 않은 sourc의 link로 부터 접속하는 것보다는
직접 다이렉트로 접속하는 것이 좋다.
예를 들어..
이메일로 온 당신의 은행 site의 link를 신뢰하는 것은 좋지 않다.
은행 site를 이용하려면 직접 site에 접속해라.
그리고 개인 정보를 원한다면 항상 조심해라..
* webmaster 또한 도울 수 있다.
그들은 사용자의 입력이 page로 요청되지 않도록 할 수 있다.
그리고 사용자에게 scripting이 되지 않게 할 수 있다.
* 다른 방법은 신뢰하지 못하는 script들이 자동으로 실행하지 못하도록 “signed scripting”을 사용하는 것이다.
하지만 이런 방법은 Internet 표준의 변화를 요구한다.
그런 변화는 "World Wide Web Consortium (www.w3c.org)"이나..
"Internet Engineering Task Force (www.ietf.org)"에서 고려될 사항이다.
* 만약 CSS가 가능한 곳을 보게 된다면 site 관리자나 CERT에 알려주기 바란다.
유감스럽게도 문제는 종종 자주 사용하는 곳에서 발생한다.
scripting을 가능하게 한 상태에서 인터넷을 돌아다닌다면 개인정보를 거의 보호하기 힘들다.
CSS는 그냥 지나치기 쉽다. 하지만 당신의 비밀번호나 신용정보가 새어나가는 큰 손해를 볼 수 있다.
____________________________________________________________________________
Appendix: References and additional information
http://www.cert.org/advisories/CA-2000-02.html
http://www.cert.org/tech_tips/malicious_code_mitigation.html
http://www.kb.cert.org/vuls/id/672683
http://www.kb.cert.org/vuls/id/642239
http://www.kb.cert.org/vuls/id/560659
“CERT” and “CERT Coordination Center” are registered in the U.S. Patent and Trademark Office.
Copyright 2001 Carnegie Mellon University
*****************************************
나온지 꽤 되서 그런지 몰라도..
Apache, IIS 에서 몇군데 테스트 해보았는데 하나도 안 먹혔다..;;
아마 거의 다 패치 ㄷㅚㅆ을 것이다.
익스플로어의 URL parsing 취약점과 접근 부분에서 비슷한 부분도 있고..
흥미로운 문서였던 것 같다..
Posted by 1010
