목차

• 1. 버퍼 오버플로우
• 2. 포맷스트링
• 3. LDAP 인젝션
• 4. 운영체제 명령 실행
• 5. SQL 인젝션
• 6. SSI 인젝션
• 7. XPath 인젝션
• 8. 디렉터리 인덱싱
• 9. 정보 누출
• 10. 악성 콘텐츠
• 11. 크로스사이트 스크립팅
• 12. 약한 문자열 강도
• 13. 불충분한 인증
• 14. 취약한 패스워드 복구
• 15. 크로스사이트 리퀘스트 변조
• 16. 세션 예측
• 17. 불충분한 인가
• 18. 불충분한 세션 만료
• 19. 세션 고정
• 20. 자동화 공격
• 21. 프로세스 검증 누락
• 22. 파일 업로드
• 23. 파일 다운로드
• 24. 관리자 페이지 노출
• 25. 경로 추적
• 26. 위치 공개
• 27. 데이터 평문 전송
• 28. 쿠키 변조

점검항목

1. 버퍼 오버플로우(Buffer Overflow), BO

점검내용

사용자가 입력한 파라미터 값의 문자열 길이 제한 확인

보안위협

웹 사이트에서 사용자가 입력한 파라미터 값의 문자열 길이를 제한하지 않는 경우 개발 시에 할당된 저장 공간보다 더 큰 값의 입력이 가능하고 이로 인한 오류 발생 시 의도되지 않은 정보 노출, 프로그램에 대한 비인가 접근 및 사용 등이 발생할 수 있음

보안설정방법

• 웹 서버, 웹 애플리케이션 서버 버전을 안정성이 검증된 최신 버전으로 패치
• 웹 애플리케이션에 전달되는 파라미터 값을 필요한 크기만큼만 받을 수 있도록 변경하고 입력 값 범위를 초과한 경우에도 에러 페이지를 반환하지 않도록 설정
• 동적 메모리 할당을 위해 크기를 사용하는 경우 그 값이 음수가 아닌지 검사하여 버퍼 오버플로우를 예방하는 형태로 소스 코드 변경
• 버퍼 오버플로우를 점검하는 웹 스캐닝 툴을 이용하여 주기적으로 점검검

참고

• 버퍼 오버플로우 공격(Buffer Overfloaw Attack) 원리와 개념
• 버퍼 오버플로

2. 포맷스트링(Format String), FS

점검내용

웹 애플리케이션에 포맷 스트링 취약점 존재 여부 점검

보안위협

C언어로 만드는 프로그램 중 변수의 값을 출력하거나 입력받을 때 입력받은 값을 조작하여 프로그램의 메모리 위치를 반환받아 메모리 주소를 변조하여 시스템의 관리자 권한을 획득할 수 있음

보안설정방법

• 컴파일러에서 문자열 입력 포맷에 대한 자체적인 검사를 내장하고 있으므로 문자열 입력 포맷 검증 후 소스 코드에 적용
• 웹 서버 프로그램 최신 보안패치 적용
• 웹 사이트에서 사용자가 입력한 파라미터 값 처리 중에 발생한 경우 사용자 입력 값의 유효성에 대한 검증 로직을 구현

참고

• 버퍼 오버플로우 공격 - 포맷 스트링 공격

3. LDAP 인젝션(LDAP Injection), LI

점검내용

웹페이지 내 LDAP 인젝션 취약점 점검

보안위협

• 응용 프로그램이 사용자 입력 값에 대한 적절한 필터링 및 유효성 검증을 하지 않아 공격자는 로컬 프록시를 사용함으로 LDAP 문의 변조가 가능함
• 공격 성공 시 승인되지 않은 쿼리에 권한을 부여하고, LDAP 트리 내의 내용 수정이나 임의의 명령 실행을 가능하게 하므로 적절한 필터링 로직을 구현하여야 함

보안설정방법

