[실전 security ⑦] Application Security

실전! 개발자를 위한 Security 체크 포인트
⑦ Application Security

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

이번 장에서는 전체 웹 서비스 시스템에 걸쳐서 고려해야 할 엔지니어링 적인 보안 요소에 대해서 알아볼 예정입니다. 코드상의 보안 이슈보다 시스템 구성/설정과 관련된 이슈를 다루겠습니다.
사실은 개발자에게는 이런 요소가 더 어려운 부분인 것 같습니다. 공개된 자료도 없고 특히나 경험적인 부분이 많이 필요한 필드이기 때문입니다.
많은 내용을 다루지는 못하겠지만 기본적인 내용 파악을 주 목적으로 알아보도록 하겠습니다.

1. 안전한 시스템 구성

1) Dual Firewall
웹서버의 앞과 뒤에 모두 f/w을 설치하는 구성입니다. 1차 방화벽은 DMZ 안에 위치한 웹서버를 보호하는 것이 주 목적이지만 이것이 100% 안전하다고 할 수 없습니다. 따라서, 1차 방화벽이 뚫렸을 경우에 DB 서버를 안전하게 보호하기 위해 (물론 App 서버도) 2차 방화벽을 사용합니다.
* 최근에는 reverse telnet 같은 outbound 패킷을 이용한 공격 방법이 이용되고 있기 때문에 방화벽 정책 구성 시 inbound와 outbound 모두 고려하여 정책을 수립하여야 합니다.

2) NAT
웹 서버 이후의 모든 장치는 NAT를 이용하여 사설 IP를 이용하는 것이 좋습니다. NAT를 이용해서 외부에 내부의 네트워크 구성을 감출 수 있기 때문입니다.

상황에 따라 시스템의 구성은 유동적일 수 있습니다. 하지만, 위에서 설명한 보안 요소들은 매우 기본적인 내용이기 때문에 그 내용을 이해하고 필요한 경우에 적용할 수 있어야 하겠습니다.

2. 웹 서버 보안 요소

웹서버는 다음과 같은 기본 적인 취약점을 가지고 있습니다. (WAS 서버 또한 이와 매우 유사한 문제점을 가지고 있습니다. 이론적인 내용이 같기 때문에 설명은 생략합니다.)
- 디폴트 ID / Password
- 소스 노출 취약점
- 디렉토리 리스팅 취약점
- 기본 인증 취약점
- 웹 서버 자체 취약점

이번 절에서 각각을 자세히 알아보도록 하겠습니다.

1) 디폴트 ID / Password 취약점
웹 서버 설치시 디폴트로 생성되므로 반드시 Password를 변경 해야 됩니다.
웹 서버 제품별로 웹서버 관리화면(포트) 디폴트 패스워드가 존재합니다. 디폴트 패스워드를 방치했을 경우 웹서비스가 다운되거나, 중요 시스템정보가 노출되어 해킹에 이용될 수 있습니다.
특히, 인터넷에 오픈된 사이트의 경우 관리포트는 내려서 운영하시거나 방화벽에서 소스 IP를 고정하여 관리자만 접근 할 수 있도록 하는게 바람직합니다.

2) 소스 노출 취약점
웹 브라우저에 프로그램 소스가 노출되는 현상으로 웹서버를 패치, 환경설정을 변경하거나 불필요한 샘플파일(JRun의 viewsource.jsp)을 삭제 해야 됩니다.
예전에는 웹서버 IIS에서 ASP소스 노출이 되었으나, 최근에는 웹어플리케이션 서버 (weblogic, Tomcat 등)에서 임의의 URL 입력으로 소스가 노출되는 취약점들이 많이 보고 되고 있습니다.

3) 디렉토리 리스팅 취약점
웹 서버의 디렉토리 구조가 보이는 현상으로 웹서버의 설정값을 변경 하거나 디렉토리 리스팅 취약점이 존재하는 경우 패치를 하여야 합니다.
간혹 일부 웹서버(Iplanet-舊 Netscape, Apache 등) 웹 서비스 신규 생성시 디폴트가 디렉토리 리스팅 허용(Fancy)로 되어 있어 웹서버 설치시 주의하셔야 합니다.

