주통기반 살펴보기 (웹 WEB)

주통기반 - 웹 (WEB)

주요정보통신기반시설 - 기술적 취약점 분석 · 평가 방법

주통기반 파일 다운로드 - KISA 한국인터넷진흥원

https://www.kisa.or.kr/2060204/form?postSeq=12&lang_type=KO&page=1

KISA 한국인터넷진흥원

위의 주통기반 웹 취약점 중 몇가지를 골라서 간단하게 살펴보려한다.

5. SQL 인젝션 (SI)

취약점 개요

점검내용
웹 페이지 내의 SQL 인젝션 취약점 존재 여부를 점검한다.

점검목적
대화형 웹 사이트에 비정상적인 사용자 입력 값 허용을 차단하여 악의적인 데이터베이스 접근 및 조작을 방지하기 위함이다.

보안위협
해당 취약점이 존재하는 경우, 비정상적인 SQL 쿼리로 DBMS 및 데이터(Data)를 열람하거나 조작 가능하므로 사용자의 입력 값에 대한 필터링을 구현해야한다.

※ SQL 인젝션 : 사용자의 입력 값으로 웹 사이트 SQL 쿼리가 완성되는 약점을 이용하며, 입력 값을 변조하여 비정상적인 SQL 쿼리를 조합하거나 실행하는 공격으로, 개발자가 생각지 못한 SQL문을 실행되게 함으로써 데이터베이스를 비정상적으로 조작이 가능하다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 방화벽

판단기준
임의로 작성된 SQL 쿼리 입력에 대한 검증이 이루어지지 않는 경우에 취약하다고 판단한다.

조치방법
소스코드에 SQL 쿼리를 입력값으로 받는 함수나 코드를 사용할 경우, 임의의 SQL 쿼리 입력에 대한 검증 로직을 구현하여 서버에 검증되지 않는 SQL 쿼리 요청시 에러페이지가 아닌 정상 페이지가 반환되도록 필터링 처리하고 웹 방화벽에 SQL 인젝션 관련 룰셋을 적용하여 SQL 인젝션 공격을 차단한다.

점검 및 조치방안

점검방법
Step 1) 사용자 입력 값에 특수문자나 임의의 SQL 쿼리를 삽입하여 DB 에러 페이지가 반환되는지 확인한다.
Step 2) 사용자 입력 값에 임의의 SQL 참, 거짓 쿼리를 삽입하여 참, 거짓 쿼리에 따라 반환되는 페이지가 다른지 확인한다.
Step 3) 로그인 페이지에 참이 되는 SQL 쿼리를 전달하여 로그인되는지 확인한다.

보안설정방법
* SQL 쿼리에 사용되는 문자열의 유효성을 검증하는 로직을 구현한다.
(입력 값에서 특수문자를 제거하여 바인딩하는 소스를 구현한다.)
* 다음과 같은 특수문자를 사용자 입력값으로 받지 못하도록한다.
문자 데이터 구분기호( ' ), 쿼리 구분 기호 ( ; ), 해당라인 주석 구분 기호( -- , # ), 구문 주석( /* */)
* Dynamic SQL 구문 사용을 지양하며 파라미터에 문자열 검사를 필수적으로 적용한다.
(PreparedStatement 객체를 사용한다. 외부 입력 값이 위치하는 부분을 "?" 로 설정하여 실행 시 해당 파라미터가 실행되도록 수정한다. - Static SQL 구문을 사용한다.)
* 시스템에서 제공하는 에러메시지 및 DBMS에서 제공하는 에러 코드가 노출되지 않도록 예외처리한다.

※ 문자열 유효성 검증 로직 구현 시 웹 서비스에서 사용하고 있는 명령어 및 특수문자가 필터링 되어 장애가 발생할 수 있으므로 사전 영향 분석이 필요하다.

 

8. 디렉터리 인덱싱 (DI)

취약점 개요

점검내용
웹 서버 내 디렉터리 인덱싱 취약점 존재 여부를 점검한다.

점검목적
디렉터리 인덱싱 취약점을 제거하여, 특정 디렉터리 내의 불필요한 파일 정보의 노출을 차단한다.

보안위협
해당 취약점이 존재하는 경우, 브라우저를 통해 특정 디렉터리 내 파일 리스트를 노출하여 응용시스템의 구조를 외부에 허용할 수 있고, 민감한 정보가 포함된 설정 파일 등이 노출될 경우 보안상 심각한 위험을 초래할 수 있다.

※ 디렉터리 인덱싱 취약점 : 특정 디렉터리에 초기 페이지 파일이 존재하지 않을 때 자동으로 디렉터리 리스트를 출력하는 취약점이다.

점검대상 및 판단기준

대상 : 웹 서버

판단기준
디렉터리 파일 리스트가 노출되는 경우에 취약하다고 판단한다.

조치방법
웹 서버 설정을 변경하여 디렉터리 파일 리스트가 노출되지 않도록 설정한다.

점검 및 조치방안

점검방법
Step 1) URL 경로 중 확인하고자 하는 디렉터리까지만 주소창에 입력하여 인덱싱 여부를 확인한다.
Step 2) 디렉터리 끝에 %3f.jsp 문자열을 붙여 디렉터리 인덱싱이 되는지 확인한다.
(Apache 서버에서 종종 되는 경우가 있는 구문이다.)

보안설정방법
* 웹 서버 환경설정에서 디렉터리 인덱싱 기능을 제거한다.

 

9. 정보 누출 (IL)

취약점 개요

점검내용
웹 서비스 시 불필요한 정보가 노출되는지 여부를 점검한다.

점검목적
웹 서비스 시 불필요한 정보가 노출되는 것을 방지함으로써 2차 공격에 활용될 수 있는 정보 노출을 차단하기 위함이다.

보안위협
웹사이트에 중요정보(개인정보, 계정정보, 금융정보 등)가 노출되거나 에러 발생시 과도한 정보(애플리케이션 정보, DB정보, 웹 서버 구성 정보, 개발 과정의 코멘트 등)가 노출될 경우 공격자들의 2차 공격을 위한 정보로 활용될 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버

판단기준
웹 사이트에 중요정보가 노출되거나, 에러 발생 시에 과도한 정보가 노출되는 경우에 취약하다고 판단한다.

조치방법
웹 사이트에 노출되는 중요정보는 마스킹을 적용하여야 하며, 발생 가능한 에러에 대해 최소한의 정보 또는 사전에 준비된 메시지만 출력하도록 한다.

점검 및 조치방안