• 사용자 입력 값을 화이트 리스트로 지정하여 영문(a-z, A-Z)과 숫자(0-9)만을 허용
• DN과 필터에 사용되는 사용자 입력 값에는 특수문자가 포함되지 않도록 특수문자 제거
• 특수문자를 사용해야 하는 경우 특수문자(DN에 사용되는 특수문자는 ‘', 필터에 사용되는 특수문자는 =, +, <, >, #, ;, \ 등)에 대해서는 실행 명령이 아닌 일반문자로 인식되도록 처리
• 필터링 대상

  '	"	--	#	(	)
  =	*/	/*	+	<	>
  user_tables	user_table_columns		table_name	column_name	Syscolumns
  union	select	insert	drop	update	and
  or	If	join	substring	from	where
  declare	substr	openrowset	xp_	sysobject	%
  *	;	&	|

• 웹 방화벽에 LDAP 관련 특수문자를 필터링하도록 룰셋 적용

참고

• LDAP injection
• LDAP DNs and RDNs

4. 운영체제 명령 실행(OS Command Execution), OC

점검내용

웺 사이트 내 운영체제 명령 실행 취약점 존재 여부 점검

보안위협

해당 취약점이 존재하는 경우 부적절하게 권한이 변경되거나 시스템 동작 및 운영에 악영향을 줄 가능성이 있으므로 “|”, “&”, “;”, “`” 문자에 대한 필터링 구현이 필요함

보안설정방법

• 웹 방화벽에 모든 사용자 입력 값을 대상으로 악용될 수 있는 특수문자, 특수 구문 등을 필터링 할 수 있도록 규칙 적용
• 애플리케이션은 운영체제로부터 명령어를 직접적으로 호출하지 않도록 구현
• 명령어를 직접 호출하는 것이 필요한 경우에는, 데이터가 OS의 명령어 해석기에 전달되기 전에 입력 값을 검증/확인하도록 구현
• 입력 값에 대한 파라미터 데이터의 “&”, “|”, “;”, “`” 문자에 대한 필터링 처리
  • &: 윈도우 명령어 해석기에서 첫 번째 명령이 성공했을 경우만 두 번째 명령어를 실행
  • |: 첫 번째 명령어가 성공하는지에 상관없이 두 번째 명령어를 실행
  • `: 쉘 해석기가 명령어를 해석하다 역 작은따옴표(`) 내에 포함된 명령어를 만나면 기존 명령어를 계속 실행하기 전에 역 작은따옴표로 둘러싸인 명령어를 먼저 실행
• 웹 서버 및 웹 애플리케이션 서버는 공개적으로 알려진 취약점이 제거된 상위 버전으로 업데이트해야 함
• 클라이언트에서 전송되는 요청(Request) 값에 대한 엄격한 필터링 적용 및 OGNL(Object Graph Navigation Language) 표현식 사용을 금지하여 원격에서 임의의 명령어가 실행되지 않도록 구현해야 함

참고

• Search CVE List
• Search Vulnerability Database

5. SQL 인젝션(SQL Injection), SI

점검내용

웹페이지 내 SQL 인젝션 취약점 존재 여부 점검

보안위협

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

보안설정방법

• SQL 쿼리에 사용되는 문자열의 유효성을 검증하는 로직 구현

• 아래와 같은 특수문자를 사용자 입력 값으로 지정 금지

  문자	설명
  '	문자 데이터 구분기호
  ;	쿼리 구분 기호
  --, #	해당라인 주석 구분 기호
  /* */	* 와 */ 사이 구문 주석

• Dynamic SQL 구문 사용을 지양하며 파라미터에 문자열 검사 필수적용
• 시스템에서 제공하는 에러 메시지 및 DBMS에서 제공하는 에러 코드가 노출되지 않도록 예외처리
• 웹 방화벽에 인젝션 공격 관련
• 문자열 유효성 검증 로직 구현

참고

• JSP, PHP, ASP 개념 / 장단점 / 비교

6. SSI 인젝션(SSI Injection), SS

점검내용

웹페이지 내 SSI 인젝션 공격 가능성 점검

보안위협

• 해당 취약점이 존재할 경우 웹 서버 상에 있는 파일을 include 시켜 명령문이 실행되게 함으로 불법적으로 데이터에 접근할 수 있음
• 공통 SSI 구현은 외부의 파일을 include 할 수 있는 명령어를 제공하며, 웹서버의 CGI 환경 변수를 설정하고 출력할 수 있고, 외부의 CGI 스크립트나 시스템 명령어들을 실행할 수 있으므로 사용자 입력 값에 대한 검증 로직을 추가로 구현하여야 함

보안설정방법

• 사용자 입력으로 사용 가능한 문자들을 정해놓음
• 정해진 문자들을 제외한 나머지 모든 문자들을 필터링 함
• 필터링 해야 하는 대상은 GET 질의 문자열, POST 데이터, 쿠키, URL, 그리고 일반적으로 브라우저와 웹 서버가 주고받는 모든 데이터를 포함하며, 아래는 특수문자에 대한 Entity 형태를 표시한 것임
• 웹 서버의 SSI 기능을 사용하지 않거나, 웹 방화벽에 특수문자를 필터링하도록 룰셋 적용

참고

• SSI 인젝션 개념 정리 및 실습

7. XPath 인젝션(XPath Injection), XI

점검내용

웹페이지 내 조작된 XPath 쿼리 공격 가능성 점검

보안위협

해당 취약점이 존재할 경우 프로그래머가 의도하지 않았던 문자열을 전달하여 쿼리문의 의미를 왜곡시키거나 그 구조를 변경하고 임의의 쿼리를 실행하여 인가되지 않은 데이터를 열람할 수 있으므로 적절한 필터링 로직 구현이 필요함

보안설정방법

XPath 쿼리에 사용자가 값을 입력할 수 있는 경우, 엄격한 입력 값 검증을 통해 필요문자만을 받아들이게 함 (, ), =, \, [, ], :, ,, *, / 등 XPath 쿼리를 파괴하는 특수문자를 입력하지 못하게 막아야 하며, 특정 특수문자만을 필터링하는 것이 아닌 허용된 문자 이외의 모든 입력을 허용하지 않아야 함

참고

• XPath Injection

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

점검내용

웹 서버 내 디렉터리 인덱싱 취약점 존재 여부 점검

보안위협

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

보안설정방법

• 웹 서버 환경설정에서 디렉터리 인덱싱 기능 제거

참고

• 4. 디렉토리 인덱싱 취약점

9 정보 누출(Information Leakage), IL

점검내용

웹 서비스 시 불필요한 정보가 누출되는지 여부 점검

보안위협

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

보안설정방법

• 사용자가 주민등록번호 뒷자리, 비밀번호 입력 시 별표 표시하는 등 마스킹 처리를 하여 주변 사람들에게 노출되지 않도록 함
• 개인정보의 조회, 출력 시 아래와 같은 원칙으로 일부 정보에 마스킹을 적용하여 표시
  • 성명 중 이름의 가운데 글자 (e.g. 홍*동)
  • 생년월일 (e.g. **년 **월 **일)
  • 전화번호 또는 휴대전화번호 (e.g. 02-****-5678, 010-****-5678)
  • 주소의 읍/면/동 (e.g. 서울시 송파구 **동)
  • IP v4 주소의 경우 17 ~ 24bit, IP v6의 경우 113 ~ 128bit
• 웹페이지를 운영 서버에 이관 시 주석은 모두 제거하여 이관
• 중요정보(개인정보, 계정정보, 금융정보 등)를 HTML 소스에 포함하지 않도록 함
• 로그인 실패 시 반환되는 에러 메시지는 특정 ID의 가입 여부를 식별할 수 없게 구현 (e.g. 가입하지 않은 아이디이거나, 잘못된 비밀번호입니다.)
• 일반적으로 웹에서 발생하는 에러 메시지는 400, 500번대의 에러 코드를 반환하는데 이러한 에러 코드에 대해 별도의 에러 페이지로 redirect 하거나 적절한 에러처리 루틴을 설정하여 처리되도록 함(전체적인 통합 에러 페이지를 작성한 후 모든 에러 코드에 대해 통합 에러 페이지로 redirect 되도록 설정)

참고

10. 악성 콘텐츠(), CS

점검내용

게시판 등에 악성 콘텐츠 삽입 및 실행 여부 점검

보안위협

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

보안설정방법

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

참고

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

점검내용

웹 사이트 내 크로스사이트 스크립팅 취약점 존재 여부 점검

보안위협

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

보안설정방법

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

  <	>	& lt;	& gt;	javascript	innerHTML
  eval	onmousewheel	onactive	expression	charset	onfocusout
  ondataavailable	oncut	onkeyup	applet	document	onafteripudate
  onclick	onkeypress	meta	string	onmousedown	onchange
  onload	xml	create	onbeforeactivate	onbeforecut	onbounce
  blink	append	onbeforecopy	ondbclick	onmouseenter	link
  binding	onbeforedeactivate	ondeactivate	onmouseout	style	alert
  ondatasetchaged	ondrag	onmouseover	script	msgbox	cnbeforeprint
  ondragend	onsubmit	embed	refresh	cnbeforepaste	ondragenter
  onmouseend	object	void	onbeforeeditfocus	ondragleave	onresizestart
  iframe	cookie	onbeforeuload	ondragover	onuload	frame
  href	onbeforeupdate	ondragstart	onselectstart	frameset	onpaste
  onpropertychange	ondrop	onreset	ilayer	onresize	ondatasetcomplete
  onerror	onmove	layer	onselect	oncellchange	onfinish
  onstop	bgsound	base	onlayoutcomplete	onfocus	onrowexit
  title	onblur	onselectionchange	vbscript	onerrorupdate	onbefore
  onstart	onrowsinserted	onkeydown	onfilterchage	onmouseup	onfocusin
  oncontrolselected	onrowsdelete	onlosecapture	onrowenter	onhelp	onreadystatechange
  onmouseleave	onmousemove	oncontextmenu

참고

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

점검내용

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

보안위협

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

보안설정방법

• 취약한 계정 및 패스워드를 삭제하고, 사용자가 취약한 계정이나 패스워드를 등록하지 못하도록 패스워드 규정이 반영된 체크 로직을 회원가입, 정보변경, 패스워드 변경 등 적용 필요한 페이지에 모두 구현하여야 함
• 규정 예시
  1. 다음 각 목의 문자 종류 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성
     (1) 영문 대문자(26개)
     (2) 영문 소문자(26개)
     (3) 숫자(10개)
     (4) 특수문자(32개)
  2. 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고
  3. 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경
  4. 최근 사용되었던 패스워드 재사용 금지
• 로그인 시 패스워드 입력 실패가 일정 횟수(3 ~ 5회) 이상 초과할 경우 관리자에게 통보 및 계정 잠금

참고

13. 불충분한 인증(Insufficient Authentication), IA

점검내용

중요 페이지 접근 시 추가 인증 요구 여부 점검

보안위협

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

보안설정방법

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

참고

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

점검내용

웹 사이트 내 패스워드 복구 절차의 적절성 점검

보안위협

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

보안설정방법

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

참고

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

점검내용

사용자의 신뢰(인증) 정보의 변조 여부 점검

보안위협

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

보안설정방법

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

참고

16. 세션 예측(Session Prediction), SE

점검내용

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

보안위협

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

보안설정방법

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

참고

17. 불충분한 인가(Insufficient Authorization), IN

점검내용

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

보안위협

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

보안설정방법

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

참고

18. 불충분한 세션 만료(Insufficient Session Close), SC

점검내용

세션의 만료 기간 설정 여부 점검

보안위협

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

보안설정방법

세션 타임아웃 구현 시 타임아웃 시간은 10분으로 설정할 것을 권고함

참고

19. 세션 고정(Session Fixation), SF

점검내용

사용자 로그인 시 항상 일정하게 고정된 세션 ID 값을 발행하는 지 여부 확인

보안위협

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

보안설정방법

로그인할 때마다 예측 불가능한 새로운 세션 ID를 발급받도록 해야 하고 기존 세션 ID는 파기해야 함

참고

20. 자동화 공격(Automation Attack), AU

점검내용

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

보안위협

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

보안설정방법

로그인 시도, 게시글 등록, SMS 발송 등에 대한 사용자 요청이 일회성이 될 수 있도록, 캡챠(이미지를 이용하여 확인 값을 표시하고 사용자가 값을 등록하여 인증함) 등 일회성 확인 로직을 구현하여야 함

• 자동화 공격을 시도하면 짧은 시간에 다량의 패킷(양)이 전송되므로 이를 공격으로 감지하고 방어할 수 있는 IDS/IPS 시스템을 구축하여야 함. 서버에 요청되는 패킷(양)의 모니터링이 불가능한 경우 적시에 적절한 대응이 어려움

참고

21. 프로세스 검증 누락(Process Verification Missing), PV

점검내용

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

보안위협

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

보안설정방법

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

참고

22. 파일 업로드(File Upload), FU

점검내용

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

보안위협

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

보안설정방법

• 사용자가 파일을 업로드할 수 있는 모든 모듈에 적용 필요
• 화이트 리스트 방식으로 허용된 확장자만 업로드 가능토록 서버 측 통제 적용
• 업로드되는 파일을 디렉터리에 저장할 때 파일명과 확장자를 외부 사용자가 추측할 수 없는 문자열로 변경하여 저장(파일 이름은 DB에 저장)
• 업로드 파일을 위한 전용 디렉터리를 별도로 생성하여 웹 서버 데몬 설정 파일(httpd.conf 등)에서 실행 설정을 제거함으로써, Server Side Script가 업로드되더라도 웹 엔진이 실행하지 않는 환경을 설정함
• 파일 업로드 필드를 대상으로 특수문자 필터링하도록 웹 방화벽 룰셋 적용
• 첨부 파일 확장자 필터링 처리로 사용자가 첨부 파일의 업로드 시도 시, 업로드 파일의 확장자를 검토하여 적절한 파일인지 검사하는 루틴을 삽입하여, 적합한 파일의 확장자 이외의 파일에 대해서 업로드가 불가능하도록 하며, 이런 필터링 규칙은 서버에서 구현하여야 함
• 시스템 보안 설정 시 웹 서버 구동은 반드시 관리자 권한이 아닌 일반 사용자 권한으로 구동함
• 외부 사용자가 첨부 파일을 이용하여 권한을 획득할지라도 최소한의 권한만을 사용할 수 있도록 함
• 업로드된 디렉터리에서 실행 권한을 제거하는 방법은 임시적이기는 하지만 소스 코드의 수정 없이 간단히 수행될 수 있음

참고

23. 파일 다운로드(File Download), FD

점검내용

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

보안위협

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

보안설정방법

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

• 다운로드 시 사용되는 파라미터 값 대상으로 아래의 특수 문자를 필터링하도록 웹 방화벽 룰셋 적용

  문자	설명
  .	Path Traversal 가능성의 확인
  /	특정 Path의 접근 가능성을 확인
  \	운영환경에 따른 Path 접근 확인
  %	UTF 인코딩 파라미터

참고

24. 관리자 페이지 노출(Administrator Page Exposure), AE

점검내용

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

보안위협

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

보안설정방법

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

참고

25. 경로 추적(Path Trace), PT

점검내용

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

보안위협

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

보안설정방법

• 웹 사이트에서 접근하려는 파일이 있는 디렉터리에 chroot 환경 적용 시 경로 추적 공격을 최소화할 수 있음 chroot 디렉터리는 해당 디렉터리가 루트처럼 다뤄짐. chroot 파일 시스템은 대부분의 유닉스를 기반으로 한 플랫폼에서 지원 가능하며, 윈도우 플랫폼에서는 적절한 시작 디렉터리를 새로운 논리 드라이브로 만들어 웹 사이트에서 해당 드라이브를 통하여 접근하게 함
• 애플리케이션 소스 파일을 수정하여 파일 내용을 웹 브라우저에 표시할 수 있는 디렉터리를 특정 디렉터리로 한정하고 이 외의 다른 디렉터리에서는 파일 내용을 표시할 수 없도록 설정해야 함
• PHP를 사용하는 경우 php.ini에서 magic_quotes_gpc를 On으로 설정하여 .\./와 같은 역슬러시 문자 입력 시 치환되도록 설정
• 웹 사이트에서 사용되는 파라미터 값 대상으로 특수 문자를 필터링하도록 웹 방화벽 룰셋 적용

참고

26. 위치 공개(Public Location), PL

점검내용

예측 가능한 폴더의 위치 사용 여부 및 불필요한 파일의 존재 여부 점검

보안위협

폴더나 파일명의 위치가 예측 가능하여 쉽게 노출될 경우 공격자는 이를 악용하여 대상에 대한 정보를 획득하고 민감한 데이터에 접근 가능

보안설정방법

• robots.txt 파일 작성을 통해 검색 차단할 디렉터리, 확장자, 페이지 등을 지정할 수 있으며 HTML의 HEAD 태그 내에 META 태그를 추가하여 검색엔진의 인덱싱을 차단
• 웹 디렉터리를 조사하여 아래의 삭제해야 할 파일 확장자에 포함된 백업 파일을 모두 삭제하고, *.txt 확장자와 같이 작업 중 생성된 일반 텍스트 파일이나 이미지 파일 등도 제거함
• 삭제해야 할 파일 확장자 예시

  *.bak	*.backup	*.org	*.old	*.new	*.txt
  *.zip	*.log	*.!	*.sql	*.tmp	*.temp

• 백업 파일은 백업 계획을 수립하여 안전한 곳에 정기적으로 백업해야 하며 웹 서버에서는 운영에 필요한 최소한의 파일만을 생성해야 함
• 웹 서버 설정 후 디폴트 페이지와 디폴트 디렉터리 및 Banner를 삭제하여 Banner Grab에 의한 시스템 정보 유출을 차단함
• Apache, IIS, Tomcat 등 각 웹 서버 설정 시 함께 제공되는 샘플 디렉터리 및 매뉴얼 디렉터리, 샘플 애플리케이션을 삭제하여 보안 위험을 최소화함

참고

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

점검내용

서버와 클라이언트 간 통신 시 데이터의 암호화 여부 점검

보안위협

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

보안설정방법

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

참고

28. 쿠키 변조(), CC

점검내용

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

보안위협

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

보안설정방법

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

Set-Cookie: secure, HttpOnly
Set-Cookie: domain=app.mysite.com

참고