OWASPTESTINGGUIDE2008v3.pdf아래는 2004년 자료임.
취약점 환경 설정과 부주의, 취약한 소프트웨어로 인하여 WWW 연결을 통해 보안상 심각한 문제가 유발될 수 있다 . www 서비스는 공개적으로 서비스를 제공하는 형태로 설계되었으며, 일반적으로 주요한 내부 자원을 외부에 제공하는 기능을 하도록 설계되었다. 따라서 이전의 외부로 부터의 접근통제가 가능하였던 보안솔루션에 의해 공격자를 막는 것은 사실상 불가능 하다.
OWASP(open web application security project) 10대 취약점을 요약하면 다음과 같다.
1. 검증되지 않은 파라미터의 허용 (Unvalidated Parameters)
웹 요청 정보가 웹 애플리케이션에 의해 처리되기 이전에 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 허가되지 않은 자원에 접근할 수 있는 취약성이다.
URL, 쿼리문, HTTP헤더, 폼 필드, 쿠키, 그리고 숨겨진 필드 등의 웹 요청 (HTTP request)들을 강제로 브라우징 한다거나 명령어 삽입, SQL문 삽입, 쿠키 위/변조 등을 통해서 보안메커니즘을 우회할 수 있게 된다
[ 대처 방안 ]
다음과 같이 스펙 상에 허용된 값만을 받아들이는 “허용(Positive)방식”을 사용하여 인자를 검증하여야 한다.
● 데이터 유형 (문자열, 정수형, 실수형 등)
● 허용된 문자셋 (Character set)
● 최대 / 최소 길이
● Null값의 허용 여부
● 반드시 필요한 인자와 그렇지 않은 인자
● 중복 허용 여부
● 숫자의 범위
● 타당한 것으로 지정된 값 (열거형 - enumeration 사용)
2. 부적절한 접근 통제 (Broken Access Control)
인증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있는 취약성이 다. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉토리를 읽을 수 있는 등의 경로 유출 (Path Traversal)을 허용하는 것이다. 이러한 취약성 은 웹 컨텐츠와 기능에 적절한 접근 통제를 하지 못하는 것이 원인이다.
[ 대처 방안 ]
다음과 같은 접근 통제를 점검한다.
● 취약한 ID - 대부분의 웹 사이트는 일정한 형태의 아이디, 키,인덱스를 사용하여 각 사용자와 역할, 컨텐츠, 접근 대상, 기능들을 구분한다. 공격자가 이런 값들을 유추할 수 있고, 입력받은 값들이 현재 사용자에게 허 용된 적절한 값인지를 검증하지 않는다면, 공격자는 무엇에 접근할 수 있는지를 파악하기 위해 접근 통제 메 커니즘을 이리저리 조사해볼 것이다. 웹 애플리케이션의 보호를 위해 특정한 아이디 값이 가진 비밀에 의존 해서는 안된다.
● 접근통제 점검을 우회하기 위한 강제접근(forced browsing) - 많은 사이트들은 사용 자가 내부 ‘깊숙이’숨어있 는 특정한 URL에 접소하는 것을 허용하기 이전에, 특정한 검사를 통과하도록 요구한다. 이런 검사는 단순히 보안 검사를 수행하는 페이지를 우회하는 것만으로 통과 가능해서는 안된다.
● 경로이동 (Path traversal) - 이런 종류의 공격은 정보를 요청하는 일부분에서 상대 경로(예를 들면 “../../target_dir/target_file")을 사용하는 것과 관련이 있다. 이런 공격은 정상적인 방법으로는 직접적으로 접근 불가능하거나, 직접적으로 접근하는 경우 서버 측에서 거부하는 파일들에 접근하려고 시도할 때 사용한다. 이런 공격은 URL 이나 궁극적으로는 파일에 액세스하는데 사용되는 값(즉 시스템 콜이나 쉘 명령어)를 서버측에 요 청할 대 사용할 수 있다.
● 파일 허가권 - 많은 웹 서버와 웹 애플리케이션 서버는 OS의 파일 시스템에 의해 제공되는 접근 통제 항목에 의존하고 있다 비록 거의 모든 데이터가 백엔드 서버에 저장되어 있다 하더라도, 웹 서버나 웹 애플리케이션 서버에 로컬로 저장되어 외부에서 접근할 수 없는 파일들은 항상 있게 마련이다. 이런 파일들에는 특정한 환경 설정 파일, 디폴트 예제 파일, 상당수의 웹 서버나 웹 애플리케이션 서버에 설치되는 예제 스크립트들이 있다. 웹 사용자들에 의해 접근 가능한 파일들만이 OS의 허가권 메커니즘으 사용해 명시적으로 읽기 가능하도록 설 정되어야 하며, 대부분의 디렉토리에 대해선 읽기 권한을 제거해야 한다. 필요한 경우 극소수의 파일들에 대해 서만 실행 권한을 주어야 한다.
● 클라이언트 측 캐쉬 - 많은 사용자들이 도서관, 학교, 공항, 혹은 다른 공공 장소에 설치된 공용 컴퓨터에서 웹 애플리케이션에 접속한다. 브라우저는 종종 웹 페이지를 캐쉬하는데, 이 캐쉬된 정보는 공격자가 이외의 다른 방 법으로는 접근할 수 없는 사이트에 접속하기 위해 필요로 하는 정보이다. 개발자는 HTTP 헤더, 메타 태크 등 다 양한 메커니즘을 사용하여 민감한 정보가 담겨있는 페이지가 사용자의 브라우저에 캐쉬되지 않도록 보장해야 한 다.
3. 부 적절한 계정과 세션 관리(Broken Account and Session anagement)
계정에 대한 증명 (Account Credential)과 세션 토큰이 적절히 보호되지 못함으로 인해 패스워드나 키, 세션쿠 키, 그리고 다른 토큰 등을 악용하여 인증 메커니즘을 무력화 시키거나 다른 사용자의 아이디를 추측할 수 있는 취약성이다. 예를 들자면 사용자의 패스워드 변경, 패스워드 분실, 사용자 정보 수정 등을 포함하는 증명서와 동 적 세션 관리가 적절히 개발되지 않아서 다른 사용자에 의해 추측되거나 가로채기를 당하는 것이다 .
[대처방안]
다음과 같은 항목들에 대해 보안 정책을 강화한다
● 강력한 패스워드 - 패스워드는 최소 길이와 복잡도에 제한을 두어야 한다. 일반적으로 복잡한 패스워드라 함 은 최소한 알파벳,숫자, 특수문자(최소 한 개 이상)을 조합하는 것을 요구한다. 사용자는 주기적으로 패스워드 를 변경하여야만 하며, 이전에 사용하던 패스워드를 재사용하지 못하도록 해야 한다.
● 패스워드 변경 통제 - 사용자의 패스워드 변경이 허용된다면, 패스워드 변경 메커니즘은 어떤 상황에서도 단 하나만을 사용하여야 한다. 사용자가 패스워드를 변경할 때는 다른 계정 정보를 변경할 때와 마찬가지로 항상 이전 패스워드와 신규 패스워드를 물어보아야 한다. 해당 시스템 상에서 분실된 패스워드를 사용자에게 전자 메일로 발송한다면, 사용자가 전자 메일 주소를 바꾸려고 할 때도 항상 이런 인증 절차를 거치도록 해야 한다. 그렇지 않은 경우 공격자가 일시적으로 다른 사용자의 세션을 이용해 접속하여 (예를 들면, 다른 사용자가 로그 인해 있는 상태로 자리를 잡시 비운 사이 컴퓨터 앞으로 걸어가서) 해당 전자 메일 주소를 변경하고, ‘분실한’ 패스워드를 메일로 보내 달라고 요청하는 상황이 벌어질 수 있다
● 패스워드 저장 - 모든 패스워드는 유츌 사고로부터 보호하기 위해, 어디에 저장되는지에 상관없이 해쉬된 형 태나 암호화된 형태로 저장되어야만 한다. 보통 해쉬 방식을 선호하는데 이 정보는 복호화할 수 없기 때문이다. 평문 패스워드를 사용하면서 이 패스워드를 전달하여 다른 시스템에 로그인 하는 경우에는 반드시 암호화를 사 용하여야만 한다. 패스워드는 소스 코드 내부에 하드 코딩하는 일이 없어야 한다. 복호화에 사용되는 키는 해당 키를 습득하여 패스워드 파일을 복호화 하는데 사용할 수 없도록 강력하게 보호되어야만 한다.
● 전송 중의 자격 증명 보호 - 가장 효과적인 방법은 SSL과 같은 기술을 사용하여 로그인 트랜잭션 전체를 암호 화하는 방법이다. 서버로 전송하기 이전에 클라이언트 단에서 패스워드를 해쉬하는 형태로 변경하는 단순한 방 법으로는, 다른 공격자가 실제 패스워드를 모르는 상태에서 해쉬된 정보를 가로채어 서버로 그대로 전송하는 일 이 발생하는 경우 별다른 보안을 제공하지 못한다.
● 세션 ID보안 - 사용자의 전체 세션은 이상적으로는 SSL을 이용하여 보호되어야만 한다. 이런 경우에는, 세션ID 유출을 불러오는 가장 심각한 위험인 세션 ID(예를 들면 세션 쿠키)를 네트워크 상에서 도청하는 방법이 별 소용 이 없다 . 그러나 속도 문제 혹은 다른 이유로 인해 SSL을 사용할 수 없는 경우라면, 다른 방법을 사용하여 세 션ID를 보호하여야만 한다. 첫째로, 세션 ID는 충분히 길고 복잡한 난수여서 손쉽게 추측할 수 없어야 한다. 세 션 ID는 세션이 유지되는 중에도 자주 바뀌어 세션 ID 가 타당하다고 받아들여지는 시간을 줄여야 한다. 세션 ID 는 SSL로 전환되는 시기, 인증을 거칠 때 혹은 다른 중요한 변화가 있는 시기에 다른 값으로 변경되어야 한다. 사용자가 세션ID를 임의로 선택하여 사용하는 일은 허용되지 않아야 한다.
● 계정 리스트 – 시스템은 사이트의 계정 리스트에 사용자가 접근하는 것을 허용하지 않도록 설계되어야만 한 다. 사용자 리스트를 반드시 제공해야 한다면, 직접적으로 계정명을 제공하기 보다는 별명(예명)과 같은 다른 형태를 제공하기를 권한다. 이렇게 하는 경우, 해당 별명을 이용해 로그인 시도를 할 수 없으며, 사용자계정을 공격하기 위한 다른 해킹을 시도할 수 없다.
● 브라우저 캐쉬 – 인증 및 세션 관련 정보는 GET 요청의 일부에 포함되어 전송되어선 안된다. 이런 경우에는 대 신 POST 요청을 사용하여야 한다. 인증 페이지는 다양한 형태의 캐쉬 금지 태그를 이용함으로써 사용자가 브 라우저의 ‘뒤로’ 버튼을 이용하여 인증 페이지로 돌아가지 못하도록 하고, 이전에 사용한 사용자 자격 증명을 재사용하지 못하도록 하여야 한다. 요즘의 여러 브라우저들은 autocomplete=false 플래그를 지원하여, 사용자 자격 증명을 자동완성 캐쉬에 저장하지 못하도록 하고 있다.
● 신뢰 관계 – 사이트의 아키텍쳐 상에서 가능한한 각 컴포넌트들 사이의 암묵적인 신뢰 관계를 피해야 한다. 각각의 컴포넌트는 그래서는 안되는 절대적인 이유가 있는 경우(속도나 가용성 문제와 같은)를 제외하고는, 서로 관련을 맺고 있는 다른 컴포넌트에 대해 인증을 수행토록 해야한다. 만일 신뢰 관계가 필요한 경우라면 강력한 절차상의 메커니즘 혹은 아키텍쳐 메커니즘을 사용하여 사이트의 아키텍쳐가 지속적으로 변화하더라도 이러한 신뢰 관계가 악용될 수 없도록 해야 한다.
4. 크로스 사이트 스크립팅 허점(Cross-Site Scripting(XSS) Flaws)
Cross-site Scripting 취약점은 공격자가 웹 애플리케이션을 사용해서 다른 최종 사용자에게 자바스크립트와 같은 악성 데이터를 보낼 때 발생한다. 그 데이터는 클라이언트에서 실행되는 Java스크립트, VB스크립트, ActiveX, Flash등을 실행하는 코드들이 존재하게 된다. 최종 사용자들은 이렇게 악성 코드들이 포함된 웹 사이트의 링크를 클릭하거나 이메일에 포함된 내용을 읽거나 BBS에 게시된 게시물을 클릭하는 것만으로도 사용자의 환경 설정사항을 변경하거나, 쿠키(cookie)를 가로채고 잘못된 광고들 게시하는 등의 일들을 할 수 있다.
[대처 방안]
XSS 공격으로부터 웹 애플리케이션을 방어하는 최선의 방법은 애플리케이션 차원에서 HTTP 헤더, 쿠키, 쿼리 스트링, 폼 필드, 히든 필드 등의 모든 인자들에 대해 허용된 유형의 데이터만을 받아들이도록 입력값 검증을 실시하는 방법이다. 다음과 같이 왼쪽의 필드의 입력 데이터를 오른쪽의 필드로 변환해서 필터링한다.
|
From |
To |
|
< |
&It; |
|
> |
> |
|
9 |
( |
|
0 |
) |
|
# |
# |
|
& |
& |
5. 버퍼 오버플로우(Buffer Overflows)
웹 애플리케이션 컴포넌트가 사용자의 입력값을 적절히 점검하지 않는 언어로 작성되어 다운될 수 있으며, 특수 한 경우에는 공격자가 해당 프로세스의 권한을 획득할 수 있다. 이 컴포넌트로는 CGI, 라이브러리, 하드웨어 드 라이버, 웹 애플리케이션 서버 컴포넌트 등이 포함된다.
[대처 방안]
운영하고 있는 웹 서버 버전을 가장 최신버전으로 업그레이드 하거나 알려진 취약점을 제거할 수 있는 패치를 적 용한다. 정기적으로 취약점 스케너를 통해서 취약점 여부를 점검하여 발견된 취약점에 대해서는 구성 설정을 변 경하거나 패치를 적용하여 취약점을 제거한다.
6. 시스템 명령어 삽입 허용(Command Injection Flaws)
웹 애플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입허용함으로써 웹 상에 서도 시스템 명령을 실행할 수 있는 취약점이다. SQL 쿼리문을 삽입허용하게 되면 DB인증 메커니즘을 무력화시 켜서 중요한 데이터베이스 정보를 외부로 유출할 수 있다. 또한 데이터베이스의 DML(Data Manipulation Language), DDL(Data Definition Language) 언어가 모두 사용 가능하므로 데이터베이스의 유출뿐만이 아니라 무 결성을 파괴할 수도 있다.
[대처 방안]
● 반드시 필요하다면 모든 시스템 명령을 사용하는 모든 사용자의 입력값을 점검한다.
● 점검되지 않은 사용자 입력을 시스템 명령으로 전달하지 않는다.
● 점검되지 않은 사용자 입력을 파이프(|)로 전달하지 않는다.
● 점검되지 않은 사용자 입력을 perl의 open() 명령으로 전달하지 않는다.
● 점검되지 않은 사용자 입력을 C 언어와 PHP의 popen() 명령으로 전달하지 않는다.
● 점검되지 않은 사용자 입력을 ``(backticks)과 함께 사용하지 않는다.
● 운영체제의 시스템 명령이 사용자 입력에 존재하는지 점검한다.
● 모든 웹 애플리케이션엔 쉘 스크립트를 허용하지 않는다.
7. 부적절한 에러처리(Error Handling Problems)
적절하지 못한 오류 처리는 웹 사이트에서 다양한 보안 문제를 야기한다. 가장 보편적인 문제는 데이터베이스 덤프, 에러 코드등과 같은 상세한 내부 메시지들이 사용자에게 노출된다는 것이다. 이러한 정보들은 바로 악용 가능하지는 않지만 향후 발생할 수 있는 공격에 정보를 제공하게 된다. 이러한 문제를 야기하는 원인은 다음과 같다.
● 스크립팅 엔진의 설정 오류
● Servlet/JSP Runner의 설정 오류
● 웹 서버의 설정 오류
● 데이터베이스의 설정 오류
이러한 문제를 통해 유출될 수 있는 정보들은 다음과 같다.
● 애플리케이션의 흐름
● 추가적인 웹 서버 정보
● 데이터베이스 형식 및 버전
● 운영체제 형식 및 버전
● Scripting/Programming 언어의 형식 및 버전
● 물리적인 경로
● 변수 이름과 값
● 변수 형식
● 변수의 사용 목적
● 스크립트 소스 코드의 세그먼트
● SQL 쿼리의 세그먼트
● 데이터베이스와 테이블의 구조
[대처 방안]
웹 애플리케이션이 잘못된 요청을 받았을 때 자체 제작한 오류 페이지로 이동하도록 설정한다.
8. 취약한 정보 저장방식
대부분의 웹 애플리케이션은 패스워드, 신용카드 번호, 계정 기록과 같은 중요한 정보나 데이터베이스를 저장하고 있기 때문에 암호화 기술을 이용하여 보호하고 있다. 이러한 암호화 기술이 웹 애플리케이션에 적용될 때 다음과 같은 구현상의 오류로 인하여 보안 허점들을 내포하게 된다.
● 중요 데이터를 암호화하지 않는 경우
● 암호화에 사용되는 키나, 인증서, 비밀번호를 안전하지 않은 장소에 저장하는 경우
● 기밀 정보를 메모리 상에 부적절하게 저장하는 경우
● 부적절한 난수 발생 방법
● 부적절한 암호화 알고리즘 사용
● 자체 제작 암호화 알고리즘 사용
● 암호화에 사용되는 키 교환에 대한 지원 절차나 다른 유지 관리 절차를 구현하지 않는 경우
[대처 방안]
암호화 취약점에 대한 가장 손쉬운 대처 방안은 암호화 사용을 최소한으로 자제하고 반드시 필요한 정보만을 저장하는 것이다. 예를 들면 신용 카드 번호를 암호화하여 저장하기 보다는 필요할 때마다 사용자가 해당 번호를 집어넣게 한다. 암호화된 비밀번호를 저장하기 보다는 SHA-1과 같은 단방향 함수를 사용한다.
9. 서비스 방해 공격(Denial of Service)
웹 애플리케이션 측면에서는 공격과 정상적인 트래픽 사이의 차이를 구분하기 어렵다. 이런 구분을 어렵게 하는 다양한 요소들이 있지만, 다른 원인들 중에 가장 중요한 원인은 IP 주소만으로는 신원 확인이 어렵다는 점이다. HTTP 요청이 어디에서 들어왔는지를 파악할 신뢰할만한 방법이 없기 때문에 악의적인 트래픽을 필터링하기가 매우 어렵다.
[대처 방안]
기본적으로 서비스 방해 공격을 막아내는 것은 어려우며, 이런 공격을 완벽하게 방어할 수 있는 방법은 존재하지 않는다.
일반적인 규칙은 모든 사용자에게는 제한된 자원만을 할당하고 인증을 거친 사용자는 할당량을 통해 특정 사용자가 시스템에 미치는 부하를 제한할 수 있다.
인증받지 않은 사용자에 대해서는 불필요한 데이터베이스 접근이나 다른 값비싼 자원에 대한 접근을 피해야 한다.
10. 웹과 애플리케이션 서버의 구성 설정상의 오류(Web and Application Server Misconfiguration)
웹 서버와 애플리케이션의 구성 설정은 보안 측면에서 중요한 의미를 가진다. 그러한 구성설정들이 다음과 같은 여러 가지 요인들로 인해 보안 문제를 야기할 수 있다. 이러한 보안문제들은 자동화된 스케닝 도구에 의해 공격자들에 의해 공격 당할 가능성이 매우 높다.
● 서버 소프트웨어 상에 존재하는 취약점을 패치하지 않은 경우
● 디렉터리 리스팅이나 디렉터리 이동(traversal) 공격을 허용하는 서버 소프트웨어 상의 취약점이나 취약한 환경 설정
● 불필요한 디폴트 파일, 백업 및 예제 파일(예제 스크립트, 예제 애플리케이션, 환경 설정 파일, 웹 페이지 등)
● 부적절한 파일 및 디렉터리 권한 설정
● 컨텐츠 관리나 원격 관리와 같은 불필요한 서비스 제공
● 디폴트 패스워드를 사용하는 디폴트 계정
● 디버깅 관련 기능이 허용되어 있거나 관리 기능이 접근 가능한 경우
● 상세한 정보를 제공하는 에러 메시지(보다 상세한 사항은 에러 처리 부분을 참조)
● 잘못 설정된 SSL 인증서와 암호화 설정
● 자체 인증서를 사용하여 인증 문제를 해결하거나 가로채기 공격(man-in-the-middle)에 대한 보안을 제공
● 디폴트 인증서 사용
● 외부 시스템을 이용한 부적절한 인증
[대처 방안]
● 최근에 발표된 보안 취약점 정보 파악
● 최신 보안 패치 적용
● 보안 강화 가이드라인의 업데이트
● 정기적인 내, 외부 취약점 스캐닝
● 보안 강화 가이드라인 준수 여부를 점검하기 위한 서버 보안 현황 내부 감사
● 전체 보안 현황을 문서화하여 경영진에게 정기적으로 보고
[참고 자료]
OWASP Top Ten Most Critical Web Application Security Vulnerabilities (http://www.owasp.org)
댓글