점검방법
Step 1) 웹 사이트에 중요정보가 평문으로 노출되고 있는지 확인한다.
Step 2) 웹 페이지에 마스킹 된 중요정보가 웹 페이지 소스에 평문으로 노출되고 있는지 확인한다.
Step 3) 에러 메시지 또는 에러 페이지에서 과도한 정보가 노출되는지 확인한다.
Step 4) 인코딩된 중요 정보는 디코딩 가능한지 확인한다.
Step 5) 임의의 계정으로 로그인을 시도하여 반환되는 에러 메시지를 통해 특정 ID의 가입 여부를 식별할 수 있는지 확인한다.

보안설정방법
* 사용자가 주민등록번호 뒷자리, 비밀번호 입력 시 별표로 표시하는 등 마스킹 처리를 하여 주변 사람들에게 노출되지 않도록 한다.
* 개인정보의 조회, 출력 시 다음과 같은 원칙으로 일부 정보에 마스킹을 적용하여 표시한다.
1) 성명 중 이름의 가운데 글자(ex : 홍*동)
2) 생년월일 (ex : ****년 **월 **일)
3) 전화번호 (ex : 010-****-5678)
4) 주소의 읍/면/동 (ex : 서울시 노원구 ***동)
5) IPv4 주소의 경우 : 17~24bit / IPv6 주소의 경우 113~128bit
* 웹 페이지를 운영 서버에 이관 시 주석(Comment)는 모두 제거하여 이관한다.
* 중요정보(개인정보, 계정정보, 금융정보 등)를 HTML 소스에 포함하지 않도록 한다.
* 로그인 실패 시 반환되는 에러 메시지는 특정 ID의 가입 여부를 식별할 수 없도록 구현한다.
* 에러 코드에 대하여 별도의 에러 페이지로 Redirect 하거나 적절한 에러처리 루틴을 설정하여 처리하도록한다.

 

10. 악성 콘텐츠 (CS)

취약점 개요

점검내용
게시판 등에 악성 콘텐츠 삽입 및 실행 여부를 점검한다.

점검목적
사이트 내의 악의적인 콘텐츠 삽입 및 실행을 방지하기 위함이다.

보안위협
웹 사이트 게시판, 댓글, 자료실 등에 정상적인 콘텐츠 대신 악성 콘텐츠를 주입하여 실행될 경우 사용자가 해당 콘텐츠 열람시 악성코드 감염 및 웹 페이지 변조 등 보안상 심각한 위험에 노출될 수 있다.

※ 기반시설 특성상 원칙적으로 업로드 기능을 제한해야 하나 꼭 사용해야 하는 경우에는 특정 사용자만 허용된 확장자의 콘텐츠 파일을 업로드 할 수 있도록 구현한다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 방화벽

판단기준
악의적인 콘텐츠가 입력되며, 실행되는 경우에 취약하다고 판단한다.

조치방법
사용자 입력 값에 대한 검증 로직 추가 및 실행 제한을 설정한다.

점검 및 조치방안

점검방법
Step 1) 콘텐츠 삽입 및 파일 업로드 제한 필터링의 적용 여부를 점검한다.
Step 2) 게시판 등의 페이지에서 강제적으로 이뤄지는 악의적인 프로그램 다운로드 및 콘텐츠 자동 실행이나 악의적인 사이트로의 이동이 발생하는지 확인한다.

보안설정방법
* 악성 콘텐츠가 삽입되어있는 페이지에 대하여 증거자료(화면, 소스 등)를 남기고, 삽입된 악성 콘텐츠를 삭제하거나 페이지의 삭제 등을 실시한다.
(취득한 증거자료를 가지고 악성 콘텐츠의 삽입 원인에 대하여 분석하여 원인을 제거할 것을 권고한다.)
* 게시판의 글 등록 및 파일 업로드 기능에 악성코드가 포함될 수 있는 콘텐츠를 삽입 또는 업로드 하지 못하게 필터링을 적용한다.
* 주기적으로 업로드된 파일을 대상으로 바이러스 검사를 실시한다.

 

11. 크로스사이트 스크립팅 (XS)

취약점 개요

점검내용
웹 사이트 내 크로스사이트 스크립팅 취약점의 존재 여부를 점검한다.

점검목적
웹 사이트 내 크로스사이트 스크립팅 취약점을 제거하여 악성 스크립트의 실행을 차단한다.

보안위협
웹 애플리케이션에서 사용자 입력 값에 대한 필터링이 제대로 이루어지지 않을 경우, 공격자는 사용자 입력 값을 받는 게시판, URL 등에 악의적인 스크립트(Javascript, Active X, Flash 등)를 삽입하여 게시글이나 이메일을 읽는 사용자의 쿠키(세션)를 탈취하여 도용하거나 악성코드 유포 사이트로 Redirect 할 수 있다.

※ 크로스사이트 스크립팅 : 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법으로 공격 방식은 크게 Stored 공격 방식과 Reflected 공격  방식으로 나누어진다.
※ OWASP - XSS 필터링 관련 참고사항
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 방화벽

판단기준
사용자 입력 값에 대한 검증 및 필터링이 이루어지지 않으며, HTML 코드가 입력 · 실행되는 경우에 취약하다고 판단한다.

조치방법
웹 사이트의 게시판, 1:1 문의, URL 등에서 사용자 입력 값에 대해 검증 로직을 추가하거나 입력되더라도 실행되지 않게 하고, 부득이하게 웹 페이지에서 HTML을 사용하는 경우 HTML 코드 중 필요한 코드에 대해서만 입력되도록 설정한다.

점검 및 조치방안

※ XSS 취약 유형
-  XSS에 취약한 페이지 유형
1. HTML을 지원하는 게시판
2. Search Page
3. Join Form Page
4. Refererr를 이용하는 Page
5. 그 외 사용자로부터 입력받아 화면에 출력하는 모든페이지에서 발생이 가능하다.
- XSS를 유발할 수 있는 스크립트
<script> ... </script>
<img src="javascript:......">
<div style="background-image:url(javascript...)"></div>
<embed>...</embed>
<iframe></iframe>
※ Filtering을 우회하기 위한 다양한 표현이 가능하다.
◆ %3Cscript%3E........%3Cscript%3E
◆ Jav&#97;script;
◆ Java&#13;script
◆ Java&#0013;script

점검방법
Step 1) 사용자 입력 값을 전달받는 애플리케이션(회원정보 변경, 게시판, 댓글, 자료실 등)에 스크립트 입력 후 실행되는지 확인한다.
Step 2) 사용자 입력 값을 전달받는 애플리케이션(검색, URL)에 스크립트 입력 후 실행되는지 확인한다.

