 |
|
난이도 : 중급 J. Jeffrey Hanson, Chief Architect, Max International
원문 게재일 : 2009 년 8 월 04 일
번역 게재일 : 2009 년 9 월 29 일 매시업 개발 모델은 웹 환경의 가능성을 실현시킬 수 있는 무한한 기회를
제공합니다. 하지만 이 개방성으로 인해 여러 가지 새로운 보안 문제도 대두되고 있습니다. 이
기사에서는 이러한 문제를 해결하는 데 도움이 될 수 있는 몇 가지 팁과 기술에 대해 설명합니다.
매시업은 다양한 소스(공용 소스 포함)의 UI 아티팩트 및 데이터의
모음을 사용하여 작성된 애플리케이션 및 웹 페이지이다. 매시업 개발 모델에서는 개방형 개발
모델이 사용되기 때문에 여러 가지 새로운 보안 위험이 나타나고 있다. 이러한 위험 요인으로
인해 보안은 매시업 애플리케이션을 개발할 때 우선적으로 고려해야 할 요소가 되었다. |
자주 사용하는 약어
- DMZ: Demilitarized zone
- DOM: Document Object Model
- HTML: Hypertext Markup Language
- HTTP: Hypertext Transfer Protocol
- SQL: Structured Query Language
- SSL: Secure Sockets Layer
- UI: User interface
|
|
DMZ 및 방화벽과 같은 일반적인 보안 수단으로는 매시업 UI 아티팩트 및
데이터에 필요한 세분화된 액세스를 해결하기가 어렵다. 매시업 애플리케이션이나 페이지에서는
CSRF(Cross-site request forgery), Ajax(Asynchronous JavaScript™ + XML)
취약성, XSS(Cross-site scripting) 및 기타 잠재적 보안 약점과 같은 문제를 해결해야 한다.
이 기사에서는 매시업 애플리케이션 및 페이지를 작성할 때 해결해야 하는 보안 문제를 살펴본다.
매시업 보안의 필요성
매시업 페이지 또는 애플리케이션은 일반적으로 일시적인 방법으로 하나 이상의
내부 및 외부 사이트에서 가져온 데이터 및 UI 아티팩트를 사용하여 작성된다. 이 개발 모델에서는
보안 취약성이 매우 빠르게 확산될 수 있다. 매시업에 새로운 아티팩트 또는 데이터 소스가 추가될
때마다 보안 취약성이 증가하기 때문이다. 이러한 개방형 통합에서는 악성 침입을 차단하기 위해
아티팩트 및 데이터에 대한 검증 및 보안 적용이 철저하게 이루어져야 한다.
매시업 페이지가 다른 매시업의 구성 요소 또는 데이터 소스로 사용될 수도 있기
때문에 시간이 지날수록 매시업 아티팩트, 페이지 및 데이터 소스가 어떻게 사용될 것인지를
정확히 예측하기가 어려워진다. 따라서 보안 문제는 반드시 매시업에 사용되는 모든 구성 요소 및
프로세스에서 해결해야 한다.
사용자 입력 보안 SQL
삽입, CSRF 및 XSS와 같은 많은 침입 취약성은 포괄적인 입력 유효성 검증 프레임워크를 사용하여
차단할 수 있다. 매시업 서버측 유효성 검증 프레임워크와 클라이언트측 매시업 유효성 검증
프레임워크에서 상호 보완하는 방식으로 입력 데이터를 처리해야 한다. 클라이언트측 유효성 검증은
매우 쉽게 뚫을 수 있기 때문에 포괄적이고 보완적인 서버측 유효성 검증에서 데이터와 프로세스를
보호할 수 있는 중요한 구성 요소를 제공한다. 효과적인 입력 유효성 검증 프레임워크가 되기
위해서는 다음과 같은 작업을 수행해야 한다.
- 입력 데이터를 제한하는 유한 값 목록을 정의한다.
- 입력 데이터 유형, 데이터 길이, 데이터 범위 및 데이터 형식의 유효성을 검증한다.
- 일관된 유효성 검증 모델을 사용하기 위해 클라이언트 및 서버에서 정규 표현식을 사용한다.
- 입력 데이터에서 올바르지 않은 문자를 삭제한다.
온디맨드 스크립트 악용 피하기 많은
매시업에서는 요청 시 동적으로 다운로드되어 해석되는 JavaScript 코드를 포함시키는 기술을
사용하고 있다. 온디맨드 스크립트에는 XSS와 같은 보안 취약성을 악용하려는 의도를 가진 악성
코드가 포함되어 있을 수 있다. 이 취약성은 악성 코드가 실행되지 않도록 하기 위해 온디맨드
스크립트의 유효성이 검증되었는지와 스크립트에서 생성된 컨텐츠가 올바르게 인코딩되었는지를
확인하여 해결할 수 있다. Listing 1에서는 인코딩되지 않은 마크업의 예를 보여 준다.
Listing 1. 인코딩되지 않은 마크업의 예
<div>
This is example content
</div>
|
Listing 2에서는 앞에서 본 코드의 인코딩된 버전을 보여 준다.
Listing 2. 인코딩된 마크업의 예
<div>
This is example content
</div>
|
위에서 본 것처럼 동적으로 생성되는 스크립트를 사용하는 매시업 페이지에서는
데이터가 브라우저에서 HTML 마크업이나 스크립트 코드로 해석되지 않도록 하기 위해 스크립트에서
생성된 데이터에 대한 유효성 검증과 인코딩이 올바르게 수행되었는지 확인해야 한다. 해석이
잘못되면 악성 코드가 실행되어 보안 위반이 발생할 수 있다. 데이터에 대한 유효성 검증과
인코딩이 적용되지 않을 경우 다음과 같은 취약성이 악용될 수 있다.
- 데이터 무결성이 훼손될 수 있다.
- 침입자가 쿠키를 작성하거나 액세스할 수 있다.
- 침입자가 사용자 입력을 인터셉트하거나 액세스할 수 있다.
- 신뢰할 수 있는 도메인 또는 컨텍스트 내에서 악성 스크립트가 실행될 수 있다.
해석된 각 컨텍스트에 대한 지능적인 분석을 통해 각각의 특정 컨텍스트 내에서
문제를 발생시킬 수 있는 문자만 처리해야 한다. 세션 고정 공격 차단하기 기존
세션의 유효성을 먼저 취소하지 않은 채로 서버에서 사용자를 인증할 경우 세션 고정이
발생할 수 있다. 세션 고정이 발생하면 침입자가 인증된 세션을 인터셉트하거나 새 세션을 작성한
후 세션 ID를 캡처할 수 있다. 그런 다음 유효한 사용자가 동일한 세션 ID로 세션을 만들 때 세션
ID를 악의적으로 사용할 수 있다. Listing 3의 Java™
코드에서는 기존 세션의 유효성을 먼저 취소하지 않은 채로 클라이언트 요청을 인증하는 모습을
보여 준다.
Listing 3. 세션 고정 취약성의 예
private boolean authenticateUser(HttpServletRequest req)
{
// session.invalidate() should have been called prior to this
// to invalidate an existing session
HttpSession session = req.getSession(false);
if (null != session)
{
// existing session assumed valid
return true;
}
if (authenticateRequest(req) == true)
{
// create a new session
req.getSession();
return true;
}
return false;
}
|
Listing 3에서는 기존 세션의 유효성이 취소되지 않았기 때문에 현재 요청이 유효한 것으로
간주되는 상황을 보여 준다. 이 상황은 새 사용자가 서버에 인증 신임을 제공할 때 악용될 수 있다.
즉, 세션이 유효한 상태로 유지되는 동안 기존 세션을 생성한 사용자가 데이터를 기록하고 악용할 수
있다. 이러한 유형의 공격을 막을 때는 다음과 같은 기술이 사용된다.
- 세션 제한 시간을 지정한다.
- 명시적인 로그아웃 UI 컨트롤을 사용하여 세션 유효성 취소를 강화한다.
- 개인 정보가 중요한 상황이 발생할 때마다 사용자에게 신임 정보를 다시 입력하도록 요청한다.
- 요청마다 세션 ID를 다시 생성한다.
이 상황은 매시업 페이지에서 침입자가 브라우저 제한을 뚫고 중요한 데이터를
리디렉션하여 기록하려는 경우에 자주 사용된다. 이 공격을 XSS(Cross-site scripting)라고도 한다.
CSRF 공격 차단하기 CSRF
공격은 브라우저를 속여서 신뢰할 수 있는 사이트로 요청을 보내도록 만드는 침입자 사이트의 악의적
코드에서 시작된다. 브라우저의 SOP(Same-Origin Policy)는 출처가 다른 사이트에서 보낸
요청은 막지 않고 출처가 다른 사이트로 보내는 요청만 막는다. 따라는 SOP는 CSRF 공격을
차단하지 못한다. CSRF 공격은 인증된 세션을 처음 시작한 브라우저에서 전송되는 모든
요청을 유효한 요청으로 간주하는 서버를 대상으로 작동한다. 사용자 이름/암호, 쿠키 및 SSL 인증서와
같은 일반적인 인증 메커니즘에서는 개별 요청과 서버 사이의 세션 인증이 아닌 브라우저와 서버
사이의 세션 인증에 의존하기 때문에 CSRF 공격을 충분히 막아내지 못한다. CSRF 공격에서는
침입자 사이트에서 발생한 요청이 인증된 브라우저 페이지를 통해 서버로 전송된다. 그런 다음
교묘한 방법을 통해 응답이 칩입자 사이트로 전송된다. 그림 1에서는 CSRF
공격 중에 발생하는 요청과 응답의 진행 순서를 보여 준다.
그림 1. CSRF 공격 중에 발생하는 이벤트의 진행 순서
그림 1에서는 인증된 매시업 페이지를 통해 매시업 서버로 요청을 보내는 침입자
사이트를 보여 준다. 이 공격은 매시업 페이지에서 침입자 사이트를 대신해서 기업 매시업 서버로
요청을 프록시할 경우에만 가능하다. 이 공격은 다양한 HTML 기술을 통해 이루어질 수 있다. 침입자가
CSRF 공격할 때 사용하는 방법 중 하나는 <img> 태그의 src
속성 내에 URL을 포함시키는 것이다. 브라우저에서 <img> 태그를 평가할 때
URL이 참조된다. 그러면 해당 URL에서 참조하는 호스트로 데이터가 전송될 수 있다. 예를 들어, 다음과 같은
<img> 태그를 살펴보자.
<img src="http://mybank/transfer?amount=10000&fromaccount=44332&toaccount=55443">
|
mybank에 인증된 세션이 위와 같은 <img> 태그가 포함된
페이지에 방문하게 되면 <img> 태그가 평가되면서 src
속성에 지정된 URL이 참조되기 때문에 요청된 작업이 수행된다. mybank 서버에서 HTTP GET
요청을 사용하여 변경 작업을 시작하지 않고 POST 요청만을 사용하여 변경
작업을 시작한다면 이러한 유형의 CSRF 공격을 차단할 수 있다. 매시업 서버에서는 CSRF 공격을
차단하기 위해 POST 및 GET 요청이 포함된 HTTP
요청을 보낼 때마다 요청별 토큰을 함께 포함시키도록 요청하는 방법을 사용하기도 한다. JSON 데이터 보안 JSON(JavaScript
Object Notation)은 JavaScript 프로그래밍 언어의 구문을 따르는 데이터 구조이다. 따라서 JSON 데이터는
거의 모든 표준 JavaScript 함수 또는 명령문을 통해 처리할 수 있다. 특히 eval()
함수가 JSON 데이터를 처리할 때 자주 사용된다. Listing 4는 JSON 데이터
블록을 보여 주는 간단한 예이다.
Listing 4. JSON 데이터 블록의 예
[
{
name: "object1",
message: "Greetings from object1",
},
{
name: "object2",
message: "Greetings from object2"
},
{
name: "object3",
message: "Greetings from object3"
code: alert("This will be executed when evaluated!")
},
{
name: "object4",
message: "Greetings from object4"
},
{
name: "object5",
message: "Greetings from object5"
}
]
|
위에서 설명한 JSON 데이터를 평가하면 object3 오브젝트에
포함된 JavaScript 명령이 실행된다. 이 기능은 매시업 서버 및 매시업 애플리케이션에서 종종 사용되는
기능으로 XMLHttpRequest 오브젝트 요청에 대한 응답을 서버에서 브라우저로
보낼 때 JSON을 응답의 데이터 형식으로 사용하려는 경우에 사용된다. 하지만 이 메커니즘에도 상당히 큰
보안 취약성이 있다. 위에서 설명한 대로 JSON 데이터 블록 내에 포함된 모든 JavaScript 명령은
데이터 블록이 해석되는 즉시 실행된다. JavaScript 언어의 eval() 함수는
다음 예제와 같이 JSON 데이터를 처리할 때 종종 사용된다.
var jsonObject = eval('(' + httpReqResponse + ')');
|
JSON 데이터 블록에 포함된 명령은 eval() 함수에 의해 처리된
후 바로 실행된다. 데이터에 악성 코드가 있을 경우 매시업 페이지의 중요한 데이터가 침입자의 손으로
넘어갈 수 있다. 또한 악성 코드가 매시업 페이지에 대한 제어를 갖게 될 수도 있다. 다음과
같은 방법을 통해 JSON 데이터 악용을 방지할 수 있다.
- JSON 데이터 블록 앞에 무한
while 루프를 배치한다.
- JSON 데이터 블록을 JavaScript 주석으로 랩핑한다.
eval() 함수로 JSON 데이터 블록을 처리하지 않는다. Listing 5에서는 JSON 데이터 블록 앞에 while(1);
명령문을 배치한 예를 보여 준다. 이 기술을 사용하면 JSON 데이터를 사용하기 전에 무한 루프를 피하기
위해 클라이언트에서 while(1); 문을 제거해야 한다.
Listing 5. while 루프로 랩핑된 JSON 데이터 블록의 예
while(1);
[
{
name: "object1",
message: "Greetings from object1",
},
{
name: "object2",
message: "Greetings from object2"
},
{
name: "object3",
message: "Greetings from object3"
code: alert("This will be executed when evaluated!")
},
{
name: "object4",
message: "Greetings from object4"
},
{
name: "object5",
message: "Greetings from object5"
}
]
|
표준 eval() 함수 대신 JSON 라이브러리에서 제공하는
JSON.parse() 함수(참고자료 참조)를
사용할 수 있다. Listing 6에서는 JSON.parse()
함수로 JSON 데이터를 처리하는 예를 보여 준다.
Listing 6. JSON.parse 함수의 예
<script type="text/javascript" src="js/json2.js"></script>
var jsonObject = JSON.parse(httpReqResponse);
|
Listing 7에서는 JavaScript 주석으로 랩핑된 JSON 데이터 블록을
보여 준다. 이 주석은 JSON 데이터를 사용하기 전에 클라이언트에서 제거해야 한다.
Listing 7. JavaScript 주석으로 랩핑된 JSON 데이터 블록의 예
/*
[
{
name: "object1",
message: "Greetings from object1",
},
{
name: "object2",
message: "Greetings from object2"
},
{
name: "object3",
message: "Greetings from object3"
code: alert("This will be executed when evaluated!")
},
{
name: "object4",
message: "Greetings from object4"
},
{
name: "object5",
message: "Greetings from object5"
}
]
*/
|
iframe 보안 매시업
위젯은 포함된 iframe(inline frame)으로 구현되기도 한다. iframe은 브라우저가 페이지 내에서 별도의
엔터티로 간주하는 HTML 요소이다. iframe 내에 배치된 컨텐츠는 iframe 외부에 있는 브라우저의 DOM을 조작할
수 없기 때문에 iframe은 매시업 페이지 내에서 잠재적인 악성 컨텐츠를 격리하기 위한 매시업 위젯 및 기타 UI
아티팩트로 사용되기도 한다. Listing 8에서는 두 가지 일반적인 iframe 요소를 보여 준다.
Listing 8. 일반적인 iframe 요소의 예
<iframe src="http://jeffhanson.com/iframe1.html" />
<iframe src="http://jeffhanson.com/iframe2.html" />
|
iframe은 일반적으로 브라우저 페이지 내에서 경계가 있는 UI 구성 요소로 표시되는
시각적 요소로 사용된다. 하지만 iframe은 그림 2와 같이 브라우저 페이지
내에서 숨겨진 상태로 메시징 컨트롤로 사용되기도 한다.
그림 2. iframe과 매시업 페이지 간의 데이터 전달
이 그림은 jeffhanson.com/index.html에서 볼 수 있는 HTML 페이지를 보여 준다. 페이지의
DOM 내에 숨겨진 iframe이 포함되어 있으며 이 iframe은 jeffhanson.com/test.html의 컨텐츠를 기반으로
구성된다. JavaScript 함수 sendData()가 숨겨진 iframe의 src
URL을 http://jeffhanson.html#data로 설정한다. onLoad 이벤트에 대해 정의된
함수에서 본 것처럼 프래그먼트 식별자(해시 표시) 뒤의 src URL 부분은
window.location.hash 요소를 사용하여 검색할 수 있다. 이 메커니즘을
사용하면 index.html 페이지가 로드될 때 숨겨진 iframe이 프래그먼트 식별자 뒤에 있는 데이터를 검색할
수 있다. 이 기술은 iframe 간 또는 HTML 페이지와 포함된 iframe 간에 데이터를 전송하는 데 사용되기도
한다. 위에서 설명한 iframe 데이터 전송 메커니즘에도 보안 취약성이 있다. 포함하는 HTML 페이지
내의 모든 구성 요소에서 src URL을 설정할 수 있기 때문에 페이지에 포함된
UI 아티팩트에 악성 코드가 들어 있을 경우 페이지에 포함된 데이터가 훼손될 수 있으며 기본 HTML 페이지가
시작된 서버와 통신이 이루어질 수도 있다. 이러한 iframe 프래그먼트 식별자 공격은 다음과 같은
여러 가지 방법으로 차단할 수 있다.
- 허용 목록에 포함된 도메인에서만 프래그먼트 식별자를 수정할 수 있도록 한다.
- 공용 키를 사용하여 프래그먼트 식별자를 암호화한다.
- JavaScript 코드를 사용하여 프래그먼트 식별자 데이터를 필터링한다.
- 프래그먼트 식별자 데이터에 포함된 JavaScript 코드가 우발적으로 실행되지 않도록 제한한다.
결론 매시업은
다양한 소스(공용 소스 포함)의 UI 아티팩트 및 데이터를 사용하여 작성된 애플리케이션 및 웹
페이지이다. 매시업 개발 모델은 여러 가지 새로운 보안 위험에 노출된 매우 개방적인 환경에서
작동한다. 이러한 새로운 위험으로 인해 보안은 매시업 애플리케이션을 개발할 때 가장 우선적으로
고려해야 할 요소가 되었다.
매시업 애플리케이션이나 페이지에서는 CSRF, Ajax 취약성, XSS 및 기타 잠재적
보안 약점을 해결해야 한다. DMZ 및 방화벽과 같은 일반적인 보안 수단으로는 매시업 개발에
필요한 보안 요구 사항을 해결하기가 어렵다. 이 기사에서는 매시업 애플리케이션 및 페이지를
작성할 때 발생하는 보안 문제를 해결할 수 있는 기술에 대해 살펴보았다.
참고자료 교육
제품 및 기술 얻기
- JSON.org에서 JSON과 필요한 라이브러리에 대한 자세한 정보를 볼 수 있다.
- IBM 시험판 제품을
다운로드하여 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및
미들웨어 제품을 사용하자.
필자소개 | 
| | 소프트웨어 산업 분야에서 20년 이상 활동해 온 Jeff Hanson은 OpenDoc 프로젝트의 Microsoft® Windows® 이식을
담당한 선임 엔지니어로 활약했으며, Novell에서 Route 66 프레임워크의 책임 아키텍트를 맡았으며, eReinsure.com, Inc.의
수석 아키텍트를 역임했다. 현재는 Max International의 CTO로서 도소매 업계를 엔터프라이즈 애플리케이션 및 플랫폼의
설계와 구현을 지도하고 있다. .NET versus J2EE Web Services: A Comparison of Approaches, Pro JMX: Java Management Extensions,
Web Services Business Strategies and Architectures, Mashups: Strategies for the Modern Enterprise 등을
포함한 수많은 기사의 저자이기도 하다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
