|
강좌
|
HOME > 강좌 > |
|
강좌| 리눅스 및 오픈소스에 관련된 강좌를 보실 수 있습니다.
|
|
|
홈페이지개발 보안가이드[2] - 홈페이지 개발시 보안 취약점 및 대책과 결론
|
|
|
 조회 : 24,244
|
제3장 홈페이지 개발시 보안 취약점 및 대책
홈페이지 개발 과정에서 발생될 수 있는 보안 취약점은 대단히 다양하다. 본 장에서는 공격자가 공격에 주로 많이 이용하고 홈페이지 개발자가 범하기 쉬운 주요 보안 취약점 10가지를 소개한다. 각 취약점에 대한 상세한 설명과 이 취약점에 대한 보안 대책과 프로그래밍 사례를 제시하도록 하겠다.
제1절 접근통제 취약점
1. 취약점 설명
가. 개요
접근통제는 특정 사용자들에게만 웹 콘텐츠나 기능들에 접근할 수 있도록 허가해 주는 것으로 일반적으로 관리자 페이지에 대한 접근통제가 필요하다.
관리자 페이지는 웹 서비스의 사용자나 데이터, 콘텐츠를 손쉽게 관리하기 위한 목적으로 다양한 기능과 권한을 갖고 있고 이는 홈페이지의 운영에 매우 중요한 역할을 하고 있으므로 일반사용자는 인증을 통과하지 못하도록 할 뿐 아니라 일반사용자가 관리자 페이지를 볼 수 없도록 해야 한다. 그러나 일반적으로 추측하기 쉬운 URL(ex: /admin, /manager)을 사용하고 있어, 아이디/패스워드에 대한 크랙 또는 접근 허가 정책에 대해 요청하는 부분의 정보를 변경함으로써 접근이 가능한 경우가 많다. 웹 관리자의 권한이 노출될 경우 홈페이지의
변조뿐만 아니라 취약성 정도에 따라서 웹 서버의 권한까지도 노출될 위험성이 존재한다.
나. 위협 사례
(1) 관리자 페이지 인증 우회
대부분의 관리자 페이지는 http://www.test.com/admin 등과 같이 쉽게 추측이 가능하다. 또 인증 과정이 존재하더라도 SQL Injection, Javascript 변조 등의 취약점을 이용하여 인증과정을 우회하여 웹 관리자 권한을 획득 할 수 있다.
다. 취약성 판단
● 일반적으로 많이 사용하는 관리자 페이지 명을 입력하여 관리자 페이지가 존재하는지 점검한다.
● 관리자가 원격지에서 페이지에 대한 변경을 수행할 때 해당 연결이 적절히 보호되는지 점검한다.
※ SSL과 같이 암호화된 연결을 사용하는지 점검
● 관리자페이지에 기본 관리자 계정 및 패스워드를 입력하여 패스워드 취약점을 점검한다.
※ 관리자 계정 예 : admin, administrator, manager 등
● 홈페이지 패스워드 크랙도구를 이용하여 원격에서 패스워드 크랙을 시도한다.
● 특정 회사의 웹 어플리케이션을 사용하는 경우 해당 회사에서 판매 시 제공하는 기본계정 및 패스워드를 이용하여 취약점을 점검한다.
※ 특정 제품에 대한 기본계정 및 패스워드는 검색사이트를 검색하여 쉽게 알 수 있다.
● 사용자 인증을 통과하여 접속한 페이지에 대하여 인증 과정 없이 중간 페이지에 접속하여 접속이 가능한지를 점검한다.
2. 보호대책
일반사용자의 접근이 불필요한 관리자 로그인 페이지 주소를 유추하기 어려운 이름으로 변경한다.
중요한 정보를 가진 웹 서버의 특정 페이지들은 관리자 또는 특정 사용자만 접근할 필요가 있다. 이러한 주요 페이지들은 웹 서버에서 적절한 설정을 통하여 특정 사용자만 접근이 가능하도록 사용자 접근제한을 할 수 있다.
가. 웹 서버 보호 대책
별도의 네트워크 범위로 IP 레벨의 접근 권한을 설정하고 웹 관리자 메뉴의 접근을 제한하며 웹 관리자의 인터페이스는 특히, SSL기술을 이용하여 HTTP over SSL과 같은 Data Transaction 암호화를 반드시 적용해야 한다.
가능하다면, VPN과 같은 네트워크 차원의 별도 보안시스템의 설치도 고려할 필요가 있다.
또한, 관리자 계정으로는 외부 사이트에서 접근하는 것을 허용하지 않는 것이 바람직하다. 대부분의 홈페이지에서 관리자 계정에 많은 권한을 부여하고 있는 경우가 많고, 일반 사용자용 게시판과는 달리 관리자용 게시판의 경우에는 별도 관리가 안되고 있는 경우가 많아 관리자 계정 권한 획득 시 홈페이지 시스템의 권한획득으로 이루어지기 쉽기 때문이다. 따라서 관리자 페이지의 경우, 사내 IP에서만 접근이 가능하도록 설정하고, 만일 외부 관리자의 접근이 반드시 필요한 경우라면, 사이트 관리 권한을 외부로 열어주지 않고도 가능한 VPN 기술을 사용하면 외부 관리자가 회사 내부(혹은 사이트) 네트워크로 접근할 수 있으며, 관리자는 보호된 백엔드 연결을 통해 사이트에 접근할 수 있다.
● admin, manager 등과 같이 추측하기 쉬운 디렉토리 명이나 파일명을 사용하지 않음
● 관리자 페이지의 경우, 관리자 호스트 IP만 접근 가능하도록 설정함
(1) IIS 웹 서버에서 보호 대책
아래의 방법으로 [관리자 페이지] 접근을 제한한다.
● 설정 -> 제어판 -> 관리도구 -> 인터넷 서비스 관리자 선택
● 해당 관리자 페이지 폴더에 오른쪽 클릭을 하고 등록정보 -> 디렉토리 보안 -> IP 주소 및 도메인 이름 제한 -> 편집 버튼을 클릭
● 액세스 거부를 선택하고 추가 버튼을 클릭하여 관리자 호스트IP 또는 서브넷을 등록
(2) Apache 웹 서버에서 보호 대책
Apache 웹 서버의 환경설정 파일인 httpd.conf 파일의 Directory 섹션의 AllowOverride 지시자에서 AuthConfig 또는 All 추가하여 .htaccess를 통하여 사용자계정, 사용자 패스워드를 등록한 사용자만 접근이 가능하도록 하고 관리자 디렉토리(admin)에 대해 특정 IP에 대해서만 접근이 가능하도록 하기 위해서 다음과 같이 설정한다.
관리자 페이지와 같이 인증이 필요한 디렉토리에 .htaccess 파일을 만들고 admin 계정의 패스워드를 다음과 같이 설정한다. 위와 같이 설정 후 ~apache/bin/htpasswd를 이용하여 사용자정보 파일(.htpasswd)을 생성한다.
※ 주의사항
① Apache 서버의 경우 AllowOverride 지시자를 변경시 apache restart가 필요하다.
② 관리자 페이지의 디렉토리명을 변경시 웹 프로그램에서 관리자 디렉토리의 경로명을 지정하고 있는 경우 웹 프로그램 또한 수정해야 한다
③ 관리자 페이지 웹 서버 인증 설정시 관리자 디렉토리에는 일반 사용자의 접근이 필요한 파일이 존재하지 않아야 한다.
제2절 부적절한 파라미터
1. 취약점 설명
가. 개요
일반적으로 웹 어플리케이션은 HTTP 요청(또는 파일) 값을 통해 다음 동작을 결정하게 되는데 공격자는 URL, 쿼리 문자열, HTTP 헤더, 쿠키, HTML 폼 인자, HTML hidden 필드 등 모든 HTTP 요청을 변조할 수 있으며, 이를 통해 사이트의 보안 메커니즘을 우회하고자 시도한다. 흔히 발생하는 입력 값 변조 공격은 URL 강제 접속, 명령어 삽입, 크로스 사이트 스크립팅, 버퍼오버플로우, 포맷스트링 공격, SQL 구문 삽입, 쿠키 조작, hidden 필드 조작 등으로 불리 운다.
나. 위협 사례
● 인수를 조작하여 시스템 명령어를 실행
Perl , Shell script 등의 스크립트 기반 언어로 짜여진 웹 어플리케이션의 경우, 일반 변수에 특정 문자열을 삽입할 경우 이를 적절히 처리하지 못하고 시스템의 명령어를 실행할 수 있다.
위와 같이 perl로 짜여진 웹 어플리케이션의 경우, 변수인 router에 공격자가 고안한 특별한 문자열과 함께 시스템 명령어를 삽입했을 때, 명령어가 시스템의 내부 명령어가 실행될 수 있다.
변수 값인 R10에 추가되는 공격자의 문자열 ;`ls;ifconfig` 가 시스템 내부에서 실행되어 결과 값으로 출력될 수 있다.
위와 같은 취약점은 스크립트 언어에서 많이 발생되는 것으로 Perl 이나 Shell script 등으로 개발된 스크립트에 대해서 개발자는 작성한 스크립트가 적절하게 변수를 체크하고 있는지, 임의의 문자열에 대해 비정상적으로 동작하지 않는지 소스레벨에서 검토해야 한다.
다. 취약성 판단
웹 어플리케이션에서 주의 깊게 검증되지 않고 사용되는 모든 HTTP 요청은 흔히 “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) 방식"을 사용하여 인자를 검증하여야 한다.
● 데이터 유형 (문자열, 정수형, 실수형 등)
● 허용된 문자셋 (character set)
● 최대 / 최소 길이
● Null 값의 허용 여부
● 반드시 필요한 인자와 그렇지 않은 인자
● 중복 허용 여부
● 숫자의 범위
● 타당한 것으로 지정된 값 (열거형 - enumeration 사용)
● 타당한 것으로 지정된 패턴 (정규식 사용)
웹 어플리케이션 방화벽과 같은 새로운 종류의 보안 장비는 어느 정도 입력값 검증 기능을 제공할 수 있다. 그러나 이런 장비를 효율적으로 사용하기 위해서는 사이트에서 사용되는 모든 인자들에 대해 어떤 값이 타당한 것인지 엄격하게 정의해 놓아야 한다. 이는 곧 URL, 폼 데이터, 쿠키, 쿼리 문자열, HTML hidden 필드 등 모든 유형의 입력값에 대해 적절히 보안하는 것을 뜻한다.
제3절 취약한 세션 관리(Cookie Injection)
1. 취약점 설명
가. 개요
쿠키(Cookie)는 사용자 정보를 유지할 수 없는 HTTP(Hyper Text Transfer Protocol)의 단점을 해결할 수 있는 방법의 하나로서 각 서버는 쿠키를 사용하여 브라우저가 갖고 있는 정보를 참조할 수 있다. 이와 같이 클라이언트에서 동작되는 쿠키는 암호화 등의 문제를 비롯하여 그 구조상 클라이언트 측에서의 조작으로 인한 다양한 문제점을 가지고 있어, 많은 웹 프로그래밍 언어들에는 서버에 클라이언트의 정보를 저장하는 세션(Session)을 지원하고 있다.
적절히 보호되지 않은 쿠키를 사용하면 Cookie Injection등과 같은 쿠키 값 변조를 통하여 다른 사용자로의 위장 및 권한상승 등의 문제가 생길 수 있다. 또한 쿠키 및 세션은 Cookie Sniffing 및 4절에서 이야기 될 악성스크립트실행(XSS)를 통한 Cookie Hijacking등과 같은 쿠키 값 복사를 통해 현재 활성화된 사용자의 권한복제 위험성이 존재한다.
나. 위협 사례
인증을 처리하는 스크립트가 입력 값에 대해 적절히 검사하지 않았을 때 공격자는 Cookie 값을 변조하여 인증과정을 통과할 수 있다.
다. 취약성 판단
● 사이트에 로그인 한 후, 웹 브라우저의 주소 창에 javascript :document. cookie;를 입력해서 내용을 확인한 후, 해당 세션 쿠키를 사용하는 웹 어플리케이션 소스 점검을 통해 불법 변조 탐지 루틴이 있는지 확인한다.
● 모든 인증 자격 증명(credential)과 세션 구분자가 SSL을 이용하여 지속적으로 보호되고 있는지 확인한다.
● 사이트의 인증 메커니즘을 다양한 측면에서 검토하여, 사용자의 자격 증명이 정적인상태(예:디스크에 저장되어 있는 상태)나 전송 중(예:사용자 로그인이 일어나고 있는 순간)에 보호되는지를 살펴보아야 한다.
● 인가된 사용자만이 사용자의 자격 증명을 변경할 수 있는지 점검하기 위해서는, 사용자의 자격 증명을 변조할 수 있는 가능한 모든 메커니즘을 검사하여야만 한다.
● 세션 관리 메커니즘을 점검할 때는 세션 구분자가 지속적으로 보호되고 있는지, 그리고 세션 관리 메커니즘이 사고나 악의적인 공격의 발생 가능성을 감소시켜줄 수 있는지를 검사한다.
2. 보호대책
가. 일반 대책
● 전송 중의 자격 증명 보호
가장 효과적인 방법은 SSL과 같은 기술을 사용하여 로그인 트랜잭션 전체를 암호화하는 방법이다. 서버로 전송하기 이전에 클라이언트 단에서 패스워드를 해쉬하는 형태로 변경하는 단순한 방법으로는 다른 공격자가 실제 패스워드를 모르는 상태에서 해쉬된 정보를 가로채어 서버로 그대로 전송하는 일이 발생하는 경우 별다른 보안을 제공하지 못한다.
● Cookie대신 보안성이 강한 Server Side Session을 사용
Client Side Session 방식인 Cookie는 그 구조상 다양한 취약점에 노출될 수 있으므로 가능한 웹 서버에서 제공되는 Server Side Session을 사용하는 것이 바람직하다.
제4절 악의적인 명령 실행(XSS)
1. 취약점 설명
가. 개요
Cross-site scripting(이하 XSS) 취약점은 웹 페이지가 사용자에게 입력 받은 데이터를 필터링하지 않고 그대로 동적으로 생성된 웹 페이지에 포함하여 사용자에게 재전송할 때 발생한다.
자바스크립트처럼 클라이언트 측에서 실행되는 언어로 작성된 악성 스크립트 코드를 웹페이지, 웹 게시판 또는 이메일에 포함시켜 사용자에게 전달하면, 해당 웹 페이지나 이메일을 사용자가 클릭하거나 읽을 경우 악성 스크립트 코드가 웹 브라우저에서 실행이 된다.
이와 같이 공격자는 XSS 취약점이 존재하는 웹 사이트를 이용하여 자신이 만든 악의적인 스크립트를 일반 사용자의 컴퓨터에 전달하여 실행시킬 수 있는데, 이러한 공격방법을 통해 사용자 쿠키를 훔쳐서 해당 사용자권한으로 로그인하거나 브라우저를 제어할 수 있다.
나. 위협 사례
● Javascript를 이용한 공격
개인 소개와 같은 많은 양의 글을 작성할 수 있는 부분에 XSS 취약점이 존재하여 Javascript를 이용하여 자신의 정보를 열람하는 사용자의 인증정보(Cookie 정보 등)를 탈취한다.
위의 그림처럼 취약점이 존재하는 부분에 적절한 악성코드를 삽입한 후에는 다른 사용자가 해당 사용자의 프로필을 검색할 때 아래 그림과 같이 인증 정보 수집 서버에 Cookie 정보가 저장되며 이를 이용하여 다른 사용자로 접근이 가능하다.
XSS 취약점이 특정한 유형이 있는 것은 아니지만 에러 메시지 출력 부분이나 게시판 또는 사용자의 정보를 입력해 다시 보여주는 부분 등이 주로 취약한 부분이 될 경우가 많다. 특히 사용자 등이 웹 사이트의 고객 불만 센터 등을 이용할 수 있게 해두었을 경우 XSS를 바로 관리자에게 보낼 수 있는 경우를 종종 볼 수 있다.
이러한 코드의 다음과 같은 입력 부분에서 XSS가 주로 발생한다. 웹 사이트를 검색할 때 공격자들이 눈여겨보는 부분이다.
다. 취약성 판단
게시판에 글쓰기와 같이 단문이상의 입력 가능한 부분에 아래와 같이 <script> 태그를 입력한 후 그 부분을 접근할 때 팝업창이 뜨면 취약점이 존재하는 것이다.
2. 보호 대책
가. 유용한 함수들
■ ASP
● Server.HTMLEncode() 메소드를 이용하여 특수문자를 Entity 형태로 변경
- 용도 : 특정 문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한 값으로 HTML 페이지를 구성하기 전에 사용하면 Cross-Site scripting 공격에 효과적이다.
- 적용 가능한 IIS : IIS 5.0이상
- 사용법
<%= Server.HTMLEncode“( <script>alert(document.cookie);</script>”) %>
- 결과
<script>alert(document.cookie);</script>
■ PHP
● htmlspecialchars()를 이용하여 특수문자를 Entity 형태로 치환
- 용도 : 이 함수는 특정 문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한 값으로 HTML 페이지를 구성하기 전에 사용하면 Cross-Site scripting 공격 대비를 위해서 사용할 수 있다.
- 사용법
htmlspecialchars“( <a href=‘test’>Test</a>”)
- 결과
<a href=‘test’>Test</a;>
● strip_tags() 함수를 이용하여 문자열로부터 HTML 태그와 PHP 태그를 제거
- 용도 : 사용자가 입력한 값을 HTML 화면에 출력할 경우 사용하여 Cross-Site scripting 공격에 대비할 수 있다.
- 적용 가능한 PHP 버전 : PHP 3.0.8 이상
- 사용법
A. strip_tags‘( <script>’); : 모든HTML에서<script> 태그를제거한다.
※ htmlspecialchars() 함수를 사용하는 것보다 strip_tags()나 strip_replace() 함수를 사용하여 처리하는 것이 보다 바람직함
제5절 버퍼 오버플로우
1. 취약점 설명
가. 개요
가장 일반적인 취약점의 하나로, 지정된 버퍼의 크기보다 큰 데이터를 저장함으로써 실행 시 오류를 발생시키는 취약성을 말한다. 프로그램이 버퍼 오버플로우를 내재하고 있을 경우, 해커는 이 공격을 이용하여 자신이 원하는 실행코드를 수행할 수 있고, 이 취약점을 이용해 쉘 코드를 실행함으로써 원격에서 Shell을 얻을 수 있게 된다.
공격자는 웹 어플리케이션의 실행 가능한 스택을 덮어쓰기 위해 버퍼 오버플로우 기법을 사용한다. 공격자는 웹 어플리케이션에 조작한 입력 값을 보내어 웹 어플리케이션이 임의의 코드를 수행하도록 할 수 있으며, 이를 이용해 시스템을 효과적으로 장악할 수 있다. 버퍼오버플로우 취약점은 발견하기 쉽지 않으며 발견했다고 하더라도 일반적으로 공격하기가 매우 어렵다. 그럼에도 공격자들은 다수의 제품군과 컴포넌트에 존재하는 버퍼 오버플로우를 발견해 왔다. 유사한 유형의 다른 취약점으로는 포맷 스트링 공격 기법이 있다.
버퍼 오버플로우 취약점은 사이트의 컨텐츠를 제공하는 웹 서버, 웹 어플리케이션 서버 혹은 웹 어플리케이션 자체에 존재할 수 있다. 널리 사용되는 서버 제품군에 존재하는 버퍼오버플로우는 일반에 널리 알려지게 되고 이로 인해 해당 제품의 사용자는 상당한 위험에 노출되게 된다. 이미지를 생성하는데 사용되는 그래픽 라이브러리와 같이 웹 어플리케이션이 사용하는 라이브러리도 버퍼 오버플로우 공격에 노출될 가능성이 있다.
버퍼 오버플로우는 자체 제작한 웹 어플리케이션 코드에도 존재할 수 있으며, 자체 제작한 웹 어플리케이션의 경우 웹 어플리케이션이 전형적으로 갖는 검증 부재 문제로 인해 버퍼 오버플로우가 발생할 확률이 상대적으로 높다. 자체 제작한 웹 어플리케이션의 버퍼 오버플로우 취약점은 비교적 발견하기 어려운데, 왜냐하면 특정한 어플리케이션에만 존재하는 취약점을 발견하여 공격하려는 해커들이 상대적으로 적기 때문이다. 자체 제작 어플리케이션에서 버퍼 오버플로우 취약점이 발견된다하더라도, 해당 어플리케이션의 소스 코드나 상세한 에러 메시지를 일반적으로 해커가 입수하기 어려우므로, 취약점을 성공적으로 공격 할 수 있는 능력이 상당히 제한된다.
대부분의 웹 서버, 웹 어플리케이션 서버, 웹 어플리케이션 환경은 버퍼 오버플로우 가능성이 있으며, 예외적으로 Java와 J2EE 환경은 JVM 자체에 버퍼 오버플로우가 발생하는 경우를 제외하고는 버퍼 오버플로우 공격에 취약하지 않다.
나. 점검방법
서버 제품군과 라이브러리의 경우, 사용하고 있는 제품군에 대한 최신 버그 리포트를 지속적으로 참고하여야 한다. 자체 제작한 어플리케이션의 경우 HTTP 요청을 통해 사용자의 입력을 받아들이는 모든 코드에 대해 임의의 매우 큰 입력 값들을 적절히 다룰 수 있는지 검토해 보아야 한다.
● 버퍼 오버플로우가 발생하는 경우
- 외부로부터 입력된 데이터(사용자 입력, 환경변수, Command-line 파라미터, 파일 등)를 버퍼에 곧바로 입력할 경우
- 입력을 큰 버퍼에서 작은 버퍼로 복사할 경우
2. 보호 대책
가. 일반 보호 대책
웹 서버와 웹 어플리케이션 서버 제품군 혹은 인터넷 환경 상에서 사용되는 제품들에 대해 최신의 버그 리포트를 지속적으로 참고하여, 해당 제품군의 최신 패치를 적용하여야 한다.
버퍼 오버플로우를 방지하기 위한 기초적이며 확실한 방법은 개발자가 프로그램 개발 시부터 입력 값에 대한 검증을 하는 것이다. 사용자입력, 환경변수, 파일, 타 시스템으로부터의 입력 등 다양한 프로그램의 입력에 대한 검증이 필요하다.
자체 제작한 어플리케이션 코드의 경우 HTTP 요청을 통해 사용자의 입력을 받아들이는 모든 코드를 검토하여 입력 값에 대해 적절한 크기를 점검하는지 살펴보아야 한다. 코드 리뷰는 버퍼 오버플로우 공격에 취약하지 않은 환경에 대해서도 수행할 필요가 있다. 왜냐하면 이런 환경에서도 적절한 입력 값 검증을 수행하지 않는 경우 매우 큰 입력 값이 들어오게 되면 서비스 불능 상태(Denial of service)에 이르게 되거나, 다른 운영상의 문제를 일으킬 수 있기 때문이다.
버퍼 오버플로우를 예방하기 위하여 일반적으로 다음과 같은 사항들을 고려한다.
● 범위를 점검하는 안전한 함수를 사용하여 입력에 대한 점검 실시
● ITS4와 같은 코드검사 툴(source code scanner)을 사용하여 버퍼 오버플로우가 발생 가능한 함수에 대한 점검 실시
※ ITS4 : http://www.cigital.com/its4/
● 버퍼 오버플로우의 발생에 대한 검출이 가능한 컴파일러 사용
● 다양한 입력을 사용한 프로그램 테스트
제6절 악의적인 명령어 주입 공격(SQL Injection)
1. 취약점 설명
가. 개요
현재 대부분의 웹 사이트들은 사용자로부터 입력받은 값을 이용해 데이터 베이스 접근을 위한 SQL Query를 만들고 있다. 사용자 로그인 과정을 예로 들면, 사용자가 유효한 계정과 패스워드를 입력했는지 확인하기 위해 사용자 계정과 패스워드에 관한 SQL Query문을 만든다. 이때 SQL injection 기법을 통해서 정상적인 SQL query를 변조할 수 있도록 조작된 사용자 이름과 패스워드를 보내 정상적인 동작을 방해할 수 있다. 이러한 비정상적인 SQL Query를 이용해 다음과 같은 공격이 가능하다.
● 사용자 인증을 비정상적으로 통과할 수 있다.
● 데이터베이스에 저장된 데이터를 임의로 열람할 수 있다.
● 데이터베이스의 시스템 명령을 이용하여 시스템 조작이 가능하다.
이러한 취약점을 SQL Injection 취약점이라고 하며, 사용자가 데이터 입력이 가능한 수 많은 웹 페이지 상에 이러한 취약점이 존재할 수 있다.
나. 위협 사례
(1) 사용자 인증 공격
아래의 그림과 같이 인증을 처리하는 모듈이 입력 값에 대해 적절히 검사하지 않았을 때 공격자는 비정상적인 SQL Query를 삽입 할 수 있고 이를 이용해 사용중인 데이터베이스에 영향을 줄 수 있다.
다음은 SQL 구문을 이용하여 인증을 처리하는 일반적인 웹 페이지 구조를 나타낸다.
이스크립트에공격자가test라는신청인명을입력하고인터넷접수번호대신A’or‘ A’=’A 이란 값을 입력하면 아래와 같은 SQL Query가 완성된다.
이 경우 구문의 WHERE 절은“참 AND 거짓 OR 참”의 WHERE 절이 생성되며 무조건 참이 되어 SQL 구문은 올바른 입력 값으로 처리하게 되며 공격자는 웹 인증 페이지를 쉽게 통과할 수 있게 된다.
(2) MS-SQL상에서의 시스템 명령어 실행
MS-SQL 데이터베이스를 사용하는 경우를 예를 들어 보자. 만약 데이터베이스 접근 권한이 시스템 권한을 사용하고 있다면 MS-SQL에서 기본적으로 제공하고 있는 xp_cmdshell이라는 Stored Procedure를 이용하여 시스템 명령어를 실행할 수 있다.
예로 위의 인증 페이지에서 신청인명에 test, 접수번호에 ’; exec master..xp_cmdshell ‘ping 10.10.1.2’-- 값을 입력했다고 가정하면 SQL Query는 다음과 같이 완성될 것이다.
이 SQL Query는 SELECT Query와 xp_cmdshell Query를 SQL Query가 순차적으로 실행되게 되며, 마지막의 -- 문자는 이후의 모든 문자열을 주석 처리하여 문장을 완성시켜 준다.
(3) 취약성 판단
● 검색어 필드 및 로그인아이디, PASSWD 필드에 큰따옴표(”), 작은따옴표( ’), 세미콜론(;) 등을 입력한 후, DB error가 일어나는지 확인하자.
● 로그인 모듈 점검
- MS SQL인 경우: ID 필드에 [’or 1=1 ;--], 비밀번호 필드에는 아무 값이나 입력한 후 로그인을 시도한다.
- Oracle인 경우: ID 필드에 [’or 1=1 --], 비밀번호 필드에는 아무 값이나 입력한 후 로그인을 시도한다.
● 기타
- ID 필드에[’or“ =’], 비밀번호필드에[’or“ =’]을입력한후로그인을시도한다.
※ 위 예제 이외에도 다양한 방법이 가능하기 때문에, 로그인 및 사용자 입력 값을 사용하는 소스에서 DB Query 생성 방식을 직접 점검해야 한다.
다. 보호 대책
(1) 일반 대책
● 데이터베이스와 연동을 하는 스크립트의 모든 파라미터들을 점검하여 사용자의 입력값이 SQL injection을 발생시키지 않도록 수정한다.
● 사용자 입력이 SQL injection을 발생시키지 않도록 사용자 입력 시 특수문자(' " / \ ; : Space -- +등)가 포함되어 있는지 검사하여 허용되지 않은 문자열이나 문자가 포함된 경우에는 에러로 처리한다.
● SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정한다. 공격자는 리턴 되는 에러 메시지에 대한 분석을 통하여 공격에 성공할 수 있는 SQL Injection 스트링을 알아낼 수 있다. 따라서 SQL 서버의 에러 메시지를 외부에 제공하지 않도록 한다.
● 웹 어플리케이션이 사용하는 데이터베이스 사용자의 권한을 제한한다. 가능하면 일반사용자 권한으로는 모든 system stored procedures에 접근하지 못하도록 하여 웹 어플리케이션의 SQL Injection 취약점을 이용하여 데이터베이스 전체에 대한 제어권을 얻거나 데이터베이스를 운용중인 서버에 대한 접근이 불가능하도록 한다.
● php.ini 설정 변경
: php.ini 설정 중 magic_quotes_gpc 값을 On으로 설정한다.
제7절 업로드 취약점
1. 취약점 설명
가. 개요
대부분의 홈페이지는 사용자들을 위하여 여러 가지 종류의 게시판을 사용하고 게시판들은 파일을 첨부하는 기능 등 다양한 기능을 가지고 있는데 이런 게시판의 첨부파일 업로드 기능을 악용하여 웹 서버의 권한이 노출될 수 있다.
만일 게시판에 업로드 되는 파일의 확장자에 대한 적합성 여부를 검증하는 루틴이 존재하지 않으면 공격자가 조작한 Server Side script 파일을 업로드하고 업로드 된 파일이 서버 상에 저장된 경로를 유추한 후 이 경로를 통해 Server Side script 파일을 실행하여 쉘을 획득할 수 있고 이러한 과정을 통해 웹 서버의 권한이 노출될 수 있다. 쉘 권한 획득 후, 시스템의 명령어를 홈페이지를 통해 실행하고 웹 브라우저를 통해 그 결과 값을 보며 시스템 관리자 권한이나 인근 서버의 침입을 시도 할 수 있다.
특히, 웹 서버 데몬의 구동이 Unix의 root와 같은 시스템 관리자의 권한으로 구동 될 경우, 시스템의 관리자 권한이 공격자에게 그대로 노출될 수 있는 상당히 위험한 보안 취약점이다.
나. 위협 사례
(1) 웹 서버의 게시판에 조작된 Server Side script 파일 Upload
다. 취약성 판단
● 먼저 사용자 게시판에 파일첨부 기능이 있는지 조사한다.
예) 게시판, 공개 자료실, 관리자 자료실, 이미지 자료실 등
● 첨부기능이 존재하는 경우, 확장자가 jsp, php, asp, cgi 등 Server Side script 프로그램을 업로드 하여 업로드가 가능한지 조사한다. 이 때 클라이언트 프로그램에서 Javascript, VBscript 등의 스크립트로 파일첨부를 차단하는 경우 차단기능을 수정하여 파일을 첨부한다.
● 홈페이지에 있는 디렉토리 정보를 이용하여 첨부한 Server Side script 프로그램의 위치를 조사한 후 브라우저 주소 창에서 해당 프로그램을 실행한다.
● 실행 창에서 프로그램 소유자를 조사하거나 중요정보가 존재하는지 조사한다.
2. 보호 대책
가. 일반 대책
첨부 파일 업로드 기능을 통한 스크립트 업로드 및 실행을 금지시킨다.
게시판 첨부파일 업로드, 사진 업로드 모듈등 사용자가 임의의 파일을 서버로 전송할 수 있는 기능을 이용해서 공격자가 작성한 악의적인 스크립트를 서버에 업로드 한 후, 이를 실행시킬 수 있다면 해당 서버는 물론 해당 Application Server와 신뢰관계를 맺고있는 서버들(예, Web DB서버, 내부 연동서버 등)들이 공격당할 수 있는 가능성이 있다. 본 취약점은 게시판 업로드 모듈뿐 아니라 그림 파일을 올리는 기능을 통해서도 발견되고 있기 때문에, 사용자가 파일을 업로드 할 수 있는 모든 모듈에 적용된다.
● Upload 파일을 위한 디렉토리에는 실행설정을 제거(웹 서버)
: Upload 파일을 위한 전용 디렉토리를 별도 생성하여 httpd.conf와 같은 웹 서버 데몬 설정파일에서 실행설정을 제거함으로써, Server Side script가 Upload되더라도 웹 엔진이 실행하지 않게 환경을 설정함
● 첨부파일의 확장자 필터링 처리
: 사용자가 첨부파일의 Upload 시도 시, Upload되는 파일의 확장자를 검토하여 적합한 파일인지를 검사하는 루틴을 삽입하여, 적합한 파일의 확장자 이외의 파일에 대해서는 업로드 되지 않도록 하며, 이런 필터링 규칙은 서버에서 구현해야 한다.
(1) 시스템 보안
웹 서버 구동은 반드시 관리자 권한이 아닌 일반 사용자 권한으로 구동하도록 한다. 외부사용자가 첨부파일을 이용하여 권한을 획득할지라도 최소한의 권한만을 사용할 수 있도록 한다. 업로드 된 디렉토리에서 실행 권한을 제거하는 방법은 임시적이기는 하지만 소스 코드의 수정 없이 간단히 수행 될 수 있다.
● IIS 보안 설정
: 설정 -> 제어판 -> 관리도구 -> 인터넷 서비스 관리자 선택
해당 업로드 폴더에 오른쪽 클릭을 하고 등록정보 디렉토리 실행권한을 “없음”으로 설정
● Apache 설정
: Apache 설정 파일인 httpd.conf에 해당 디렉토리에 대한 문서 타입을 컨트롤하기 위해 Directory 섹션의 AllowOverride 지시자에서 FileInfo 또는 All 추가
파일 업로드 디렉토리에 .htaccess 파일을 만들고 다음과 같이 AddType 지시자를 이용, 현재 서버에서 운영되는 Server Side script 확장자를 text/html로 MIME Type을 재조정하여 업로드 된 Server Side script가 실행되지 않도록 설정한다.
또는 FileMatch 지시자를 이용하여 *.ph, *.inc, *lib 등의 Server Side script파일에 대해서 직접 URL 호출을 금지시킨다.
※ 주의사항
1. Apache 서버의 경우 AllowOverride 지시자를 변경 시 apache restart가 필요하다.
2. 파일 업로드 되는 디렉토리에 운영에 필요한 Server Side script가 존재하는지 확인한다. 파일 다운로드 프로그램이 아닌 직접 URL 호출을 통해 파일을 다운받는 경우 FileMatch 지시자를 사용하면 차단 설정한 확장자의 파일 다운로드는 거부된다.
제8절 다운로드 취약점
1. 취약점 설명
가. 개요
홈페이지 상에서 파일을 다운받거나 업로드 시키는 경우 cgi, jsp, php, php3 등의 프로그램들을 사용한다. 만일 이러한 cgi, jsp, php, php3 등의 프로그램에서 입력되는 경로를 체크하지 않는 경우, 임의의 문자(../.. 등)나 주요 파일명의 입력을 통해 웹 서버의 홈 디렉토리를 벗어나서 임의의 위치에 있는 파일을 열람하거나 다운받는 것이 가능할 수 있다.
나. 위협 사례
● 상대경로를 이용한 파일 접근
상대경로란 ./, ../와 같이 논리적 단위로 이루어진 디렉토리 경로를 말한다. 파일의 이름이나 경로를 다루는 웹 어플리케이션에서 이러한 논리적인 경로를 적절히 처리하지 못하여 웹 어플리케이션이 설치된 디렉토리를 상회하여 시스템 파일이나 지정하지 않은 다른 파일에 접근할 수 있다.
위와 같이 파일을 다운로드 받아야 하는 URL의 경우 공격자는 filename 변수를 ../../../../../../../winnt/win.ini와 같이 상대경로를 이용, 치환해서 시스템 내부의 파일을 불법으로 획득할 수 있다.
파일을 다루는 웹 어플리케이션은 특히 파일의 이름을 변수로 주거나, 이에 대한 입력 값을 사용자로부터 입력받을 때 혹은 관련 웹 어플리케이션으로부터 파일 이름 변수를 넘겨받을 때 해당 변수에 상대경로가 포함되어 있는지 소스레벨에서 검사를 해야 한다. 이를테면 파일의 이름에 ../../../../../../../ 혹은 .\..\..\..\..\..\ 등의 상대경로가 포함되어 있을 때에는 실행을 중단하여 주요 파일로의 불법적인 접근을 차단해야 한다.
다. 취약성 판단
● 게시판 또는 공지사항, 자료실 등에서 cgi, jsp, php 등의 프로그램을 이용하여 파일을 다운받는 페이지가 있는지 조사한다.
● 해당 홈페이지의 파일 다운받기 주소에서 다운받는 파일명을 시스템의 중요한 파일의 위치와 이름으로 치환한 후 웹 주소 창에 입력하여 중요 파일이 다운받아 지는지 조사한다.
● 중요 파일이 다운로드가 되면 해당 취약점이 존재하는 것이다.
2. 보호 대책
가. 서버별 보안대책
● 파일 다운로드의 취약성은 주로 파일의 이름을 조작하는 데서 비롯한다. 다운로드 파일의 이름을 데이터베이스에 저장하고 다운로드 수행 시 요청 파일 이름과 비교하여 적절한지 확인하여 사용자가 조작할 수 있는 변수를 제거하는 것이 바람직하다. 또한 다운로드 위치는 지정된 데이터 저장소를 고정하여 사용하는 것이 바람직하다.
● 프로그램 내에서 파일을 다운받을 수 있는 디렉토리를 특정 디렉토리로 한정하고 이외의 다른 디렉토리에서는 파일을 다운받을 수 없도록 프로그램을 수정한다.
● PHP를 사용하는 경우 php.ini 에서 magic_quotes_gpc 를 On으로 설정하여“.\./”와 같은 역 슬래시 문자에 대해 대응도 가능하다.
제9절 개발 보안 관리
1. 취약점 설명
가. 개요
웹 어플리케이션 개발에 있어서 지켜야 할 보안 사항은 매우 많다. 그 중 첫 번째 해야 할 작업은 서비스에 사용하는 웹 서버와 웹 어플리케이션 서버의 환경 설정에 대해 보안 강화 가이드라인을 만드는 것이다.
나. 개발 보안 가이드
(1) 사용자에게 전달된 값(HIDDEN form 필드, parameter)를 재사용할 경우 신뢰해서는 안된다.
주로 회원정보 변경 모듈에 사용자의 key값(예: id)를 hidden form 필드로 전송한 후, 이를 다시 받아서 update에 사용하는 경우가 있는데, 공격자가 이 값을 변경할 경우 다른 사용자의 정보를 변경할 수 있는 취약점이 존재한다.
● 점검방법
: HTML 소스에서 FORM 필드 확인 후, 해당 값이 어떻게 사용되는지를 소스에서 확인해야 한다.
● 조치방법
: 해당 값의 무 결성을 검사할 수 있는 루틴(예, 해쉬값 비교)의 추가 또는 서버 세션을 사용한다.
(2) 최종 통제 메커니즘은 반드시 서버에서 수행되어야 한다.
Javascript, VBscript 등을 사용한 사용자 입력 값 점검 루틴은 우회될 수 있기 때문에, 서버에서 최종 점검하는 것이 필요하다. 물론 서버의 부하를 줄이기 위해서 1차적으로 클라이언트 레벨에서 점검할 수 있으나 보안 통제 수단으로 사용할 수 없다. 첨부파일 업로드 기능에 스크립트 파일의 전송을 제한하기 위해서 파일 확장자 검사를 script를 사용해서 웹 브라우저 레벨에서 수행할 경우, 공격자는 해당 script를 우회해서 서버에 원하는 스크립트 파일을 전송할 수 있다.
● 점검방법
: HTML 및 웹 어플리케이션 소스 리뷰
(3) 클라이언트에게 중요 정보를 전달하지 않는다.
Java Applet, ActiveX를 사용해서 C/S 어플리케이션을 작성하는 경우, 클라이언트에서 실행되는 컴포넌트에 중요 정보를 하드 코딩해서는 안된다. Cookie에 중요 정보를 전달할 경우 암호화해서 사용해야 한다.
● 점검방법
- HTML 소스 리뷰
- URL 주소에 javascript:document.cookie를 입력해서 쿠키 내용 확인
(4) 중요 정보 전송 시 POST Method 및 SSL을 적용한다.
사용자로부터 중요 정보를 받을 때는 POST Method를 사용해야 하며, 그 중요도에 따라 SSL을 사용한 암호화 통신을 적용해야 한다. SSL은 자료 전송 시 암호화를 지원하므로, 민감한 정보는 어플리케이션 레벨의 암호화를 고려해야 한다.
● 점검방법
: 중요 정보 전달 FORM ACTION에 사용된 프로토콜이“HTTPS”로 되어 있는지 확인함
(5) 중요한 트렌젝션이 일어나는 프로세스에 사용자의 비밀번호를 재확인한다.
사용자의 개인정보변경 프로세스에 비밀번호 재확인하는 루틴을 추가할 경우 불법적인 위장으로 인한 추가 피해를 줄일 수 있다.
● 점검 방법
: 해당 프로세스 확인
(6) 중요 정보를 보여주는 페이지는 캐쉬를 사용하지 못하도록 설정한다.
중요 정보를 보여주는 화면에 no-cache 설정을 하지 않을 경우, 로그아웃을 한 이후에도 [뒤로가기] 버튼을 사용해서 해당 내용을 볼 수 있는 위험이 존재한다.
● 점검방법
: 중요 정보 페이지를 열어본 후, 로그아웃을 한다. 웹 브라우저의“뒤로가기”버튼을 클릭 하였을 때 이전 내용이 보이는지 확인
● 조치방법
- no-cache 설정을 위해서 HTML HEAD 부분에 아래 내용을 추가한다.
(7) 적절한 방법으로 암호화한다.
자체 개발한 암호화 알고리즘 사용을 지양하며, 공인된 암호화 알고리즘(3DES, SEED, AES등)을 사용하는 것을 고려해야 한다. 암호화키를 사용하지 않는 알고리즘은 암호화 알고리즘이 아니라, 단순 인코딩 알고리즘으로 기밀성을 보장할 수 없다. 암호화키는 소스에 hard-coding되어서는 안되며, 제한된 사람만이 접근이 가능하도록 해야 한다.
(8) 각 언어에서 제공하는 보안 수단을 이해한 후 사용한다.
■ Java
● Java Class 역 컴파일 문제
Java 언어의 Byte-code 특성으로 인하여 Java class는 쉽게 역 컴파일이 가능하다. 만약 Java Applet에 중요 정보 (예, 원격지 접속을 위한 ID/PW, DB Query, 직접 제작한 암호화 알고리즘, 프로그램 로직등)을 hard-coding 했다면, 이를 발견한 공격자는 해당 정보를 악용할 수 있는 위험이 존재한다. 따라서 외부로 전송되는 Java class 파일에는 중요 정보를 hard-coding하는 것을 지양해야 한다.
● Sun Microsystems에서 Java 프로그램 개발 시 고려해야할 다양한 보안 사항을 제공하고 있다.
- Secure Code guidelines(Sun Microsystems) :
http://www.java.sun.com/security/seccodeguide.html
■ ASP (Visual Basic, C++, C#등을 사용한 모든 ASP에 적용)
● include 파일을 보호하자.
- 일반적인 디렉토리(/lib, /include, /library 등)를 사용하지 않도록 한다.
- include 파일들의 확장자를 .inc나 .lib등을 사용하는 경우 웹 페이지 상에서 텍스트 파일로 인식하지 않도록 .asp를 붙여서 사용한다.
(예: config.inc.asp, lib.inc.asp등)
- 별도의 확장자를 사용할 경우 아래와 같이 해당 확장자를 처리할 수 있도록 웹 서버에서 설정하여 준다.
● Server.HTMLEncode
- 용도 : 특정 문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한 값으로 HTML 페이지를 구성하기 전에 사용하면 Cross-Site scripting 공격 등에 효과적이다.
- 적용 가능한 IIS : IIS 5.0이상
- 사용법
- 결과
● Session.Abandon
- 용도 : Session 객체에 저장되어 있는 모든 정보를 삭제한다. 사용자 로그 아웃 프로세스에 사용해서 기존 세션 정보를 보호하기 위해서 사용할 수 있다.
- 적용 가능한 IIS : IIS 5.0이상
- 사용법
● Session.Timeout
- 용도 : Session 객체에 Time-out 시간을 분단위로 지정한다. 사용자로부터 지정된 시간동안 요청이 없을 경우 세션이 자동으로 끊어진다.
- 적용 가능한 IIS : IIS 5.0이상
- 사용법
Session.Timeout : 세션 Timeout 시간을 기본값인 10분으로 설정한다.
Session.Timeout = 15 : 세션 Timeout 시간을 명시한다.
(권장 시간 : 4분 ~ 20분)
● ASPError 객체의 output을 사용자에게 전달하지 말자.
● DB 접근을 위해서 COM+ 객체 사용을 고려하자
● SQL 쿼리를 ASP에서 직접 생성하는 것을 지양하고, Stored procedure를 사용하도록고려하자.
- 직접 생성 방식
- Stored procedure를 사용한 생성 방식
■ PHP
● [PHP 4.0 이상] 환경 설정(php.ini) 내용 중 register_global을“on”으로 설정할 경우, PHP 스크립트의 변수 값을 임의로 변경할 수 있는 취약성이 있다. 따라서 register_global은“off”로 설정한 후, $_GET, $_POST 문을 사용해서 사용자가 전달한 값을 얻어야 한다.
● PHP 스크립트 오류를 사용자에게 보내지 않기 위해서 PHP 환경 설정 파일(php.ini)에서 아래와 같이 설정한다.
● utf8_decode()
- 용도 : UTF-8 형식의 입력 값을 ISO-8859-1 형식으로 전환해준다. 필터링 규칙을 적용하기 전에 사용할 것을 권장한다.
- 적용 가능한 PHP 버전 : PHP 3.0.6 이상
● strip_tags()
- 용도 : 문자열로부터 HTML 태그와 PHP 태그를 없앤다. 사용자가 입력한 값을 HTML 화면에 출력할 경우 사용해서 Cross-Site scripting 공격에 대비할 수 있다.
- 적용 가능한 PHP : PHP 3.0.8 이상
- 사용법
strip_tags‘( <script>’); : 모든HTML에서<script> 태그를제거한다.
strip_tags‘( <script>’,‘ <script<iframe>’)
: 첫번째 인자로 전달된 문자열은 제거하고, 두번째 인자로 지정된 태그는 허용한다.
● htmlspecialchars()
- 용도 : 특정 문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한 값으로 HTML 페이지를 구성하기 전에 사용하면 Cross-Site scripting 공격 대비를 위해서 사용할 수 있다.
- 적용 가능한 PHP : PHP 3 이상
- 사용법
- 결과
● addslashes()
- 용도 : DB Query와 같이 인용된 부분앞에 역슬래쉬를 분여서 반환한다. 해당 문자에는 작은 따옴표, 큰 따옴표, 역슬래쉬, NULL이 있다. SQL Injection 공격을 위해서 사용한다.
- 적용 가능한 PHP 버전 : PHP 3 이상
● include 파일을 보호하자.
- 일반적인 디렉토리(/lib, /include, /library등)를 사용하지 않도록 한다.
- include 파일들의 확장자를 .inc나 .lib 등을 사용하는 경우 웹 페이지 상에서 텍스트 파일로 인식하지 않도록 .php를 붙여서 사용한다. (예: config.inc.php, lib.inc.php 등)
- 별도의 확장자를 사용할 경우 아래와 같이 해당 확장자를 처리할 수 있도록 웹 서버에서 설정하여 준다.
● session_destroy
- 용도 : Session 객체에 저장되어 있는 모든 정보를 삭제한다. 사용자 로그 아웃 프로세스에 사용해서 기존 세션 정보를 보호하기 위해서 사용할 수 있다.
- 적용 가능한 PHP 버전 : PHP 3 이상
● 웹 어플리케이션 취약성 점검 도구를 사용한다.
- 웹 어플리케이션 취약성 점검을 위해서 자동화 툴을 사용해서 일반적인 취약점을 제거한다.
- 공개 도구들
Nikto(공개프로그램) - http://www.cirt.net/code/nikto.shtml
Whisker(공개프로그램) - http://www.wiretrip.net
Retina(상용프로그램-eEye) - http://www.eeye.com
제10절 부적절한 환경설정(서버 설정관련)
1. 취약점 설명
가. 개요
부적절한 환경 설정이란 웹 어플리케이션을 운영하는데 있어서 개발자와 시스템 관리자들이 자주 실수로 놓치게 되어 발생하는 문제들을 말한다. 테스트 파일이나 sample 파일, 웹 서버 설치 시 기본적으로 설치되는 파일 또는 관리자나 운영자가 임시로 만들어 놓은 파일들이 아무런 접근 권한 없이 웹 홈 디렉토리에 놓여 있을 경우 일반 사용자가 이 파일명을 직접 입력하여 디렉토리 정보, 시스템정보 및 중요한 파일 정보를 획득할 수 있다.
나. 위협 사례
(1) 백업 파일의 노출
일반적으로 관리자는 홈페이지 상에서 작은 수정을 위해 기존 홈페이지 파일의 원본을 임시로 저장할 수 있다. 혹은 대부분의 Text 전용 에디터의 경우 수정을 위해 기존 원본을 특정 확장자를 사용하여 저장할 수 있다. 문제는 이러한 특정 확장자의 파일들이 서버에서 적절하게 처리되지 못할 경우 소스가 유출 될 수 있다는 것이다.
위 그림과 같이 .bak 파일을 적절히 처리하지 못하여 공격자의 요청에 text 파일 그대로 출력을 할 수 있다. 이러한 소스 유출은 웹 어플리케이션의 보안에 치명적이다.
백업 파일이 웹 서버에 존재는 것은 소스 노출이나 DB정보 노출 등의 문제가 발생할 수 있으므로 웹 서버상의 불필요한 백업 파일들은 모두 삭제하도록 한다.
(2) 디렉토리 리스팅 (Directory Listing 또는 Directory Traversal)
웹 서버에는 현재 브라우징 하는 디렉토리의 모든 파일들을 사용자에게 보여 줄 수 있는 디렉토리 인덱스 기능이 대부분 존재한다. 그러나 이런 설정이 활성화되어 있는 경우 공격자가 웹 어플리케이션의 구조를 파악할 수 있는 기회를 제공해 주며, 민감한 정보가 포함된 설정 파일을 조회할 수 있게 된다. 이것은 보안상 매우 위험하며 따라서 이 기능을 중단시켜야 한다.
웹 서버별로 이러한 기능을 설정하는 옵션이 존재하므로 디렉토리 별로 이러한 디렉토리 리스팅이 불가하도록 설정해야 한다.
(3) 설정 파일 및 환경변수 노출
일반적으로 웹 어플리케이션을 설정하기 위해 위치하는 파일들은 시스템이나 DB에 관련한 많은 정보를 포함하고 있다. 이런 파일들이 공격자에게 노출될 경우 공격자에게 시스템의 많은 정보를 제공하게 된다. 이것은 보안상 매우 위험한 일이다.
일례로 PHP를 사용하는 시스템에는 기본적으로 phpinfo.php 라는 파일이 웹 서버 root 에 설치하거나 또는 개발 시 시스템 환경을 참조하기 위해 직접 작성하여 사용한다. 이 phpinfo.php는 시스템이 정상적으로 설치되었는가와 환경변수에 대한 정보를 포함하고 있다.
대부분의 웹 서버나 웹 어플리케이션의 경우 이를 관리하기 위한 설정파일이 존재한다. 특히 웹 어플리케이션의 경우 웹에서 관리를 하는 경우 이에 대한 설정파일이 외부에 공개되기 쉽다. 이러한 설정파일의 경우 최소한 외부에 공개될 수 있는 것은 줄이는 것이 좋다. 파일의 권한 설정을 통해 이를 막을 수 있다.
(4) 계정 사용 정보 노출
홈페이지 디렉토리 내에 관리상의 부주의로 인해 접속 계정의 히스토리 파일이 남아있는 경우가 있다.
2. 보호 대책
가. 일반 대책
먼저 웹 서버의 종류를 파악하고 이 웹 서버에서 기본적으로 설치되어 있는 파일명을 입력하여 중요한 시스템 정보, 디렉토리 정보 등이 있는지 조사한다. 웹 취약점 점검도구를 이용하여 기본적으로 설치되어 있는 테스트 파일이 존재하는지 조사한다.
■ Apache 보안 강화 설정
● 불필요한 파일 관리
홈페이지 서버에 테스트 파일과 같은 불필요한 파일을 삭제하고 홈페이지 서비스와 관련 없는 디렉토리(백업디렉토리 등)는 일반사용자가 접근이 불가능하도록 적절한 권한(디렉토리 또는 파일 접근권한)을 설정한다.
● 최소한의 사용자 계정 사용
아파치 운영 시 위험을 최소화하기 위해서 최소한의 권한을 가진 사용자 아이디와 그룹으로 생성하는 것이 안전하다. 첫 번째로 이 사용자는 로그인을 할 수 없도록 운영체제의 계정을 다음과 같이 설정한다.
두 번째로 아파치 설정에서는 nobody 권한으로 실행하도록 다음과 같이 설정한다.
위의 설정으로 아파치 구동 프로세스는 한 개의 root 권한의 프로세스와 나머지는 nobody 권한으로 프로세스가 실행된다.
● 디렉토리 Indexes 설정 제거
웹 브라우저에서 사용자가 URL을 입력했을 경우, 아파치 웹 서버는 3가지 경우로 응답한다.
- 정상적인 웹 페이지
- 디렉토리 내용 리스트
- 에러 메시지
이 중 디렉토리 리스트는 공격자에게 불필요한 정보를 제공하여 시스템에 대한 많은 정보를 획득할 수 있는 기회를 제공하는 것이다. 이러한 디렉토리 내의 모든 파일들이 리스팅되는 것을 방지하기 위해서는 아래와 같이 httpd.conf 파일에서 DocumentRoot 항목을 수정해야 한다.
● 심볼릭 링크 사용 설정 제거
유닉스 계열의 시스템인 경우 심볼릭 링크 기능(ln -s / system.html)을 사용하여 다른 위치의 파일이나 디렉토리와 연결하여 사용할 수 있는데 이런 경우 웹에서 허용하는 디렉토리 외에 다른 디렉토리를 참조하는 링크가 존재하는 경우 해당 링크를 엑세스할 수 있는 위험성이 존재한다. 이 위험성을 제거하기 위해서는 디렉토리 리스트와 마찬가지로 httpd.conf 파일에서 DocumentRoot 항목을 아래와 같이 수정한다.
● PUT, POST, DELETE의 제한
원격 사용자가 DocumentRoot 디렉토리에 파일을 업로드하거나 수정하는 등의 행위를 하는 것을 제한하도록 하여야 하는데 이러한 제한이 적절히 이루어지지 않을 경우 홈페이지가 변조되거나 침해를 입을 수 있다.
따라서 POST, PUT, DELETE Method는 제한된 사용자만 가능하도록 하거나 아무도 사용하지 못하도록 다음과 같이 설정한다.
● 헤더 정보 숨기거나 최소화
클라이언트와 Apache가 통신을 할 경우 웹 서버에서는 응답 메시지의 헤더에 웹 서버 버전이나 응용 프로그램 버전 등을 전송한다.
이 정보는 공격자에 의해 Apache 웹 서버 버전별 또는 구동되고 있는 응용프로그램에 잘알려진 취약점을 공격하는데 유용하게 이용되기 때문에 공격자에게 웹 서버의 버전과 같은 banner 정보를 숨기는 것이 안전하다.
Apache 웹 서버에서는 httpd.conf 내용에 ServerTokens 지시자를 삽입하여 헤더에 의해 전송되는 정보를 최소화 할 수 있다.
● 에러 메시지 수정
에러 메시지는 공격자에게 무엇이 틀렸는지 알려주는 표시를 해주며 이로 인해 공격자는 각각의 지시에 대해 다양한 공격 방법을 시도할 수 있게 된다. Apache에서 에러 메시지를 처리하는 방법은 4가지로 나누어진다.
- 간단한 시스템에서 작성된 에러 메시지 출력
- 사용자가 수정한 메시지 출력
- 문제나 에러를 해결하기 위한 로컬 URL을 Redirection
- 문제나 에러를 해결하기 위한 외부 URL을 Redirection
이중 가장 보편적인 방법은 별도의 에러 페이지를 제작하여 각각의 에러코드에 대해 에러 페이지로 Redirection 시키는 방법이다.
httpd.conf 파일에서 아래와 같이 설정한다.
● 관리자페이지 접근통제
관리자페이지는 가장 보호되어야 할 페이지로 매우 제한적으로 접근을 허용하여야 한다. 기본적으로 특정 IP Address에서만 접근을 허용하고 그 외의 모든 접근은 차단하는 것이 바람직하다. 이를 위해 httpd.conf 파일에서 다음과 같이 설정한다.
● 특정 파일의 내용 보기 방지
임의의 사용자가 웹 브라우저에서 특정 파일을 입력함으로서 파일 내용을 볼 수 있는데 이를 방지하기 위하여 환경 설정화일(httpd.conf)에서 아래와 같이 설정한다.
- 아파치 웹 서버의 경우
위에서 AddType application/x-httpd-php는 뒷부분의 확장자 타입(.php .php3 .inc .html .phtml)에 대하여 실행을 시키는 실행파일을 알려 주는 것이다. 따라서 이 부분에 .inc, .bak와 같이 확장자를 입력 시 application /x-httpd-php을 통하여 동작시키므로 파일 내용을 보여주지 않게 되는 것이다.
- CGI의 경우
httpd.conf에서 다음과 같이 설정한다.
- PHP의 경우
PHP를 사용하여 개발하는데 있어 Error나 Warning 메시지를 자주 접하게 되는데 이 메시지는 오류메시지가 발생된 CGI의 물리적인(또는 시스템상의) 위치와 에러 부분을 표시하여 준다. 이를 이용하여 공격자는 /lib, /inc, /admin등 보여지지 말아야할 정보가 노출되는 위험성을 가지고 있다. 이를 제거하기 위해서는 php.ini내의 설정 중에서 display_errors 값을 Off로 설정하여 준다.
또, PHP에서는 각 코딩 라인에 @을 사용하여 해당 라인의 에러 메시지를 출력하지 않는 방법을 제공한다.
● 주요 파일시스템 설정 변경
최근 많이 발생한 웹 해킹의 경우, 악성 프로그램을 /tmp, /dev/shm등의 디렉토리에 악성 프로그램을 업로드 하는 경우가 많으므로 /etc/fstab의 내용을 수정하여 해당 디렉토리의 실행권한을 제거하도록 한다.
변경 후에는 mount 명령을 실행하여 변경 내용을 적용한다.
또한, apache 웹 서버의 설정파일이 위치하는 디렉토리의 권한을 700으로 변경하여 하도록 한다. (예: chmod 700 /usr/local/apache/conf)
제 4 장 결 론
홈페이지 해킹사고는 단순한 홈페이지 변조 수준에서 그칠 뿐만 아니라 이를 이용하여 피싱 사이트로 악용하거나 고객의 정보를 유출하여 악용하는 등의 범죄적인 성향으로 발전하고 있다.
홈페이지 서버는 인터넷을 통해 누구에게나 열려져 있는 시스템이며 홈페이지를 통해 볼 수 있는 정보도 내부 DB와의 연동에 의해 고객 정보, 회사 내부 자료 등 금전적으로 가치있는 정보들이 저장되고 있어 공격자에게는 상당히 매력적인 공격대상이 되고 있다. 이처럼 홈페이지의 활용도 및 중요도가 갈수록 증가하고 있으므로 홈페이지에 대한 해킹시도도 줄지 않을 것이다.
하지만 많은 홈페이지 개발자 및 관리자들은 홈페이지 보안의 중요성을 인식하지 못하고 있어 많은 국내 홈페이지가 해외 해커에 의해 공격당하는 사고가 빈발하고 있는 실정이다.
비용 효율적으로 안전한 홈페이지를 구축하기 위해서는 구축이후가 아닌 설계∙구축단계에서 먼저 정보보호를 고려하는 것이 중요함을 다시 한번 강조하고자 한다. 특히, 다수의 사용자들이 사용하는 패키지 형태의 웹 어플리케이션들은 이들의 보안 취약점이 배포 이후에 발견되어 보안조치를 취할 경우 이 어플리케이션을 사용하여 홈페이지를 구축한 수많은 사용자들이 다시 패치를 적용하여야 하는 불편함과 비용이 소요될 수 밖에 없다.
본 가이드는 최근 발생되고 있는 홈페이지 해킹사고의 주요 원인이 웹 어플리케이션의 보안취약점에 있다는 사실에 따라 웹 어플리케이션 개발시 고려하여야 하는 사항 및 코딩 예를 소개하고, 국내 주요 웹 어플리케이션의 보안대책에 대해 소개하였다. 본 가이드가 홈페이지 개발자 및 운영자가 홈페이지 보안성 강화하는데 실질적인 도움이 될 수 있었으면 한다.
출처 : 
|
[원글링크] : https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1698
 |
인터넷 침해사고대응지원센터의
허락하에 본 사이트에서 pdf 파일 형식으로 배포 됩니다. |
|
|
|
|
