[실전 security ②] 웹 서버 보안 기초

실전! 개발자를 위한 Security 체크 포인트
② 웹 서버 보안 기초 - HTTP, Cookie, Session

작성자 : 김문규
최초 작성일 : 2008. 8. 4
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

1. HTTP
웹 서버 프로그래밍을 할 때 HTTP 프로토콜에 대한 이해는 필수입니다. 구글링, 네이버링을 통해서 기본적인 사항을 꼭 파악하시길 바랍니다.
다음은 www 관련 스펙을 정리하는 W3C 주소 입니다. 참고하세요.
http://www.w3.org/Protocols/

2. Cookie
1) 쿠키란?
사용자 정보를 유지하기 위해 웹 브라우저에 의해 사용자의 PC에 저장되는 정보 (파일 혹은 메모리)
서버에서 클라이언트로 전송되는 것
<name : value> 쌍 입니다.

2) 동작 순서

1	Request	Client가 Server측에 문서요청을 합니다.
2	Call	Server는 Cookie를 검사하기 위해 CGI를 호출합니다.
3	Set	Cookie가 없는 경우에 CGI는 Set-Cookie header를 포함한 출력을 Server에 return 합니다.
4	SetCookie	Set-Cookie header에 부가 header를 덧붙여 Body와 함께 Client에 전송합니다.
5	Save	Set-Cookie header를 받을 Client는 Cookie 정보(Name = Value, Expires Date, Path, Domain)를 Cookie.txt라는 파일에 저장합니다.
6	Read, SendCookie	Cookies.txt에 등록된 동일한 Domain의 동일한 Path를 사용자가 요청하는 경우 Client는 Cookie 정보를 header를 이용해 Server로 전송합니다.
7	Call	Server는 Client로부터 받은 Cookie 정보를 환경변수 (HTTP_COOKIE)에 저장하고 CGI를 호출합니다.
8	HTTP_COOKIE	CGI는 HTTP_COOKIE로부터 Cookie 정보를 복원해서 Server로 전송합니다.

3) 보안상의 위험성
쿠키는 암호화 하지 않은 평문으로 주고 받을 경우에는 네트워크를 통해 쉽게 노출되고 또한 쉽게 변조될 가능성이 높습니다.

이런 쿠키를 획득하거나 변조하는 해킹 기술을 아래와 같습니다.
- 쿠키 스니핑 (Cookie Sniffing)
해커가 개인 PC에서 사용자의 정보를 담고 있는 Cookie를 네트워크 스니퍼를 통해 획득하는 기술
- 쿠키 스푸핑 (Cookie Spoofing)
타인의 시스템 자원에 접근할 목적으로 쿠키정보를 변조하여, 정당한 사용자인 것처럼 보이게 하거나 승인받은 사용자인 체하여 시스템에 접근함으로써 추적을 피하는 고급 해킹 기법

4) 쿠키인증 기법을 사용하는 사이트의 보안대책
 - 임의로 쿠키값을 조작하지 못하도록 쿠키 값을 암호화하여 전달합니다.
 - 쿠키 저장시 서버측에서 유효성 여부를 확인할 수 있는 대책을 강구합니다.
2.변수값에 쿠키변조 여부를 확인하는 체크섬을 추가하여 운영합니다.
   (MD5, SHA1과 같은 해쉬 알고리즘 활용)
 - 쿠키 저장 시 타인이 임의로 쿠키를 읽어 들일 수 없도록 도메인과 경로 지정에 유의합니다.
 - 수신된 웹메일의 본문에 포함된 스크립트 언어소스를 필터링하거나 무력화합니다.
2. 스크립트를 무력화하면 Cross-Site Scripting을 이용한 쿠키 훔쳐가기를 방지할 수 있습니다.

5) 일반 사용자들의 보안대책
 - 웹메일 서비스 옵션에서 '자바스크립트 허용여부'를 허용하지 않는 것으로 설정합니다. 
 - 로그인한 상태로 타인의 홈페이지를 방문하지 않습니다.
 - 브라우저의 인터넷 옵션에서 쿠키를 허용하지 않을 수 있으나, 대부분의 웹사이트가 쿠키를 사용하기 때문에 차단시 사이트에 로그인이 안될 수 있습니다.

3. Session
1) Cookie vs. Session

	Cookie	Session