4) 기본 인증 취약점
기본 인증은 웹서버에서 기본적으로 제공하는 인증 방법입니다.
HTTP를 이용해서 웹 서버의 특정 디렉토리와 그 이하의 모든 디렉토리에 접근 제어를 할 수 있습니다.   그러나 ID/패스워드 전송시 MIME type에 사용되는 BASE64 인코딩 기법을 사용하기 때문에 취약점이 존재합니다. BASE64알고리즘은 암호 알고리즘이 아니라, 단순 Encode/Decode 알고리즘이기 때문에 쉽게 디코딩, 노출이 가능합니다.

이번엔 기본 인증관련 취약점과 관련하여, 인코딩된 패킷을 스니퍼 프로그램을 이용하여 가로챈 경우를 살펴볼까요?
인코딩된 패킷을 가로채 보면, 아래와 같이 인코딩된 부분이 보입니다. 
Authorization: Basic dGVzdDp0ZXN0MDA=  
dGVzdDp0ZXN0MDA= 부분을 인터넷에 돌아다니는 base64 디코딩 툴로 디코드해보면 test:test00가 추출이 됩니다. 이는 곧 <웹 관리자 id:패스워드>라는 뜻이지요.
또한 무작위 공격(brute force attack) 또는 사전 공격(dictionary attck)을 통해 기본인증이 적용된 웹페이지의 ID와 Password가 노출될 수도 있습니다.

자, 그럼 어떻게 해야 할까요?
해결방법은 기본인증을 사용하지 않고, Digest방식을 사용하는 것입니다. Digest방식은 md5와 같은 암호 알고리즘을 사용하여 id/패스워드가 전송되기 때문에 쉽게 노출되지 않고, 안전하게 사용할 수 있습니다. (제품별로 Digest방식을 지원 못하는 제품도 있음)

참고 1 : 다양한 웹 인증 방법

 

 

 

인증 방식	특 징	보안 수준	비 고
① 기 본	평문형태 혹은 Base64 인코딩 방법으로 전송합니다.	낮음
② 다이제스트	MD5와 같은 일방향 알고리즘을 사용하여 복호화가 불가능합니다.	보통	HTTP1.1 지원 브라우저 필요
③ 통합 윈도우(NTLM)	마이크로소프트의 독점 인증 프로토콜로 OS의 사용자ID와 연동됩니다. HTTP 요청/응답 헤더 안에서 구현됩니다.	높음	인트라넷 적합
④ 인증서	클라이언트측 인증서를 이용하여 인증을 수행합니다. SSL/TLS사용시 Enable하여 사용할 수 있습니다.	보통	인증서 배포 필요
⑤ 폼-기반	사용자 정의 폼이 입력에 사용되고, 백엔드에서 사용자 정의 로직을 사용하여 처리됩니다. 일반적으로 로그온 상태를 유지하기 위하여 쿠키를 사용합니다.	높음	SSL 적용 필요

다양한 인증방법 중 ④인증서 방식 외 모든 인증 방식들은 패스워드 추측(Password Guessing)에 취약합니다. 최근에는 웹 인증을 파괴하는 자동화된 툴(Webcracker, Brutus)들이 많이 나와 있어 주의해야 합니다.
가장 좋은 방법은 강력한 패스워드 규칙 사용과 패스워드 오류시 잠금기능 (Lock)을 적용하는 것입니다.

5) 웹 서버 자체 취약점
제품 자체가 근본적으로 가지는 취약점을 말합니다. IIS의 유니코드 취약점이 그 대표적인 예입니다.
주기적으로 문제점을 파악하여 반드시 패치하거나 최신 버전으로 업그레이드를 하여야 합니다.
-  제품별 취약점 조회 사이트

http://www.securityfocus.com http://www.securitymap.net

3. DB 서버 보안 요소

응용시스템의 소스노출 취약점을 이용해 DB서버의 정보(ID,Password 등)를 획득하고 공격하는 경우가 많이 있습니다. 이럴 경우 DB connection부분에 사용되는 Password를 암호화 해서 사용하면 좀 더 안전한 웹사이트를 구축할 수 있습니다.

DbCon(userid, password, serverip, datasource, databasenm)

                                             ▼

<%
tmptext = dbcon
("ACYRDhDxLx","ACHnACNHLxho2VZH","LjLjGa0M37WHZHycnOnO7sNH0", "OlDxrbrbb7S7vjLs","")
set db = server.createobject("adodb.connection") db.open tmptext
%>