보안설정방법
* 웹 사이트에 사용자 입력 값이 저장되는 페이지는 공격자가 웹 브라우저를 통해 실행되는 스크립트 언어를 사용하여 공격하므로 해당되는 태그 사용을 사전에 제한하고, 사용자 입력 값에 대한 필터링 작업이 필요하다.
* 게시물의 본문뿐만 아니라 제목, 댓글, 검색어 입력 창, 그 외 사용자 측에서 넘어오는 값을 신뢰하는 form과 파라미터 값에 대하여 필터링을 수행한다.
* 입력 값에 대한 필터링 로직 구현 시 공백 문자를 제거하는 trim, replace 함수를 사용하여 반드시 서버 측에서 구현되어야 한다.
* URL Decoder 클래스에 존재하는 decode 메소드를 통해 URL 인코딩이 적용된 사용자 입력 값을 디코딩 함으로써 우회 공격을 차단한다.
* 웹 방화벽에 모든 사용자 입력 폼(회원정보 변경, 게시판, 댓글, 자료실, 검색, URL 등)을 대상으로 특수문자, 특수 구문을 필터링하도록 룰셋을 적용해야한다.
※ 필터링 조치 대상 입력 값
● 스크립트 정의어 : <SCRIPT>, <OBJECT>, <APPLET>, <EMBED>, <FORM>, <IFRAME> 등
● 특수문자 : <, >, ", ', &, %, %00(null) 등

※ 참고 : 필터링 대상

 

12. 약한 문자열 강도 (BF)

취약점 개요

점검내용
웹 페이지 내 로그인 폼 등에 약한 강도의 문자열 사용 여부를 점검한다.

점검목적
유추 가능한 취약한 문자열 사용을 제한하여 계정 및 패스워드 추측 공격을 방지하기 위함이다.

보안위협
해당 취약점이 존재하는 경우 유추가 용이한 계정 및 패스워드의 사용으로 인한 사용자 권한 탈취 위험이 존재하며, 해당 위험을 방지하기 위해 값의 적절성 및 복잡성을 검증하는 로직을 구현하여야 한다.

※ 약한 문자열 강도 취약점 : 웹 사이트에서 취약한 패스워드로 회원가입이 가능할 경우 공격자는 추측 및 주변 정보를 수집하여 작성한 사전 파일로 대입을 시도하여 사용자 계정을 탈취할 수 있는 취약점이다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
관리자 계정 및 패스워드가 유추하기 쉬운 값으로 설정되어 있으며, 일정 횟수 이상 인증 실패 시 로그인을 제한하고 있지 않은 경우에 취약하다고 판단한다.

조치방법
계정 및 비밀번호의 체크 로직을 추가 구현해야한다.

점검 및 조치방안

점검방법
Step 1) 웹 사이트 로그인 페이지의 로그인 창에 추측 가능한 계정이나 패스워드를 입력하여 정상적으로 로그인되는지 확인한다.
Step 2) 일정 횟수 이상 인증 실패 시 로그인을 제한하는지 확인한다.

보안설정방법
* 취약한 계정 및 패스워드를 삭제하고, 사용자가 취약한 계정이나 패스워드를 등록하지 못하도록 패스워드 규정이 반영된 체크 로직을 회원가입, 정보변경, 패스워드 변경 등의 적용이 필요한 페이지에 모두 구현하여야 한다.

※ 규정 예시
1) 영문 대 · 소문자, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 또는, 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성한다.
2) 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고한다.
3) 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경을 권고한다.
4) 최근 사용되었던 패스워드의 재사용을 금지한다.
* 로그인 시 패스워드 입력 실패가 일정 횟수(3~5회) 이상 초과할 경우 관리자에게 통보 및 계정을 잠금 설정한다.
※ 인증 실패 횟수를 Client Side Script를 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script를 통하여 구현한다.

 

13. 불충분한 인증 (IA)

취약점 개요

점검내용
중요 페이지 접근 시에 추가 인증 요구 여부를 점검한다.

점검목적
중요 페이지에 추가 인증으로 접근을 강화하여 불필요한 정보의 노출 및 변조를 차단하기 위함이다.

보안위협
중요정보(개인정보 변경 등) 페이지에 대한 인증 절차가 불출분할 경우, 권한이 없는 사용자가 중요정보 페이지에 접근하여 정보를 유출하거나 변조할 수 있으므로 중요정보 페이지에는 추가적인 인증 절차를 구현하여야 한다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
중요정보 페이지 접근에 대한 추가 인증을 하지 않는 경우에 취약하다고 판단한다.

조치방법
중요정보 페이지에 대한 추가 인증 로직을 추가적으로 구현한다.

점검 및 조치방안

점검방법
Step 1) 중요정보(개인정보 변경 등) 페이지 접근 시 재인증 여부를 확인한다.
Step 2) 인증 후 페이지에 아이디만을 인증 값으로 하여 변수로 관리되고 있는지를 확인한다.

보안설정방법
* 중요정보(개인정보 변경 등)를 표시하는 페이지에서는 본인 인증을 재확인하는 로직을 구현하고, 사용자가 인증 후 이용 가능한 페이지에 접근할 때마다 승인을 얻은 사용자인지 페이지마다 검증하여야 한다.
* 접근 통제 정책을 구현하고 있는 코드는 구조화, 모듈화가 되어 있어야 한다.
* 접근제어가 필요한 모든 페이지에 통제수단(로그인 체크 및 권한 체크)을 구현해야 하며 특히, 하나의 프로세스가 여러 개의 페이지 또는 모듈로 이루어져 있을 때 권한 체크가 누락되는 경우를 방지하기 위해서 공통 모듈을 사용하는 것을 권장한다.
* 인증 과정을 처리하는 부분에 Client Side Script를 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script를 통하여 인증 및 필터링 과정을 수행하도록 한다.

 

14. 취약한 패스워드 복구 (PR)

취약점 개요

점검내용
웹 사이트 내 패스워드 복구 절차의 적절성을 점검한다.

점검목적
패스워드 복구 로직을 유추하기 어렵게 구현하고, 인증된 사용자 메일이나 SMS에서만 복구 패스워드를 확인할 수 있도록 하여 비인가자를 통한 사용자 패스워드 획득 및 변경을 방지하기 위함이다.

보안위협
취약한 패스워드 복구 로직(패스워드 찾기 등)으로 인하여 공격자가 불법적으로 다른 사용자의 패스워드를 획득, 변경할 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
패스워드 재설정 시 일정 패턴으로 재설정되고 웹 사이트 화면에 바로 출력시에 취약하다고 판단한다.

조치방법
패스워드 복구 로직을 변경(패스워드 재설정 시 난수를 이용하여 재설정)하고 인증된 사용자 메일이나 SMS로 재설정된 패스워도 혹은 재설정을 위한 링크를 전송하도록한다.

점검 및 조치방안

점검방법
Step 1) 재설정(또는 패스워드 찾기)되는 패스워드에 대하여 사용자의 연락처, 주소, 메일 주소, 일정 패턴 등을 패스워드로 이용하고 있는지 확인하고, 재설정된 패스워드를 인증된 사용자 메일이나 SMS로 전송하는지 확인한다.

