OWASP TOP 10 in 2007

1 OWASP Top 10 2007OWASP Top 10 2007
OWASP Top 10 2007OWASP Top 10 2007
SK communications

CENZIC Application Security
Trends Report Q2 2007

OWASP TOP10OWASP TOP10
1. The Open Web Application Security Project (http://www.owasp.org)
2. 가장 공통적인 웹 어플리케이션 보안 취약점에 대해 개발자 , 설계자 , 아키
텍트 등 관련된 모든 사람에 대한 보안 교육을 위한 공개 프로젝트
3. 보안적으로 안전한 웹 프로그래밍을 하도록 도와 주기 위함
4. 2004 년 첫 발표 이후 현재까지
2007 년 개정판 발표
2007 년 개정판은 2006 년 MITRE 취약점
(MITRE Vulnerability Trends for 2006) 을
기준으로 작성 .

A1 – 크로스사이트
스크립팅 (XSS)
1. 콘텐츠를 암호화나 검증하는 절차 없이 사용자가 제공하는 데이
터를 어플리케이션에서 받아들이거나 , 웹 브라우저로 보낼 때
마다 발생 .
2. 공격자가 희생자의 브라우저 내에서 스크립트를 실행하게 허용
함으로써 사용자 세션을 가로채거나 , 웹 사이트를 손상하거나
웜을 심는 것 등 가능 .
A2 – 인젝션 취약점
1. 인젝션은 사용자가 입력한 데이터가 명령어나 질의문의 일부분
으로 인터프리터에 보내질 때 발생 .
2. 악의적인 공격자가 삽입한 데이터에 대해 인터프리터는 의도하
지 않은 명령어 실행 및 데이터 변경 가능 .
A3 – 악성 파일 실행
1. 공격자가 악의적인 코드와 데이터의 첨부를 허용함으로써 전체
서버 훼손과 같은 파괴적인 공격 가능 .
2. 악성 파일 실행 공격은 PHP, XML, 그리고 사용자로부터 파일명
이나 파일을 받아들이는 프레임워크에 영향을 줌 .
A4 – 불안전한 직접 객
체 참조
1. 직접 객체 참조는 개발자가 파일 , 디렉토리 , 데이터베이스 기
록 혹은 키 같은 내부 구현 객체에 대한 참조를 URL 혹은 폼
매개변수로 노출시킬 때 발생 .
2. 공격자는 이러한 참조를 조작해서 승인 없이 다른 객체에 접속
가능 .
A5 – 크로스 사이트 요
청 변조 (CSRF)
1. 로그온 한 희생자의 브라우저가 사전 승인된 요청을 취약한 웹
애플리케이션에 보내도록 함으로써 희생자의 브라우저가 공격자
에게 이득이 되는 악의적인 행동을 수행하도록 함 .

A6 – 정보 유출 및 부적
절한 오류 처리
1. 애플리케이션은 다양한 애플리케이션 문제점을 통해 의도하
지 않게 자신의 구성 정보 , 내부 작업에 대한 정보를 누출
하거나 또는 개인정보 보호 위반 가능 .
A7 – 취약한 인증 및 세
션 관리
1. 자격 증명과 세션 토큰은 종종 적절히 보호되지 않는 경우 .
2. 공격자는 다른 사용자인 것처럼 보이게 하기 위하여 비밀번
호 , 키 , 혹은 인증 토큰을 손상시킴 .
A8 – 불안전한 암호화 저
장
1. 웹 애플리케이션은 데이터와 자격 증명을 적절히 보호하기
위한 암호화 기능을 사용 않음 .
A9 – 불안전한 통신
1. 애플리케이션은 민감한 통신을 보호할 필요가 있을 때 네트
워크 트래픽을 암호화하는데 종종 실패함 .
A10 – URL 접속 제한 실
패
1. 애플리케이션이 권한 없는 사용자에게 연결 주소나 URL 이
표시되지 않도록 함으로써 , 민감한 기능들을 보호함 .
2. 공격자는 이러한 약점을 이용하여 이 URL 에 직접 접속함으
로써 승인되지 않은 동작 수행 가능 .

• 웹 애플리케이션은 클라이언트에서 요청하는 입력 값에 의해서 다양하게 동작
• 대부분의 웹 애플리케이션 공격의 주요 원인 ( 실제 취약 사례의 75% 이상 )
• 사용자의 입력 값을 적절히 검사하지 않아 발생
• 공격자가 조작 가능한 인자는 프로그래머의 예상을 초월하며 , 다양한 공격이 존재
Web
Client
입력 값 검증
입력 (input)
연산 , 처리
출력 (output)
WebServer
요청 (Request)
응답 (Response)
구분 설명
조작 가능한 인
자
URL, 쿼리 문자열 , HTTP 헤더 , 쿠키 , HTML 폼 인자 , HTML
히든 필드 등 모든 HTTP 요청을 변조
발생 가능한 공
격
URL 강제 접속 , 명령어 삽입 , 크로스 사이트 스크립팅 , 버퍼
오버플로우 , 포맷 스트링 공격 , SQL 구문 삽입 , 쿠키 조작 ,
히든 필드 조작
※ 다양한 지점 (check point) 에서 공격 / 문제점 발생
입력값 검증 부재입력값 검증 부재

• 대처 방안
– 모든 인자에 대해 사용 전에 입력 값 검증을 수행
– 하나의 컴포넌트 또는 라이브러리를 통해서 중앙 집중적으로 처리
– “ 허용 (Positive) 방식”을 사용하여 인자를 검증
– 검증해야 하는 인자 유형
데이터 유형 ( 문자열 , 정수형 , 실수형
등 )
중복 허용 여부
허용된 문자셋 (character set) 숫자의 범위
최대 / 최소 길이 타당한 것으로 지정된 값 ( 열거형 )
Null 값의 허용 여부
타당한 것으로 지정된 패턴 ( 정규식 사
용 )
반드시 필요한 인자와 그렇지 않은 인자
※ JSP – JDK 1.4 정규 표현식 도입 (RegExp)
PHP – htmlspecialchars(), eregi() 등 지원
ASP – ASP.NET 에 보안 관련 기능 다수 추가
입력값 검증 부재입력값 검증 부재 (Cont’d)(Cont’d)

입
력
값
검
증
• 사용자의 입력 값을 적절히 검증하지 않아 발생 (‘ 입력 값 검증 부재’의 일부 )
• 웹 애플리케이션을 이용하여 다른 사용자에게 악성 코드를 보내는 데 사용
• 악성 코드는 일반적으로 스크립트 형태 (JavaScript, VBScript, flash, 등 )
• 악성 스크립트는 브라우저 쿠키 , 세션 토큰 또는 다른 민감한 정보에 접근할 수 있으
며 , HTML 페이지의 내용도 조작 / 변경 가능
• 초래되는 결과
– 사용자의 세션 쿠키 유출 , 사용자 파일 유출 , 트로이 목마 설치 , 다른 페이지나
사이트로의 리다이렉트 , 현재 보여지는 컨텐츠의 변조 등 다양
Attacker
Client
입
력
처
리
출
력
Web Application
Token
Token
악성 스크립트
A1.A1. 크로스 사이트 스크립팅크로스 사이트 스크립팅
(XSS)(XSS)

• 대처 방안
– 최선의 방법은 애플리케이션 차원에서 HTTP 헤더 , 쿠키 , 쿼리 스트링 , 폼 필
드 , 히든 필드 등의 모든 인자들에 대해 허용된 유형의 데이터만 받아들이도록 입
력값을 검증
– 명시적으로 허용된 것을 지정하여 받아들이는 ‘허용 (positive) 방식’ 적용
– 인코딩을 변환을 통해 JavaScript 를 통한 공격의 상당수 방어 가능
변환 대상 (From) 변환값 (To) 변환 대상 (From) 변환값 (To)
< < ) )
> > # #
( ( & &
A1.A1. 크로스 사이트 스크립팅크로스 사이트 스크립팅
(Cont’d)(Cont’d)

10OWASP Top 10 2007OWASP Top 10 2007
System Calls
• 사용자의 입력 값을 적절히 검사하지 않아서 발생 (‘ 입력 값 검증 부재’의 일부 )
• 특수 ( 메타 ) 문자 , 악의적인 명령어 , 혹은 명령어 수정 인자를 삽입하여 웹 애플리케
이션이 호출하는 외부 프로그램에 그대로 전달되어 실행
• 시스템 콜을 통한 OS 호출 , 쉘 명령어를 통한 외부 프로그램 사용 , SQL 구문을 통
해 백앤드의 데이터베이스를 호출이 가능
• 특히 ‘ SQL 구문 삽입’ 자주 발견되는 문제이며 , 다양한 삽입 취약점 중에서 위험한
유형에 속함
DBMS
External Programs
Web Server
Web Application
악의적 요청
A2.A2. 삽입 취약점삽입 취약점

• 대처 방안
– 가장 간단한 대처 방안은 가능한 한 외부 인터프리터를 호출하지 않는 것
( 각 언어에서 쉘 명령어나 시스템 콜이 수행하는 것과 동일한 역할을 수행하는 라
이브러리를 이용 )
– 반드시 사용해야 되는 경우 , 입력 값 검증을 수행하여 악의적인 구문이 포함되지
않도록 보장 (Stored procedure, Prepared statement 사용 )
– 명령어 삽입에 대한 방어 수단으로는 해당 기능을 수행하는 데 필요한 권한 이상
의 권한을 부여하지 않는 것
• 웹 서버를 root 권한으로 운영하지 않는다
• 데이터베이스에 접속할 때 DB 관리자 권한으로 접속하지 않는다 .
– 외부 명령어를 실행해야 한다면 , 사용자가 입력한 정보 중 해당 명령어로 전달되
는 내용을 철저히 검증하여야 하며 , 호출 과정에 발생하는 모든 예측 가능한 에
러 , 시간 초과 , 실행 중단 문제를 적절히 처리할 메커니즘을 구현해야 한다
A2.A2. 삽입 취약점삽입 취약점 (Cont’d)(Cont’d)

A4.A4. 취약한 직접적인 객체 참조취약한 직접적인 객체 참조
• 직접 객체 참조는 개발자가 파일 , 디렉토리 , 데이터베이스 레코드나 키를 URL 이나
폼 매개변수로 내부에 구현된 객체를 노출시킬 때 발생할 수 있다 .
• 접근 권한 확인이 적절히 이뤄지지 않으면 , 공격자는 이러한 참조를 조작함으로써 다
른 객체에 인증 없이 접근할 수 있다 .
• 알고 있는 올바름을 수락’하는 접근을 통해 사적 객체 참조를 광범위하게 검증하라 .
• 모든 참조된 객체에 대해 권한을 검증 하도록 하라 .
• 매개변수 변조 공격을 방어하기 위해서는 인덱스 값이나 참조 맵을 사용하는 것이 최
적의 방안이다 .
http://www.example.com/application?file=1
• 만약 데이터베이스 구조에 대한 직접 참조를 노출해야 한다면 , SQL 구문이나 다른 데
이터베이스 접근 방법들이 아래와 같이 권한 부여된 레코드만 허용하도록 확인해야 한
다 :
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" +
user.getID();

• CSRF 공격은 로그인한 피해자의 브라우저가 취약한 웹 어플리케이션에 요청을 보내
도록 하여 피해자 대신 선택된 작동을 수행하도록 한다 .
• 본 검증의 목적은 브라우저에 의하여 자동으로 제시되지 않는 몇 종류의 권한 토큰을
생성하고 요청함으로써 어플리케이션이 CSRF 의 공격을 방어하도록 검증하는 것이
다 .
• 여러분의 어플리케이션 내에 XSS 취약점이 없도록 확인하라
• 모든 폼과 URL 내에 브라우저에 의해 자동으로 제출되지 않도록 특별히 설계되
고 불규칙한 토큰을 삽입하라 . 예를 들면 ,
<form action="/transfer.do" method="post">
<input type="hidden" name="8438927730" value="43847384383">
…
</form>
• 민감한 데이터나 값에 대한 트랜잭션을 위하여 재 인증이나 트랜잭션 서명을 사
용하여 요청이 진실함을 확인하라 .
• 민감한 데이터나 또는 값의 트랜젝션 수행을 위해 GET 요청 (URLs) 은 사용하지
마라 .
• POST 방식만으로 보호하는 것은 불가능하다 .
A5.A5. 크로스 사이트 요청 변조크로스 사이트 요청 변조
(CSRF)(CSRF)

• 부적절한 에러 처리는 웹 사이트에 다양한 보안 문제를 야기
• 가장 일반적인 문제는 stack trace, 데이터베이스 덤프나 에러 코드에 대한 자세한 에
러 메시지를 반환되어 결코 알려져서는 안되는 구현상의 세부 정보를 노출
• 부적절한 에러 처리는 해커들에게는 사이트의 잠재적인 취약점에 대한 힌트를 , 일반
사용자에게는 불필요하고 귀찮은 정보임
• 통일성 없는 에러 메시지는 사이트의 작동 방식이나 내부적으로 정보가 어디에 저장되
어 있는지에 대한 중요한 정보를 노출 가능
• 보편적인 보안 문제는 fail-open( 보안 점검에 실패하면 무조건 열어줌 ), 시스템 크래
쉬 유발 , 리소스 고갈 등으로 정상적인 사용자에 대한 서비스를 방해
A6.A6. 정보노출과 부적절한 에러 처정보노출과 부적절한 에러 처
리리

웹 루트 디렉토리 노출
WAS 설치 디렉토리 노출
WAS 종류 노출
• 부적절한 에러 처리의 예
향후 공격에 유용
A6.A6. 정보노출과 부적절한 에러 처리정보노출과 부적절한 에러 처리

• 대처 방안
– 에러 처리에 대한 명시적 정책을 문서화
• 에러의 유형 , 반환되는 정보 , 로그 기록 여부가 다루어져야 함
• 모든 개발자는 해당 정책을 이해 , 자신이 작성한 코드에 이를 적용
– 구현 측면에서는 예상 가능한 모든 에러가 적절히 다루어지도록 보장
• 명시적 결과 반환
• 불필요한 정보의 노출을 하지 않으면서 도움이 되는 정보 반환
• 특정 부류의 에러는 구현상 문제점 및 해킹 시도 파악을 위해 로그에 기록
– 침입탐지 기능을 포함하고 있는 것이 바람직하다
A6.A6. 정보노출과 부적절한 에러 처리정보노출과 부적절한 에러 처리

• 올바른 인증 및 세션 관리는 웹 어플리케이션 보안에 필수적이다 . 이러한 취약점은 사
용자나 관리자 계정을 가로챌 수 있고 , 권한 및 책임 추구성 관리를 약화시키며 , 개인
정보 침해를 유발한다 .
• 우선적으로 SSL 은 어플리케이션의 모든 인증된 부분을 위한 유일한 옵션 (A9 –
불안전한 통신 ) 이며 모든 자격 인증이 해시나 암호화 형태 (A8 – 불안전한 암호
화 저장 ) 로 저장되도록 확실히 하라 .
• 본래의 세션 관리 메커니즘만 사용한다 .
• 자체 제작된 SSO 기능과 같은 인증 및 세션 관리를 위한 여러분의 특별히 개발된
쿠키를 제한하거나 제거한다 .
• 암호화되지 않은 페이지로부터 로그인 과정이 시작되도록 허용하지 말라 .
• 모든 페이지에 로그아웃 연결주소를 두어라 .
• 보호할 데이터의 가치 대비 비활성화된 세션이 자동 로그아웃 되도록 타임아웃 기
간을 설정하라 .
• URL 이나 로그에서 세션 식별자나 유효한 자격 증명의 어떤 부분이 드러나지 않도
록 하라 ( 세션을 재작성하거나 로그 파일에서 사용자의 암호를 저장하지 마라 ).
• 강력한 부수적인 인증 기능 ( 질문과 답변 , 암호 재설정 ) 을 사용하라 .
• IP 주소 또는 주소 범위 마스크 , DNS 조회 또는 역 DNS 조회 , 참조 헤더 또는
이와 유사한 조작 가능한 자격 증명을 유일한 인증 형태로 의존하지 마라 .
A7.A7. 취약한 인증 및 세션 관리취약한 인증 및 세션 관리

• 웹 애플리케이션은 데이터베이스나 파일 시스템 상에 패스워드 , 신용 카드 정보 , 계좌
정보 혹은 자체적인 정보와 같은 민감한 정보를 저장
• 민감한 정보를 저장하기 위해 암호화가 사용되나 애플리케이션에 적용 시 또는 개발자
의 암호화에 대한 과대 평가로 인해 문제 발생
• 자주 저지르는 실수들
– 중요 데이터를 암호화 하지 않는 경우
– 암호화에 사용되는 키 , 인증서 , 비밀번호를 안전하지 않은 장소에 저장하는 경우
– 기밀 정보를 메모리 상에 부적절하게 저장 하는 경우
– 부적절한 난수 발생 방법
– 부적절한 암호화 알고리즘 사용
– 자체 제작 암호화 알고리즘 사용
– 암호화에 사용되는 키 교환에 대한 지원 절차나 다른 유지 관리 절차를 구현하지 않
는 경우
– 하드 코딩된 키와 안전하지 못한 영역에 키 저장
A8.A8. 취약한 암호화 저장취약한 암호화 저장

• 대처 방안
– 가장 손쉬운 대처 방안은 암호화 사용을 최소한으로 자제하고 반드시 필요한 정보
만 저장
예 ) 신용 카드 번호를 암호화하여 저장하기 보다는 필요할 때마다 사용자에게
입력을 받는 것이 손쉽다 .
– 암호화된 비밀번호를 저장하기 보다는 SHA-1 과 같은 단방향 암호화 함수를 이용
하여 패스워드를 해쉬하는 것이 손쉽다 .
– 암호화가 반드시 필요하다면 객관적인 검증 과정을 거쳐 취약점이 없다고 밝혀진
라이브러리를 사용
– 사용하는 암호화 관련 함수들을 캡슐화하고 해당 코드를 주의 깊게 점검
– 공격자의 공격을 어렵게 하기 위해서 기밀 정보의 마스터 파일은 최소한 두 개로
분산하여 저장하고 실행 중에 합쳐서 사용
A8.A8. 취약한 암호화 저장취약한 암호화 저장 (Cont’d)(Cont’d)

요청 (Request)
• 접근 통제 ( 권한 관리 )
– 어떤 사용자들에게 웹 컨텐츠나 기능들에 접근할 수 있도록 허가하고 , 다른 사용
자에게는 허용하지 않는 방법
• 접근 통제 모델은 해당 사이트가 제공하는 컨텐츠와 기능과 밀접한 관계가 있다 .
• 신뢰할만한 접근 통제 메커니즘의 구현에 대해 과소 평가
– 접근 통제 설계를 신중하게 하지 않음
– 접근 통제 규칙이 사이트 전체에 분산되어 비대하고 복잡해짐
• 공격에 필요한 요소
– 접근할 수 없는 기능이나 컨텐츠에 대해 요청하는 부분에 대한 약간의 정보 변조
WebApplication
접근
통제
일반 사용자
인터페이스
관리자 인터페이스
A10.A10. 취약한 접근 통제취약한 접근 통제

• 대처 방안
– 접근 통제 규칙을 정의하고 문서화
– 접근 통제 표 (Access Control Matrix) 의 사용
– 정의된 접근 통제 규칙을 철저히 검증하여 우회할 방법이 없음을 증명
– 접근 통제와 관련된 주제들
구분 설명
취약한 ID
입력 받은 값들이 현재 사용자에게 허용된 적절한 값인지를
검증해야 한다 .
강제 접근
내부 URL 을 접속하기 위해 실시하는 보안 검사가 단순히 페
이지 우회로 통과 가능해서는 안 된다 .
경로 이동
상대 경로와 같이 특정 URL 이나 파일에 액세스하는데 사용되
는 값들을 허용해서는 안 된다 .
파일 허가권
환경 설정 파일 , 디폴트 예제 파일 등과 같은 파일에 대해서
는
접근을 금지해야 하며 , 불필요한 허가권을 부여해서는 안 된
다 .
클라이언트 측 캐
쉬
HTTP 헤더 , 메타 태그 등을 사용하여 민감한 정보가 담긴
페이지가 사용자의 브라우저에 캐쉬 되지 않도록 한다 .
A10.A10. 취약한 접근 통제취약한 접근 통제 (Cont’d)(Cont’d)

• 웹 서버와 애플리케이션 서버의 설정은 웹 애플리케이션 보안의 핵심적 역할을 수행
• 웹 애플리케이션 프로그래머와 웹 서버 운영자 사이의 커다란 격차로 인해서 발생
• 발생 가능한 문제점
– 서버 소프트웨어 상에 존재하는 취약점을 패치하지 않은 경우
– 디렉터리 리스팅이나 디렉터리 이동 공격을 허용하는 서버 소프트웨어 상의 취약
점이나 취약한 환경 설정
– 불필요한 디폴트 파일 , 백업 및 예제 파일
– 부적절한 파일 및 디렉터리 권한 설정
– 컨텐츠 관리나 원격 관리와 같은 불필요한 서비스 제공
– 디폴트 패스워드를 사용하는 디폴트 계정
– 디버깅 관련 기능이 허용되어 있거나 관리 기능이 접근 가능한 경우
– 상세한 정보를 제공하는 에러 메시지
– 잘못 설정된 SSL 인증서와 암호화 설정
– 인증 문제를 해결하거나 가로채기 공격을 방지하기 위해 자체 인증서 사용
– 디폴트 인증서 사용
– 외부 시스템을 이용한 부적절한 인증
부적절한 환경설정부적절한 환경설정

• 부적절한 환경 설정의 예
취약한 구버전 WAS 사용
디렉토리 인덱싱 활성화
%3f.jsp
http://www.securityfocus.com/bid/3592
http://www.securityfocus.com/bid/5838
부적절한 환경설정부적절한 환경설정 (Cont’d)(Cont’d)

• 웹 서버와 애플리케이션 서버의 환경 설정에 대한 보안 강화 가이드라인 제작
– 운영 서버 뿐만 아니라 개발 환경에도 모두 적용
– 보안 강화 가이드 라인에 포함되는 사항
• 모든 보안 메커니즘에 대한 설정
• 불필요한 모든 서비스를 제거하는 방법
• 디폴트 계정의 비활성 , 디폴트 계정의 패스워드 변경 방법 등의 역할 , 권한
계정에 관한 설정
• 로그 및 알람 관련 설정
– 기존의 보안 강화 자동화 도구 및 자체 제작 도구의 사용
– 각 개인이나 팀에게 최신 가이드 라인의 준수 및 유지 , 관리 임무 할당
• 최근에 발표된 보안 취약점 정보 파악
• 최신 보안 패치 적용
• 보안 강화 가이드라인의 업데이트
• 정기적인 내 , 외부 취약점 스캐닝
• 보안 강화 가이드라인 준수 여부를 점검하기 위한 서버 보안 현황 내부 감사
• 전체 보안 현황을 문서화하여 경영진에게 정기적으로 보고
부적절한 환경설정부적절한 환경설정 (Cont’d)(Cont’d)

OWASP TOP 10 in 2007

Recommended

Recommended

More Related Content

Similar to OWASP TOP 10 in 2007

Similar to OWASP TOP 10 in 2007 (20)

More from Samsung Electronics

More from Samsung Electronics (20)

OWASP TOP 10 in 2007