에 의해 비교적 쉽게 해결이 가능했다.
최근 해킹의 화두는 웹 애플리케이션의 취약성을 이용하는 것이다. 그러한 이유를 위에서 언급된 내용을 토대로 말하자면 요즘 대부분의 기업이나 기관들은 시스템의 패치나 구성설정 변경을 제대로 하고 있지 못하더라도 접근 통제 솔루션을 하나 이상은 갖추고 있어서 외부로부터 유입되는 부적절한 접근으로부터 내부의 시스템을 보호할 수 있는 장치를 마련하고 있다. 그러나 이러한 솔루션이 갖추어져 있더라도 필수 불가결하게 서비스해야 하는 것이 바로 웹 서비스이다. 접근 통제 솔루션은 웹 서비스로 접근하는 패킷을 통제하지 않고 내부로 유입시키기 때문에 만약 통과되는 패킷에 악의적으로 패킷을 조작해서 보낸다면 정상 패킷으로 간주하여 적절한 통제를 하지 못하게 된다.
이러한 배경을 토대로 이제까지 발표되어 악용되었던 웹 애플리케이션 취약성 유형을 크게 10가지로 나눌 수 있는데 이번 호에는 그 중 3 가지 취약성에 대해 설명하고 간략하게나마 취약성을 예방할 수 있는 방법을 소개하겠다. 좀더 자세한 내용을 원한다면 코코넛 시큐리티 레터 8월호의 참고 자료를 참조하면 된다.
1. 검증되지 않은 파라미터의 허용(Unvalidated Parameters)
클라이언트로부터 웹 애플리케이션이 요청을 받았을 때 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 백엔드에 존재하는 허가되지 않은 자원에 접근할 수 있는 취약성이다. url, 쿼리 문, HTTP 헤더, 폼 필드, 쿠키, 그리고 숨겨진 필드 등의 웹 요청(HTTP request) 들을 강제로 브라우징 한다거나 명령어 삽입, SQL 문 삽입, 쿠키 위/변조등을 통해서 보안 메커니즘을 우회할 수 있게 된다.
[예방 방법]
웹 요청에 대한 잘못된 예외 규칙을 다음과 같이 정하여 소스 코드에서 철저하게 검증을 하는 것이다.
- 데이터 형식(문자, 정수, 실수 등)
- 허용되는 문자셋
- 최소, 최대 허용 길이
- NULL 값의 허용 여부
- 파라미터의 허용 여부
- 허용되는 숫자 범위
- 정규 표현식 등
2. 부적절한 접근 통제(Broken Access Control)
인증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있는 취약성이다. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉터리를 읽을 수 있는 등의 경로 유출(Path Traversal)을 허용하는 것이다. 이러한 취약성은 웹 컨텐츠와 기능에 적절한 접근 통제를 하지 못하는 것이 원인이다.
[예방 방법]
다음과 같은 접근 통제를 점검한다.
- 안전하지 않은 ID 점검
- 절대 경로를 통한 인증 회피 가능 점검
- Path Traversal 가능 점검
- 웹 컨텐츠의 퍼미션 점검
- 클라이언트 측의 케싱 점검
3. 부적절한 계정과 세션 관리(Broken Account and Session Management)
계정에 대한 증명(Account Credential)
과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션 쿠키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다.
[예방방법]
다음과 같은 항목들에 대해 보안 정책을 강화한다.
- 패스워드 변경 통제
- 패스워드 복잡성
- 패스워드 저장
- 전송 중인 증명서 보호
- 세션 아이디 보호
- 계정 목록
- 신뢰 관계
- 백엔드 인증
4. 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)
Cross-site Scripting 취약점은 공격자가 웹 애플리케이션을 사용해서 다른 최종 사용자에게 자바스크립트와 같은 악성 데이터를 보낼 때 발생한다. 그 데이터는 클라이언트에서 실행되는 Java스크립트, VB스크립트, ActiveX, Flash등을 실행하는 코드들이 존재하게 된다. 최종 사용자들은 이렇게 악성 코드들이 포함된 웹 사이트의 링크를 클릭하거나 이메일에 포함된 내용을 읽거나 BBS에 게시된 게시물을 클릭하는 것만으로도 사용자의 환경 설정사항을 변경하거나, 쿠키(cookie)를 가로채고 잘못된 광고들 게시하는 등의 일들을 할 수 있다.
[예방 방법]
해당 취약점을 예방할 수 있는 최선의 방안은 모든 코드들을 상세히 검증하는 것이다. 즉, 헤더, 쿠키, 질의문, 폼 필드와 숨겨진 필드등과 같은 모든 파라미터들을 엄격한 규칙에 의해서 검증한다. 또한 다음과 같이 왼쪽의 필드의 입력 데이터를 오른쪽의 필드로 변환해서 필터링한다.
| From | To |
| < | & l t; |
| > | & g t; |
| ( | & # 4 0; |
| ) | & # 4 1; |
| # | & # 3 5; |
| & | & # 3 8; |
5. 버퍼 오버플로우(Buffer Overflows)
버퍼오버플로우의 자세한 내용은 코코넛 시큐레터 6월호의
[예방 방법]
운영하고 있는 웹 서버 버전을 가장 최신버전으로 업그레이드 하거나 알려진 취약점을 제거할 수 있는 패치를 적용한다. 정기적으로 취약점 스케너를 통해서 취약점 여부를 점검하여 발견된 취약점에 대해서는 구성 설정을 변경하거나 패치를 적용하여 취약점을 제거한다.
6. 시스템 명령어 삽입 허용(Command Injection Flaws)
웹 애플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입 허용함으로써 웹 상에서도 시스템 명령을 실행할 수 있는 취약점이다. SQL 쿼리문을 삽입 허용하게 되면 DB인증 메커니즘을 무력화시켜서 중요한 데이터베이스 정보를 외부로 유출할 수 있다. 또한 데이터베이스의 DML(Data Manipulation Language), DDL(Data Definition Language) 언어가 모두 사용 가능하므로 데이터베이스의 유출뿐만이 아니라 무결성을 파괴할 수도 있다.
다음은 시스템 명령 삽입 허용 취약점을 악용할 수 있는 스크립트, 프로그래밍 언어의 함수들이다.
PHP
- require()
- include()
- eval()
- preg_replace() (/e 옵션과 함께 사용)
- exec()
- passthru()
- `` (backticks)
- system()
- popen()
Shell Scripts
- 모두 실행 가능
Perl
- open()
- sysopen()
- glob()
- system()
- '' (backticks)
- eval()
Java(Servlets, JSP s)
- System.* (특별히 System.Runtime)
C,C++
- system()
- exec**()
(strcpy strcat sprintf vsprintf gets strlen (특별히 null 바이트와 함께 사용될 경우) scanf() fscanf sscanf vscanf vsscanf vfscanf realpath getopt getpass streadd strecpy strtrns)
Python
- exec()
- eval()
- execfile()
- compile()
- input()
[예방 방법]
- 반드시 필요하다면 모든 시스템 명령을 사용하는 모든 사용자의 입력값을 점검한다.
- 점검되지 않은 사용자 입력을 시스템 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 파이프(|)로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 perl의 open() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 C 언어와 PHP의 popen() 명령으로 전달하지 않는다.
- 점검되지 않은 사용자 입력을 ``(backticks)
과 함께 사용하지 않는다.
- 운영체제의 시스템 명령이 사용자 입력에 존재하는지 점검한다.
- 모든 웹 애플리케이션엔 쉘 스크립트를 허용하지 않는다.
7. 잘못된 오류 처리(Error Handling Problems)
적절하지 못한 오류 처리는 웹 사이트에서 다양한 보안 문제를 야기한다. 가장 보편적인 문제는 데이터베이스 덤프, 에러 코드등과 같은 상세한 내부 메시지들이 사용자에게 노출된다는 것이다. 이러한 정보들은 바로 악용 가능하지는 않지만 향후 발생할 수 있는 공격에 정보를 제공하게 된다. 이러한 문제를 야기하는 원인은 다음과 같다.
- 스크립팅 엔진의 설정 오류
- Servlet/JSP Runner의 설정 오류
- 웹 서버의 설정 오류
- 데이터베이스의 설정 오류
이러한 문제를 통해 유출될 수 있는 정보들은 다음과 같다.
- 애플리케이션의 흐름
- 추가적인 웹 서버 정보
- 데이터베이스 형식 및 버전
- 운영체제 형식 및 버전
- Scripting/Programming 언어의 형식 및 버전
- 물리적인 경로
- 변수 이름과 값
- 변수 형식
- 변수의 사용 목적
- 스크립트 소스 코드의 세그먼트
- SQL 쿼리의 세그먼트
- 데이터베이스와 테이블의 구조
[예방 방법]
웹 애플리케이션이 잘못된 요청을 받았을 때 자체 제작한 오류 페이지로 이동하도록 설정한다.
8. 안전하지 않은 암호화 메커니즘 사용(Insecure Use of Cryptography)
대부분의 웹 애플리케이션은 패스워드, 신용카드 번호, 계정 기록과 같은 중요한 정보나 데이터베이스를 저정하고 있기 때문에 암호화 기술을 이용하여 보호하고 있다. 이러한 암호화 기술이 웹 애플리케이션에 적용될 때 다음과 같은 구현상의 오류로 인하여 보안 허점들을 내포하게 된다.
- 안전하지 않은 키, 인증서와 패스워드 저장
- 적절하지 못한 메모리상의 기밀 저장
- 잘못된 난수 소스
- 중요 데이터 암호화 실패
- 새로운 암호화 알고리즘 개발 시도
- 암호화 키 변경과 같은 추가적인 지원 부재
[예방 방법]
이러한 취약점을 예방하기 위해서는 암호화 사용을 최소화 해야한다. 즉, 신용카드 번호와 그와 관련된 정보와 같이 중요하다고 판단되는 정보만을 암호화한다. 또한 저장된 암호화된 패스워드를 사용하는 대신 단방향 함수인 SHA-1과 같은 해쉬함수를 사용한다.
9. 원격 관리 허점(Remote Administration Flaws)
웹 애플리케이션을 관리하기 위해 강력한 기능을 갖는 원격 관리 도구들이 많이 존재한다. 그러한 기능들은 사용자들, 데이터, 그리고 웹 사이트의 컨텐츠들을 관리 가능하게 한다. 이러한 강력한 기능 때문에 원격 관리 도구들은 내/외부에서 공격자들의 주요 목표가 된다. 가장 일반적인 문제점은 원격 관리에 접근할 수 있는 강력한 인증 메커니즘이 갖춰져 있지 못한 이유로 인해 허가되지 않는 사용자에 의해서 웹 애플리케이션의 기밀성과 무결성, 그리고 가용성이 파괴될 수 있다.
[예방 방법]
ACL(Access Control List)을 이용하여 원격 관리 도구에 접근할 수 있는 대상을 엄격히 제한한다. 또한 VPN를 사용하여 관리자와 원격 관리 도구간에 암호화 통신을 한다.
아래 그림은 단계별 방어가 적용되기 전(그림 1)과 단계별 방어가 수립된 후(그림 2)
의 네트워크 구성을 나타낸 것이다. 그림 2처럼 단계적으로 방어 대책이 수립된다면 관리자와 일반 사용자의 네트워크가 분리되며 시스템 용도별로 네트워크가 분리되어 단계별로 보안 대책이 수립되기 때문에 안전한 네트워크 운영이 가능하게 된다.
가 적용 된 상태
10. 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration) 설정
웹 서버와 애플리케이션의 구성 설정은 보안 측면에서 중요한 의미를 가진다. 그러한 구성 설정들이 다음과 같은 여러 가지 요인들로 인해 보안 문제를 야기할 수 있다. 이러한 보안 문제들은 자동화된 스케닝 도구에 의해 공격자들에 의해 공격 당할 가능성이 매우 높다.
- 서버 소프트웨어에 있는 패치되지 않은 보안 취약점들
- 디렉터리 리스팅과 디렉터리 경로 유출을 허용하는 잘못된 서버 구성 설정
- 스크립트, 애플리케이션 환경 설정 파일과 웹 페이지가 포함된 불필요한 기본 파일, 백업 파일, 샘플 파일들
- 부적절한 파일, 디렉터리 권한 설정
- 컨턴츠 관리와 원격 관리가 가능한 불필요한 서비스 활성화
- 기본 패스워드로 설정된 기본 계정
- 관리와 디버깅 목적의 기능들
- 정보가 유출될 수 있는 잘못된 에러 처리
- 잘못 설정된 SSL 인증서와 암호화 설정
- 기본 인증서 사용 등
[예방 방법]
① 여러 보안 관련 사이트(SANS institute, OWASP, CERT)나 자료 등에 언급되어 있는 보안 가이드라인을 참고하여 다음과 같은 조치들을 취한다.
- 고려할 수 있는 모든 보안 메커니즘들 구성
- 모든 불필요한 서비스 중지
- 역할(roles), 퍼미션(permissions), 계정(accounts)
- 로깅과 경고
② 1번과 같이 보안 가이드라인이 만들어졌다면 다음과 같은 작업들을 주기적으로 실시한다.
- 가장 최근에 발표된 보안 취약점 모니터링
- 가장 최신의 보안 패치 적용
- 보안 가이드라인의 업데이트
- 정기적인 내/외부 취약점 스캐닝
이 글을 마무리 하며
서두에도 언급했듯이 최근의 해킹 동향은 웹 애플리케이션을 이용한 해킹이 전체 피해 건수의 약 3/4를 상회하고 있다. 이러한 배경으로 인해 기업에서는 추가적인 보안 솔루션(웹 애플리케이션 취약점 스캐너, 웹 애플리케이션 방화벽 등)을 도입하고 있거나 도입 계획을 세우고 있다. 그러나 모든 보안이 그렇듯이 솔루션을 도입한다고 해결되는 것도 아니고 사람이 뛰어나다고 해결되는 것도 아니다.
도입된 솔루션이 제대로 운영되기 위해 끊임없이 관리자들은 노력해야 할 것이며 웹을 개발하는 개발자들은 만들어진 보안 가이드라인을 준수하여 개발해야 하며 일반 사용자들 또한 보안 가이드라인에 준하는 행동으로 발생할 수 있는 인지된 사고를 미연에 방지해야 한다. 이처럼 기업의 모든 구성요소들이 적절하게 조화를 이뤄 야지만이 투자된 비용만큼의 보안 수준을 유지할 수 있게 된다.
[참고 자료]
The Ten Most Critical Web Application Security Vulnerabilities(http://www.owasp.org/asac)
A Guide to Building Secure Web Applications (http://www.owasp.org)
Security at the Next Level (http://www.spidynamics.com/whitepapers.html)
Information Security (http://infosecuritymag.techtarget.com/2002/jun/insecurity.shtml)
CERT (http://www.cert.org)
SANS Institute (http://www.sans.org)
Hacking Exposed - Web Applications
내용출처 : [기타] (주)코코넛 시큐레터 8월호
(출처 : '[해킹기법과 대응] ③ 웹 애플리케이션 해킹 (Web Application Hacking)' - 네이버 지식iN)