보안설정방법
* 사용자의 개인정보(연락처, 주소, 메일 주소 등)로 패스워드를 생성하지 말아야 하며, 난수를 이용한 불규칙적이고 최소 길이(6자 이상 권고) 이상의 패턴이 없는 패스워드를 발급하여야 한다.
* 사용자 패스워드를 발급해주거나 확인해줄 때 웹 사이트 화면에 바로 출력해주는 것이 아니라 인증된 사용자 메일이나 SMS로 전송해주어야 한다.
* 패스워드 재발급 검증 실해에 대한 임계값을 설정하여 일정 횟수 이상 실패한 경우, 다른 방식으로 패스워드 찾기 기능을 제공하여야 한다. 검증 후 기존의 패스워드가 아닌 임시 패스워드를 발급하도록 설계해야 하며, 사용자가 임시패스워드를 발급받은 즉시 새로운 패스워드로 재설정하도록 구현하여야 한다.

 

15. 크로스사이트 리퀘스트 변조 (CF)

취약점 개요

점검내용
사용자의 신뢰(인증) 정보의 변조 여부를 점검한다.

점검목적
사용자 입력 값에 대한 적절한 필터링 및 인증에 대한 유효성을 검증하여 신뢰(인증) 정보 내의 요청(Request)에 대한 변조를 방지한다.

보안위협
사용자의 신뢰(인증) 정보 내에서 사용자의 요청(Request)을 변조함으로써 해당 사용자의 권한으로 악의적인 공격을 수행할 수 있다.

※ CSRF(Cross Site Request Forgery) : 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹 사이트에 요청하게 하는 공격 유형이다.
※ OWASP - CSRF 관련 참고사항
https://owasp.org/www-community/attacks/csrf

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 방화벽

판단기준
사용자 입력 값에 대한 필터링이 이루어지지 않으며, HTML 코드(또는 스크립트)를 입력하여 실행되는 경우에 취약하다고 판단한다.

조치방법
사용자 입력 값에 대해 검증 로직 및 필터링을 추가 적용한다.

점검 및 조치방안

점검방법
Step 1) XSS 취약점이 존재하는지 확인한다.
Step 2) 등록 및 변경 등의 데이터 수정 기능의 페이지가 있는지 조사한다.
Step 3) 데이터 수정 페이지에서 전송되는 요청(Request) 정보를 분석하여 임의의 명령을 수행하는 스크립트를 삽입 후 해당 게시글을 타 사용자가 열람하였을 경우 스크립트가 실행되는지 확인한다.

보안설정방법
* 웹 사이트에 사용자 입력 값이 저장되는 페이지는 요청이 일회성이 될 수 있도록 설계한다.
* 사용 중인 프레임워크에 기본적으로 제공되는 CSRF 보호 기능을 사용한다.
* 사용자가 정상적인 프로세스를 통해 요청하였는지 HTTP 헤더의 Referer 검증 로직을 구현한다.
* 정상적인 요청(Request)와 비정상적인 요청을 구분할 수 있도록 Hidden Form을 사용하여 임의의 암호화된 토큰(세션 ID, Timestamp, nonce 등)을 추가하고 이 토큰을 검증하도록 설계한다.
* HTML이나 Javascript에 해당되는 태그(Tag) 사용을 사전에 제한하고, 서버 단에서 사용자 입력 값에 대한 필터링을 구현한다.
* HTML Editor 사용으로 인한 상기사항 조치 불가 시, 서버 사이드(Server Side)/서블릿(Servlet)/DAO(Data Access Object) 영역에서 조치하도록 설계한다.
* XSS 조치 방안을 참조

 

16. 세션 에측 (SE)

취약점 개요

점검내용
단순한 방법(연속된 숫자 할당 등)으로 생성되는 세션 ID를 예측하여 세션 탈취 여부를 점검한다.

점검목적
사용자의 세션ID를 추측 불가능하도록 난수로 생성하여 공격자의 불법적인 접근을 차단하기 위함이다.

보안위협
사용자에게 전달하는 세션 ID가 일정한 패턴을 가지고 있는 경우 공격자가 세션 ID를 추측하여 불법적인 접근을 시도할 수 있다.

※ 세션(Session) : 일정 시간 동안 같은 사용자(브라우저)로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
세션 ID가 일정한 패턴으로 발급되는 경우에 취약하다고 판단한다.

조치방법
추측 불가능한 세션 ID가 발급되도록 로직을 구현한다.

점검 및 조치방안

점검방법
Step 1) 각기 다른 IP 주소와 다른 사용자명, 시간적 차이로 세션 ID를 발급받는다.
Step 2) 발급받은 세션 ID에 일정한 패턴이 있는지 조사한다.
Step 3) 일정한 패턴이 확인되고, 패턴에 의해 사용 가능한 세션 ID의 예측이 가능한지 확인한다.

보안설정방법
* 아무리 길이가 길고 복잡한 항목으로 세션 ID가 만들어져도 공격자가 충분한 시간과 자원이 있다면 뚫는 것은 불가능하지 않으므로 강격한 세션 ID를 생성하여야 한다.
(주된 목적은 수많은 대역폭 처리 자원을 가지고 있는 공격자가 하나의 유효한 세션 ID를 추측하는데 최대한 오랜 시간이 걸리게 하여 쉽게 추측하지 못하게 하는 것에 있다.)
* 단순 조합보다는 상용 웹 서버나 웹 애플리케이션 플랫폼에서 제공하는 세션 ID를 사용하고, 가능하다면 맞춤형 세션 관리 체계를 권고한다.
* 세션 ID는 로그인 시마다 추측할 수 없는 새로운 세션 ID로 발급하여야 한다.

 

17. 불충분한 인가 (IN)

취약점 개요

점검내용
민감한 데이터 또는 기능에 접근 및 수정 시에 통제 여부를 점검한다.

점검목적
접근 권한에 대한 검증 로직을 구현하여 비인가자의 악의적인 접근을 차단하기 위함이다.

보안위협
접근제어가 필요한 중요 페이지의 통제수단이 미흡한 경우, 비인가자가 URL 파라미터 값 변경 등의 방법으로 중요 페이지에 접근하여 민감한 정보 열람 및 변조가 가능하다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
접근제어가 필요한 중요 페이지의 통제수단이 미흡하여 비인가자의 접근이 가능한 경우 취약하다고 판단한다.

조치방법
접근제어가 필요한 모든 페이지에 권한검증 로직을 구현한다.

점검 및 조치방안

점검방법
Step 1) 비밀 게시글(또는 개인정보 변경, 패스워드 변경 등) 페이지에서 다른 사용자와의 구분을 ID, 일련번호 등의 단순한 값을 사용하는지 조사한다.
Step 2) 게시글을 구분하는 파라미터 값을 변경하는 것만으로 다른 사용자의 비밀 게시글(또는 개인정보 변경, 패스워드 변경 등)에 접근이 가능한지 확인한다.