정의	사용자마다 관리해야 하는 데이터를 각 사용자의 웹 browser가 있는 Client 컴퓨터에 기록하는 것	웹서버와 특정 사용자의 연결이 끊어 지더라도 그 사용자에 대해서 계속 관리해야 하는 데이터를 웹 서버에 기록해 둔 것
저장 방식	Client 측 메모리 혹은 파일로 저장	Session ID만 Cookie 형태로 Client에 저장 되고 실제 정보는 서버 메모리, DB 형태로 저장 (IIS 웹서버와 여러 웹어플리케이션 서버에서 많이 사용)

2) Session의 안전성
이는 곧 Session ID의 안전성과 직결된다고 할 수 있습니다. Sessino의 안전성은 Session ID가 얼마나 추측 가능한 지에 의존한다고 할 수 있습니다.

3) Session의 보안상의 위험성
대표적인 세션을 이용한 해킹으로 Session Hijack이 있습니다. 이는 다른 사람이 사용하고 있는 입, 출력을 내가 사용하는 일을 말합니다. 나의 Session ID가 노출되어서 누군가가 나의 행세를 하게 되는 것이지요.

Session Hijack의 기법으로는 아래의 방법들이 있습니다.
- ID 예측 : Session ID가 특정한 패턴이 발견되어 해커가 이를 예측하고 해당 Session ID를 사용하는 해킹
- brute forcing : 해당 해킹 툴을 사용하여 가능성이 높은 패스워드 부터 차례로 입력하는 해킹

4) 사이트 보안 대책
이들을 대처하기 위해서는 아래의 내용대로 Session ID를 설계해야 합니다.

방법	보호타입
강한 Session ID	큰 랜덤 풀로부터 Session ID를 생성하십시오. - 1과 100,000 사이의 값을 선택하는 강한 가짜 난수 생성기는 여전히 안전하지 - 않으므로, 32비트 이상의 값을 이용하여야 합니다. - Session ID가 예측할 수 없다는 것을 확신하기 위하여 Session ID 생성기를 - 테스트하십시오.
강한 해시 또는 암호화 된 컨텐츠	타임스탬프 또는 가짜 난수와 같은 동적 데이터를 스트링의 처음에 위치 시키십시오. - 이것은 brute forcing를 보다 어렵고 불가능하게 만듭니다.
Session 시간 제한 강제	특정 기간의 비활동 또는 정해진 시간 이후에 상태 정보와 Session ID를 무효화하십시오. - 서버는 ID 또는 토큰 정보를 무효화해야 합니다. - 이것은 Session 재사용 공격으로부터 어플리케이션을 보호하는 것입니다.
동시 로그인 제한 강제	사용자가 어플리케이션에 복수의 현재 인증된 Session을 못 가지게 하십시오. - 이것의 악의적인 사용자가 타당한 Session ID를 Hijacking 또는 추측하지 - 못하게 합니다.
상태 정보의 컨텐츠 타당성 입증	어플리케이션이 User ID를 세팅한 시간과 같은 상태 정보는 Client에게 보내 집니다. 따라서 이것은 조작될 수 있고 입력 값 타당화 또는 SQL 인젝션 공격을 위한 벡터로서 이용될 수 있습니다. 항상 들어오는 데이터를 체크하십시오.
체크섬 또는 메시지 인증 기술 이용	상태 정보가 변조되지 않았음을 증명하기 위해 체크섬을 이용하십시오. - 복잡한 알고리즘일 필요는 없지만 체크섬은 사용자에 의해 다시 만들어 - 져서는 안됩니다. 예를 들어, 사용자 명에 대한 체크섬을 생성하기 위하여, - 서버에 알려진 비밀 값에 더하여 사용자의 MD5 해시의 마지막 4바이트를 - 취할 수 있습니다.
SSL 이용	민감한 정보를 포함하는 트래픽은 스니핑 공격을 막기 하여 암호화되어야 합니다. (보다 자세한 내용은 뒤의 SSL 부분에서 다루도록 하겠습니다.)

4. 맺음말
웹에서의 보안을 말하기에 앞서서 준비 운동 격인 예습이었습니다. 다음 포스트에서는 Cookie와 Session의 취약점을 보완하는 안전한 개발 포인트를 좀 더 구체적으로 공부할 예정입니다. 아~ 재밌어요.