보안설정방법
* 접근제어가 필요한 중요 페이지는 세션을 통한 인증 등 통제수단을 구현하여 인가된 사용자 여부를 검증 후 해당 페이지에 접근할 수 있도록 한다.
* 페이지별 권한 매트릭스를 작성하여 접근제어가 필요한 모든 페이지에서 권한 체크가 이뤄지도록 구현해야 한다.

 

18. 불충분한 세션 만료 (SC)

취약점 개요

점검내용
세션의 만료 기간 설정 여부를 점검한다.
(해당 취약점은 세션 만료의 기준이 내규별로 다르기에 잡지 않기도 한다.)

점검목적
세션 타임아웃 기능을 구현하여 공격자가 만료되지 않은 세션 활용을 방지하기 위함이다.

보안위협
세션의 만료 기간을 정하지 않거나, 만료기한을 너무 길게 설정된 경우, 악의적인 사용자가 만료되지 않은 세션을 활용하여 불법적인 접근이 가능할 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버

판단기준
세션 종료 시간이 설정되어 있지 않아 세션 재사용이 가능한 경우에 취약하다고 판단한다.

조치방법
세션 종료 시간 설정 또는 자동 로그아웃 기능 구현한다.
(세션 종료 시간은 사이트의 특성에 따라 달라질 수 있으므로 사이트의 특성에 맞게 적정 시간을 설정한다.)

점검 및 조치방안

점검방법
Step 1) 인증 후 정상적으로 세션이 발행된 페이지의 리퀘스트를 취득하여 일정 시간(사이트에 따라 다름)이 지난 후에 재전송 시 정상 처리가 되는지 확인한다.
(로그인 후 발급된 세션에 대하여 일정 시간 경과 후 세션 유지 여부를 확인한다.)

보안설정방법
* 세션 타임아웃을 구현한다.

 

19. 세션 고정 (SF)

취약점 개요

점검내용
사용자 로그인 시 항상 일정하게 고정된 세션 ID 값을 발행하는지 여부를 확인한다.

점검목적
로그인할 때마다 예측 불가능한 새로운 세션 ID를 발행하여 세션 ID의 고정 사용을 방지하기 위함이다.

보안위협
사용자 로그인 시 항상 일정하게 고정된 세션 ID가 발행되는 경우 세션 ID를 도용한 비인가자의 접근 및 권한 우회가 가능하다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
로그인 세션 ID가 고정 사용되거나 새로운 세션 ID가 발행되고, 기존 세션 ID는 파기될 경우

조치방법
사용자가 로그인할 때마다 예측 불가능한 새로운 세션 ID 생성 로직을 구현하고 기존 세션 ID는 파기한다.

점검 및 조치방안

점검방법
Step 1) 로그인시 세션 ID가 발행되는지 확인하고 로그아웃 후 다시 로그인할 때 예측 불가능한 새로운 세션 ID가 발급되는지 확인한다.

보안설정방법
* 로그인할 때마다 예측 불가능한 새로운 세션 ID를 발급받도록 해야 하고 기존 세션 ID는 파기해야 한다.

 

20. 자동화 공격 (AU)

취약점 개요

점검내용
웹 애플리케이션의 특정 프로세스(로그인 시도, 게시글 등록, SMS 발송 등)에 대한 반복적인 요청 시 통제 여부를 확인한다.

점검목적
무차별 대입 공격 및 자동화 공격으로 웹 애플리케이션의 자원이 고갈되는 것을 방지하기 위함이다.

보안위협
웹 애플리케이션의 특정 프로세스에 대한 반복적인 요청을 통제하지 않을 경우 무차별 대입 공격으로 인해 사용자 계정을 탈취할 수 있고, 자동화 공격으로 게시글 등록 또는 SMS 발송 요청을 반복하여 웹 애플리케이션 자원을 고갈시킬 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 방화벽

판단기준
웹 애플리케이션의 특정 프로세스에 대한 반복적인 요청 시 통제가 미흡한 경우에 취약하다고 판단한다.

조치방법
웹 애플리케이션의 특정 프로세스에 대한 대량 사용 통제 로직 구현 및 웹 방화벽 룰셋 설정을 통해 대량의 불특정 프로세스 요청을 차단한다.

점검 및 조치방안

점검방법
Step 1) 로그인 시도, 게시글 등록, SMS 발송 등에 대한 정상적인 요청 정보를 식별하여 반복적으로 요청 시 통제가 이루어지는지 확인한다.

보안설정방법
* 로그인 시도, 게시글 등록, SMS 발송 등에 대한 사용자 요청이 일회성이 될 수 있도록, 캡차(이미지를 이용하여 확인 값을 표시하고 사용자가 값을 등록하여 인증한다.) 등 일회성 확인 로직을 구현해야 한다.

※ 캡차(CAPTCHA) : 자동화된 컴퓨터와 사람을 판별하기 위한 기술의 일종이다.
* 자동화 공격을 시도하면 짧은 시간에 다량의 패킷(양)이 전송되므로 이를 공격으로 감지하고 방어할 수 있는 IDS/IPS 시스템을 구축하여야 한다.
(서버에 요청되는 패킷(양)의 모니터링이 불가능한 경우 적시에 적절한 대응이 어렵다.)

 

21. 프로세스 검증 누락 (PV)

취약점 개요

점검내용
인증이 필요한 웹 사이트의 중요 페이지(관리자 페이지, 회원변경 페이지 등)에 대한 접근제어 설정 여부를 확인한다.

점검목적
인증이 필요한 모든 페이지에 대해 유효 세션임을 확인하는 프로세스 및 주요 정보 페이지에 접근 요청자의 권한 검증 로직을 적용하여, 비인가자가 하위 URL 직접 접근, 스크립트 조작 등의 방법으로 중요한 페이지에 접근을 시도하는 것을 차단하기 위함이다.

보안위협
인증이 필요한 웹 사이트의 중요 페이지(관리자 페이지, 회원변경 페이지 등)에 대한 접근 제어가 미흡할 경우 하위 URL 직접 접근, 스크립트 조작 등의 방법으로 중요한 페이지에 대한 접근이 가능하다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
인증 후에 접근해야하는 웹 사이트의 하위 URL을 로그인하지 않고 직접 접근할 때 접근이 가능한 경우에 취약점으로 판단한다.

조치방법
인증이 필요한 페이지의 경우 페이지별 권한 체크 로직을 구현한다.

점검 및 조치방안

점검방법
Step 1) 업무 프로세스를 파악한다.
Step 2) 권한의 종류 및 범위를 파악한다.
Step 3) 페이지의 모든 기능을 수집하여 프로세스 상에 통제된 페이지에 접근이 가능한지 확인한다.

보안설정방법
* 우회될 수 있는 플로우를 차단하여야 하며, 페이지별 권한 매트릭스를 작성하여 페이지에 부여된 권한의 타당성을 체크한 후 권한 매트릭스를 기준으로 전 페이지에서 권한 체크가 이뤄지도록 구현해야 한다.
* 인증이 필요한 모든 페이지에 대해 유효 세션임을 확인하는 프로세스 및 주요 정보 페이지에 접근 요청자에 대한 권한 검증 로직을 적용한다.
* 유효 세션 검증 및 페이지에 대한 접근 권한을 Client Side Script에 의존할 경우 사용자가 임의로 수정할 수 있으므로 Server Side Script로 구현된 프로세스를 사용한다.

 

22. 파일 업로드 (FU)

취약점 개요

점검내용
웹 사이트의 게시판, 자료실 등에 조작된 Server Side Script 파일 업로드 및 실행 가능 여부를 점검한다.

점검목적
업로드되는 파일의 확장자에 대한 적절성 여부를 검증하는 로직을 통해 공격자가 조작된 Server Side Script 파일 업로드 방지 및 서버상에 저장된 경로를 유추하여 해당 Server Side Script 파일 실행을 불가능하게 하기 위함이다.

보안위협
해당 취약점이 존재할 경우 공격자는 조작된 Server Side Script 파일을 서버에 업로드 및 실행하여 시스템 관리자 권한 획득 또는 인접 서버에 대한 침입을 시도할 수 있다.

※ Server Side Script : 웹에서 사용되는 스크립트 언어 중 서버 측에서 실행되는 스크립트이다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버, 웹 방화벽

판단기준
업로드되는 파일에 대한 확장자 검증이 이루어지지 않는 경우에 취약하다고 판단한다.

조치방법
업로드되는 파일에 대한 확장자 검증 및 실행 권한을 제거한다.

점검 및 조치방안

점검방법
Step 1) 웹 사이트에 파일 업로드 기능이 존재하는 경우, 확장자가 jsp, php, asp, cgi 등의 Server Side Script 파일들이 업로드 가능한지 확인한다.
(※ 클라이언트에서 JavaScript 등의 스크립트로 파일 첨부를 차단하는 경우 차단 기능을 수정하여 파일 첨부한다.)
Step 2) 웹 사이트에 있는 디렉터리 정보를 이용하여 첨부한 Server Side Script 파일의 위치를 조사한 후 브라우저 주소창에 해당 경로를 입력하여 실행 가능한지 확인한다.

보안설정방법
※ 사용자가 파일을 업로드할 수 있는 모든 모듈에 적용이 필요하다.
* 화이트 리스트 방식으로 허용된 확장자만 업로드 가능하도록 서버 측 통제를 적용한다.
* 업로드되는 파일을 디렉터리에 저장할 때 파일명과 확장자를 외부 사용자가 추측할 수 없는 문자열로 변경하여 저장한다.(파일 이름은 DB에 저장한다.)
* 업로드 파일을 위한 전용 디렉터리를 별도로 생성하여 웹 서버 데몬 설정 파일(httpd.conf 등)에서 실행 설정을 제거함으로써, Server Side Script가 업로드되더라도 웹 엔진이 실행하지 않는 환경을 설정한다.
* 파일 업로드 필드를 대상으로 특수문자를 필터링하도록 웹 방화벽 룰셋을 적용한다.

※ 유형 별 상세 설정
● 웹 애플리케이션
1) 수용 가능한 파일의 확장자만 업로드를 허용한다.(Positive 방식)
- 이미지 파일의 경우 (JPG, GIF, BMP 등)
- 문서 파일의 경우 (XLS, PDF, PPT, DOC 등)
* 확장자 검증 시 대소문자 구분없이 문자열을 비교한다.
2) MIME TYPE 확인을 통한 실행 파일 업로드를 차단한다.

● 웹 서버
- 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 호출을 금지 시킨다.

※ 주의할 점
- Apache 서버의 경우 AllowOverride 지시자 변경 시 Apache Restart가 필요하다.
- 파일 업로드 되는 디렉터리에 운영에 필요한 Server Side Script가 존재하는지 확인한다.
- 파일 다운로드 프로그램이 아닌 직접 URL 호출을 통해 파일을 다운받는 경우 FileMatch 지시자를 사용하면 차단 설정한 확장자의 파일 다운로드는 거부된다.

* 첨부 파일 확장자 필터링 처리로 사용자가 첨부 파일의 업로드 시도 시, 업로드 파일의 확장자를 검토하여 적절한 파일인지 검사하는 루틴을 삽입하여, 적합한 파일의 확장자 이외의 파일에 대해서 업로드가 불가능하도록 하며, 이런 필터링 규칙은 서버에서 구현하여야 한다.
* 시스템 보안 설정 시 웹 서버 구동은 반드시 관리자 권한이 아닌 일반 사용자 권한으로 구동하도록 한다.
* 외부 사용자가 첨부 파일을 이용하여 권한을 획득할지라도 최소한의 권한만을 사용할 수 있도록 한다.
* 업로드된 디렉터리에서 실행 권한을 제거하는 방법은 임시적이기는 하지만 소스 코드의 수정 없이 간단히 수행될 수 있다.

● 웹 방화벽
* 웹 쉘에 주로 사용되는 문자열, 오브젝트, 메소드 등을 시그니처로 지정하여 파일 업로드 시 탐지 및 차단한다.

 

23. 파일 다운로드 (FD)

취약점 개요

점검내용
웹 사이트에서 파일 다운로드 시 허용된 경로 외 다른 경로의 파일 접근이 가능한지 여부를 점검한다.

점검목적
파일 다운로드 시 허용된 경로 외 다른 경로의 파일 접근을 방지하여 공격자가 임의의 위치에 있는 파일을 열람하거나 다운받는 것을 불가능하게 하기 위함이다.

보안위협
해당 취약점이 존재할 경우 공격자는 파일 다운로드 시 애플리케이션의 파라미터 값을 조작하여 웹 사이트의 주요한 파일(DB 커넥션 파일, 애플리케이션 파일 등) 또는 웹 서버 루트에 있는 중요한 설정 파일(passwd, shadow 등)을 다운받을 수 있다.
(cgi, jsp, php 등 파일 다운로드 기능을 제공해주는 애플리케이션에서 입력되는 경로를 검증하지 않는 경우 임의의 문자(../.. 등)나 주요 파일명의 입력을 통해 웹 서버의 홈 디렉터리를 벗어나서 임의의 위치에 있는 파일을 열람하거나 다운 받는 것이 가능하다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버, 웹 방화벽

판단기준
다운로드 파일이 저장된 디렉터리 이외에 접근이 가능한 경우 취약하다고 판단한다.

조치방법
다운로드 시 허용된 경로 이외의 디렉터리와 파일에 접근할 수 없도록 구현한다.

점검 및 조치방안

점검방법
Step 1) 웹 사이트에 cgi, jsp, php 등의 애플리케이션을 이용하여 파일을 다운받는 페이지가 있는지 조사한다.
Step 2) 웹 사이트에서 파일 다운로드시 요청(Request) 정보에 파일 경로를 웹 서버(웹 사이트 포함) 중요파일(winnt\win.ini, /etc/passwd 등)의 상대 경로(../)로 치환한 후 전송했을 때 해당 경로 파일들을 다운로드 가능한지 확인한다.
../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../winnt/win.ini
../../../../../../../../../../../../boot.ini
Step 3) "Step 2"에서 파일 다운로드가 불가능한 경우 변조한 파일 경로를 아래의 인코딩(또는 치환, 종단문자추가)을 적용하여 재전송 후 다운로드 가능한지 확인한다.

※ URL 인코딩: .(%2e), /(%2f), \(%5c)
※ 16bit 유니코드 인코딩: .(%u002e), /(%u2215), \(%u2216)
※ 더블URL 인코딩: .(%252e), /(%252f), \(%255c)
※ 경로 치환: …//, ….\\, ….\/, …./\
※ 종단 문자 추가: [파일명]%00.jpg, [파일명]%0a.jpg

보안설정방법
* 파일 다운로드의 취약성은 주로 파일의 이름을 조작하는 데서 비롯되므로 다운로드 파일 이름을 데이터베이스에 저장하고 다운로드 수행 시 요청 파일 이름과 비교하여 적절한지 확인하여 사용자가 조작할 수 있는 변수를 제거한다.
* 다운로드 애플리케이션 소스 파일을 수정하여 파일을 다운받을 수 있는 디렉터리를 특정 디렉터리로 한정하고 이 외의 다른 디렉터리에서는 파일을 다운받을 수 없도록 설정해야 한다.
* PHP를 사용하는 경우 php.ini에서 magic_quotes_gpc를 On으로 설정하여 .￦(\)./ 와 같은 역 슬래시 문자 입력 시 치환되도록 설정한다.
* 파일 다운로드의 절대 경로 설정 및 DocBase의 상위경로 또는 타 드라이브로 설정을 변견한다.
* 다운로드 경로 정보를 자바스크립트나 js 소스에서 확인할 수 없게 제한하며, 웹 서버 서블릿 내부 또는 별도의 설정 파일에서 관리한다.
* 다운로드를 제공하는 페이지의 유효 세션 체크 로직을 필수 적용한다.
* 다운로드 시 사용되는 파라미터 값 대상으로 다음의 특수문자를 필터링하도록 웹 방화벽 룰셋을 적용한다.
- Path Traversal 가능성의 확인( . )
- 특정 Path의 접근 가능성을 확인( / )
- 운영환경에 따른 Path 접근을 확인( ￦(\) )
- UTF 인코딩 파라미터( % )

 

24. 관리자 페이지 노출 (AE)

취약점 개요

점검내용
유추하기 쉬운 URL로 관리자 페이지 및 메뉴 접근의 가능 여부를 점검한다.

점검목적
관리자 페이지 URL이 유추하기 쉬운 이름(admin, manager 등) 및 웹 사이트 설계 오류를 수정하여 비인가자의 관리자 메뉴 접근을 방지하기 위함이다.

보안위협
웹 관리자의 권한이 노출될 경우 웹 사이트의 변조뿐만 아니라 취약성 정도에 따라서 웹 서버의 권한까지도 노출될 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버, 웹 방화벽

판단기준
유추하기 쉬운 URL로 관리자 페이지 접근이 가능한 경우에 취약하다고 판단한다.

조치방법
유추하기 어려운 이름(포트 번호 변경 포함)으로 관리자 페이지를 변경하여 비인가자가 관리자 페이지에 접근할 수 없도록 하고 근본적인 해결을 위해 지정된 IP만 관리자 페이지에 접근할 수 있도록 제한하여야 한다.
(단, 부득이하게 관리자 페이지를 외부에 노출해야 하는 경우 관리자 페이지 로그인 시 2차 인증(otp, vpn, 인증서 등)의 적용이 필요하다.

점검 및 조치방안

점검방법
Step 1) 추측하기 쉬운 관리자 페이지 경로(/admin, /manager, /master, /system 등) 접근을 시도하여 관리자 페이지가 노출되는지 확인한다.
Step 2) 추측하기 쉬운 포트(7001, 8080, 8443, 8888 등) 접속을 시도하여 관리자 페이지가 노출되는지 확인한다.
Step 3) 관리자 페이지의 로그인 창에 기본 관리자 계정(admin, administrator, manager 등) 및 패스워드를 입력하여 로그인 가능한지 확인한다.
Step 4) 관리자 페이지 로그인 후 식별된 하위 페이지(/admin/main.asp, /admin/menu.html 등) URL을 새 세션에서 직접 입력하여 인증 과정 없이 접근 가능한지 확인한다.

보안설정방법
* 일반 사용자의 접근이 불필요한 관리자 로그인 페이지 주소를 유추하기 어려운 이름으로 변경하고 관리자 페이지 접근 포트도 변경한다.
* 관리자 페이지의 하위 페이지 URL을 직접 입력하여 접근하지 못하도록 페이지마다 세션 검증이 필요하다.
* 관리자 페이지 이외에도 특정 사용자만 접근 가능한 페이지들은 정상적인 프로세스에 따라 접근할 수 있도록 페이지마다 세션 검증이 필요하다.
* 웹 방화벽을 이용하여 특정 IP만 접근 가능하도록 룰셋을 적용한다.

 

25. 경로 추적 (PT)

취약점 개요

점검내용
웹 서버와 웹 애플리케이션의 파일 또는 디렉터리의 접근 통제 여부를 점검한다.

점검목적
웹 서버 또는 웹 애플리케이션의 중요한 파일과 데이터의 접근 및 실행을 방지하기 위함이다.

보안위협
웹 서버와 웹 애플리케이션의 파일 또는 디렉터리 접근이 통제되지 않아 웹 서버 또는 웹 애프리케이션의 중요한 파일과 데이터에 접근을 허용하는 취약점으로 웹 루트 디렉터리에서 외부의 파일까지 접근하여 이를 실행할 수 있다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버, 웹 방화벽

판단기준
웹 루트 디렉터리보다 상위 디렉터리에 접근이 가능한 경우에 취약하다고 판단한다. (ex : /root)

조치방법
사용자가 임의로 접근할 수 있는 최상위 디렉터리를 웹 루트 디렉터리로 설정하여 웹 서버의 시스템 루트 디렉터리 로 접근하지 못하게 제한한다.

점검 및 조치방안

점검방법
Step 1) 웹 브라우저에 표시할 페이지를 지정하는 파라미터 값을 임의의 경로가 포함된 값으로 변조 후 전송하여 해당경로의 파일 내용이 웹 브라우저에 표시되는지 확인한다.
../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../winnt/win.ini
../../../../../../../../../../../../boot.ini
Step 2) "Step 1)"에서 변조하여 전송한 파라미터 값을 아래의 인코딩(또는 치환, 종단문자 추가)을 적용하여 재전송 후 해당경로의 파일 내용이 웹 브라우저에 표시되는지 확인한다.
※ URL 인코딩: .(%2e), /(%2f), \(%5c)
※ 16bit 유니코드 인코딩: .(%u002e), /(%u2215), \(%u2216)
※ 더블URL 인코딩: .(%252e), /(%252f), \(%255c)
※ 경로 치환: …//, ….\\, ….\/, …./\
※ 종단 문자 추가: [파일명]%00.jpg, [파일명]%0a.jpg

보안설정방법
* 웹 사이트에서 접근하려는 파일이 있는 디렉터리에 chroot 환경 적용 시 경로 추적 공격을 최소화할 수 있다.
- chroot 디렉터리는 해당 디렉터리가 루트처럼 다루어진다. chroot 파일 시스템은 대부분의 유닉스를 기반으로 한 플랫폼에서 지원 가능하며, 윈도우 플랫폼에서는 적절한 시작 디렉터리를 새로운 논리 드라이브로 만들어 웹 사이트에서 해당 드라이브를 통하여 접근하게 한다.
* 애플리케이션 소스 파일을 수정하여 파일 내용을 웹 브라우저에 표시할 수 있는 디렉터리를 특정 디렉터리로 한정하고 이 외의 다른 디렉터리에서는 파일 내용을 표시할 수 없도록 설정해야 한다.

 

27. 데이터 평문 전송 (SN)

취약점 개요

점검내용
서버와 클라이언트 간 통신 시 데이터의 암호화 여부를 점검한다.

점검목적
서버와 클라이언트 간 통신 시 데이터의 암호화 전송 미흡으로 정보 유출의 위험을 방지하기 위함이다.

보안위협
웹상의 데이터 통신은 대부분 텍스트 기반으로 이루어지기 때문에 서버와 클라이언트 간에 암호화 프로세스를 구현하지 않으면 간단한 도청(Sniffing)을 통해 정보를 탈취 및 도용할 수 있다.

※ Sniffing : 스니퍼를 이용하여 네트워크상의 데이터를 도청하는 행위를 말한다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드, 웹 서버

판단기준
중요정보 전송구간에 암호화 통신이 이루어지지 않는 경우에 취약하다고 판단한다.

조치방법
사이트의 중요정보 전송구간(로그인, 회원가입, 회원정보관리, 게시판 등) 암호화 통신(https, 애플리케이션방식)을 적용한다.

점검 및 조치방안

점검방법
Step 1) 중요정보(인증정보, 개인정보 등)를 송수신하는 페이지의 존재 여부를 확인한다.
Step 2) 중요정보 송수신 페이지가 암호화 통신(https, 데이터 암호화 등)을 하는지 확인한다.
Step 3) 취약한 버전의 암호 프로토콜 사용 시 암호화된 통신 내용이 유출될 수 있으므로, 취약한 버전의 SSL(SSL 2.0, 3.0) 사용 여부를 점검한다.

보안설정방법
* 웹상에서의 전송 정보를 제한하여 불필요한 비밀번호, 주민등록번호, 계좌정보와 같은 중요정보의 전송을 최소화하여야 하며, 중요정보에 대해서는 반드시 SSL 등의 암호화 통신을 사용하여 도청으로부터의 위험을 제거해야한다.
* 쿠키와 같이 클라이언트 측에서 노출되는 곳에 비밀번호, 인증인식 값, 개인정보 등의 정보를 기록하지 않는다.
* 암호화 전송 시 프로토콜 설계의 결함이 있는 SSLv2, SSLv3, TLSv1.0, TLSv1.1은 필수적으로 비활성화 하고, TLSv1.2 이상 사용을 권장한다.

 

28. 쿠키 변조 (CC)

취약점 개요

점검내용
쿠키 사용 여부 및 사용하는 경우 안전한 알고리즘으로 암호화 하고 있는지 여부를 점검한다.

점검목적
쿠키를 사용하는 경우 안전한 알고리즘으로 암호화하여 공격자가 쿠키 인젝션 등과 같은 쿠키 값 변조를 통한 다른 사용자로의 위장 및 권한 변경을 방지하고자 한다.

보안위협
클라이언트에 전달되는 쿠키에 사용자 식별 값이 평문으로 노출될 경우 쿠키 변조를 통해 다른 사용자의 유효한 세션을 취득할 수 있으며, 기타 중요정보의 유출 및 변조가 가능하다.

※ 쿠키(Cookie) : 인터넷 사용자가 어떤한 웹 사이트를 방문할 경우 그 사이트가 사용하고 있는 서버에서 인터넷 사용자의 컴퓨터에 설치하는 작은 기록 정보 파일이다.

점검대상 및 판단기준

대상 : 웹 애플리케이션 소스코드

판단기준
안전한 알고리즘이 적용되어있지 않은 쿠키(또는 Session)를 사용하거나, Client Side Session을 사용하는 경우에 취약하다고 판단한다.

조치방법
쿠키 대신 Server Side Session 방식을 사용하거나, 쿠키를 통해 인증 등 중요한 기능을 구현해야 할 경우엔 안전한 알고리즘(SEED, 3DES, AES 등)을 적용한다.

점검 및 조치방안

점검방법
Step 1) 쿠키 내용 및 발행되는 쿠키에 중요정보(인증을 위한 ID, 권한을 위한 구분자 등)의 노출 여부를 조사한다.
Step 2) 쿠키의 중요정보를 변경하여 다른 사용자 및 권한으로 정상 이용이 가능한지 확인한다.

보안설정방법
* 쿠키 대신 보안성이 강한 Server Side Session 방식을 사용한다.
(Client Side Session 방식인 쿠키느 그 구조상 다양한 취약점에 노출될 수 있다.)
* 쿠키(또는 세션)를 사용해서 중요정보나 인증으 구현해야 할 경우엔 안전한 알고리즘을 적용한다.
* HTTP 헤더에 다음과 같이 설정하여 세션 ID 값은 HTTPS를 통해서만 전송되도록 설정하고, 자바스크립트를 통해 세션 ID 값 등 쿠키 정보가 유출되지 않도록 보호한다.

Set-Cookie : secure, HttpOnly
Set-Cookie : domain=app.mysite.com
※ HttpOnly 설정 관련 참고사항
https://msdn.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx
https://www.owasp.org/index.php/HttpOnly