현재 위치: WiKi Security Spirit » 보안 하드닝 가이드 » JSP 보안 개발 가이드

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- guide:jsp_개발_보안_가이드 [2013/11/29 06:26] – 121.140.124.172
+++ guide:jsp_개발_보안_가이드 [2024/04/04 05:12] (현재) – 바깥 편집 127.0.0.1
@@ 줄 494: / 줄 494: @@
     * Tomcat, Jeus, IIS, Weblogic 등의 관리 콘솔 중 사용하지 않는 기능을 중지하거나 삭제
     * 기타 Third party 제품군의 관리 페이지, 샘플 페이지 등을 삭제
   * 디폴트 페이지 사용시 관리 강화
     * 디폴트 페이지나 관리 콘솔을 사용해야 하는 경우, 접근 경로 및 접근 port 의 디폴트 설정값을 변경하여 사용하도록 함
@@ 줄 499: / 줄 500: @@
     * 관리 콘솔 등 중요한 기능의 경우 적절한 ACL 정책을 적용함
     * Third party 제품군의 관리 페이지 등이 일반에 노출되지 않도록 주의함
+==== 11. 백업 파일 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+웹 디렉토리 내에 백업용 압축파일, 테스트 파일 등이 존재하고 유추 가능한 이름으로 되어 있는 경우, 별도의 과정 없이 다운로드가 가능하거나 내용이 브라우저 상으로 출력될 수 있으므로 이를 통해서 중요한 정보가 노출될 위협이 있음.
+=== 나. 보안 대책 ===
+아래의 내용을 확인하고 해당 사항이 발견될 경우, 적절한 조치를 취애햐 함.
+  * 관리자는 웹 디렉토리를 조사하여 *.asp.bak , *.jsp.bak, *.php.old와 같은 백업파일을 모두 삭제 해야 함.
+  * *.txt 같은 웹 페이지의 작업 도중 생성된 일반 텍스트 파일이나 그 밖에 이미지 파일 등도 본래 파일 이외에는 제거하여야 하며 *.asp.bak, *.jsp.bak 파일 이외의 *.bak 파일도 불필요한 경우는 삭제해야 함.
+  * 백업 파일 같은 경우 언제 생성될 지 관리자의 측면에서는 알기가 매우 힘드므로 cron등을 이용하여 주기적으로 검사 및 삭제할 것을 권고하며 가급적이면 웹 서버를 실행하는데 필요한 파일을 제외하고는 모두 삭제할 것을 권고함.
+==== 12. 에러 페이지 미비 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+공격자가 대상 시스템의 현황을 파악하기 위하여 다양한 에러를 유발시킴으로써 반응하는 에러 결과값으로 웹 프로그램의 구조 및 환경설정을 추측하여 공격에 이용되므로 이러한 Error를 위한 별도의 페이지를 작성하여 Error발생시 기본 Error Page로 Redirect 시킴으로써, 불필요한 정보가 노출되지 않도록 해야 함. SQL Injection 공격으로 대상시스템의 SQL Query문장의 구성을 알아내기 위한 Foot Printing 시도와 같은 것이 이 항목에 해당됨
+=== 나. 보안 대책 ===
+모든 에러(404 error,403 error,500 error, ...)발생 시 에러 메시지를 외부에 제공하지 않도록 함. 에러가 발생한 경우 에러 발생 메시지를 사용자 클라이언트의 브라우저에 표시하지 않게 하고 메인 페이지 또는 별도로 만든 에러 페이지로 Redirect 시키도록 함.
+  * Apache 에러페이지 설정
+<code | Apache 에러페이지 설정>
+# 사용자 정의 에러 반응 메시지 (아파치 스타일)
+# 다음 3 가지 방법으로 가능함.
+#
+# 1) 보통의 텍스트
+#ErrorDocument 500 "The server made a boo boo.
+# 주목: " 표시는 텍스트임을 알려주는 것으로서 그 자체는 출력되지 않음.
+#
+# 2) 지역적인 방향 전환
+#ErrorDocument 404 /missing.html
+# 지역적 URL인 /missing.html로 방향 전환하기
+#ErrorDocument 404 /cgi-bin/missing_handler.pl
+# 주목: 스크립트나 SSI로 방향 전환시킬 수 있음.
+#
+# 3) 외부 방향 전환
+#ErrorDocument 402 http://some.othercom.com/subscription.html
+# 주목: 원래 요청과 관련있는 환경 변수의 상당수가 스크립트에 전달되지 못함.
+내부 방향 전환에는 전혀 이상이 없으나 외부 방향 전환 시 가끔 에러가 발생 함.
+ErrorDocument 400 /message/400error.html
+ErrorDocument 401 /message/401error.html
+ErrorDocument 403 /message/403error.html
+ErrorDocument 404 /message/404error.html
+ErrorDocument 405 /message/405error.html
+ErrorDocument 500 /message/500error.html
+ErrorDocument 501 /message/501error.html
+또는 스크립트를 이용하여 변수를 전달시킬수도 있음.
+ErrorDocument 400 /message/error.php?ecode=400
+ErrorDocument 401 /message/error.php?ecode=401
+ErrorDocument 403 /message/error.php?ecode=403
+ErrorDocument 404 /message/error.php?ecode=404
+ErrorDocument 405 /message/error.php?ecode=405
+ErrorDocument 500 /message/error.php?ecode=500
+ErrorDocument 501 /message/error.php?ecode=501
+</code>
+  * IIS 에러페이지 설정\\ 인터넷 정보서비스(IIS) 관리 – [속성] – [사용자 지정 오류] 탭에서 아래와 같이 에러표시 페이지를 설정한다.
+{{:guide:iis에러페이지_설정.png?600|}}
+==== 13. 중요정보 전송구간 암호화 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+인터넷 구간을 통해서 계정 정보나 사용자 정보를 전송할 때 SSL이나 암호화가 적용되지 않은 상태로 전송된다면, 공격자는 인접 네트워크 대역이나 무선 LAN 환경에서 네트워크 트래픽을 모니터링 함으로서 전송되는 정보들을 수집하여 계정 정보나 개인 정보 등 중요 정보를 획득할 수 있다.
+\\
+만일 암호화나 SSL 이 적용되어 있는 경우에도 안전한 것으로 공인된 강력한 알고리듬이 사용되지 않았거나 SSL 환경 및 인증서 설정의 오류로 인해 취약점이 발생할 수 있다.
+\\
+또한 많은 웹사이트에서는 퍼포먼스의 문제로 인해서 민감한 정보를 다루는 일부 페이지에서만 SSL 및 암호화를 적용하는데, 민감한 데이터를 전송하면서도 SSL 및 암호화의 적용이 누락되는 페이지가 존재하는 경우가 많기 때문에 보다 철저한 점검이 요구된다.
+=== 나. 보안 대책 ===
+인터넷 전송 구간을 안전하게 방어하기 위한 가장 쉬운 대책은 웹사이트 전체에 SSL 또는 암호화를 적용하는 것이다. 그러나 퍼포먼스의 문제로 인해서 대부분의 경우 민감한 정보를 다루는 페이지에만 암호화 및 SSL을 적용하게 된다.
+\\
+웹사이트에서 암호화 및 SSL을 적용할 때는 최소한 다음의 원칙을 준수해야 한다.
+  * 민감한 데이터를 다루는 모든 페이지에 적용하고 누락되는 페이지가 없도록 확인
+  * GET/POST와 같은 Request 데이터 뿐만 아니라 Response 데이터의 HTML 코드에 포함된 <INPUT>변수 또는 javascript 변수 등도 민감 정보가 포함되어 있을 수 있다는 점에 유의하여 이에 대한 암호화가 누락되지 않도록 함
+  * SSL 적용시 인증서를 정확하게 설정하여 사용자의 웹브라우저에서 인증서 경고창이 출력되지 않도록 주의 함 (웹을 사용하기 위해 사용자가 인증서 경고창을 무시하고 진행하도록 강요하는 상황은 해당 사이트 유저의 Fishing 공격에 대한 대응을 약화시켜 Fishing 위협을 증가시키는 결과를 초래함)
+  * SSL 이 필요한 웹페이지에 대해서 일반 HTTP로 요청할 경우 반드시 SSL 페이지로 리다이렉트 시키도록 함
+  * 로그인시 계정 정보를 단순 인코딩 또는 해쉬값을 이용하는 경우 복호화 없이도 해당 정보를 로그인 인증을 통과하기 위한 인증 값으로 이용할 수 있으므로 대칭키/비대칭키를 이용한 적절한 암호화가 실시되어야 함
+==== 14. 사용자 정보 및 기타 중요 정보 노출 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+웹사이트를 통해서 발생하는 사용자 개인정보 및 중요 정보의 노출은 그 발생 원인이 매우 다양하다. 예를 들면 웹사이트 운영상의 단순한 실수로 정보가 노출되는 경우도 있고, 또는 웹사이트의 설정상의 오류나 보안 취약점에 대한 공격의 결과로서 정보가 노출되는 유형도 존재할 수 있다.
+\\
+웹사이트 운영상의 실수로 정보가 노출되는 대표적인 유형을 살펴보면, 관리되지 않고 방치되는 게시판 또는 삭제되지 않은 구 버전 웹사이트, 백업 파일 관리 미흡, 관리자의 실수로 업로드된 엑셀 파일 또는 게시물, 비공개 게시물이 설정 실수로 인해 전원에게 공개되는 경우 등을 들 수 있다.
+\\
+또한 웹사이트 설정 오류나 보안 취약점에 의해 발생하는 유형으로는 암호화가 미흡하거나 파일 업로드 취약점이나 파일 다운로드 취약점을 통해 서버측의 리소스가 직접 유출되는 경우, 디렉토리 인덱싱에 의해 파일 목록이 유출되는 경우, 파라미터 변조 취약점 등에 의해서 발생하는 경우, SQL Injection 등을 통해 DB 데이터가 직접 유출되는 경우도 존재할 수 있다.
+\\
+따라서 이를 해결하기 위해서는 운영 담당자의 상시 웹사이트 점검 노력과 보안 취약점의 제거 대책이 종합적으로 적용되어야 할 것이다.
+=== 나. 보안 대책 ===
+웹사이트 운영 담당자는 다음과 같은 내용을 상시 점검해야 한다.
+  * 공지사항에 올린 게시물에 개인정보가 포함되어 있지 않은가?
+  * 게시판에 업로드한 첨부 파일에 개인정보가 포함되어 있지 않은가?
+  * 웹사이트 리뉴얼 후 구버전 웹사이트가 계속 접속 가능한 상태로 방치되어 있지 않은가?
+  * 웹사이트에 관리되지 않는 불필요한 포트가 허용되어 있지 않은가? (예: 80 포트와 8080 포트를 동시 허용된 상태로 8080포트에 웹방화벽이나 SSL 적용이 이루어지지 않는 경우)
+  * 공개/비공게 게시판 또는 서비스에 대한 접근 Role 설정이 적절하게 관리되고 있는가?
+  * 웹 방화벽이나 SSL 적용이 누락된 페이지가 존재하지 않는가?
+또한 사회 공학적 유형의 정보 유출이 발생하지 않도록 다음과 같은 정책의 적용해야 한다.
+  * 주민등록번호, 비밀번호와 같은 민감한 정보 입력시 화면상에 ‘*’로 처리한다.
+  * 관리자 페이지 등을 통해 사이트 운영자가 회원들의 개인정보에 무단으로 접근하여 열람하지 못하도록 대책을 강구한다.
+  * 민감한 정보에 대한 접근은 로그를 기록하고 규정에 따라 보관하도록 한다.
+==== 15. 관리자 페이지 접근 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+관리자 기능이 일반 사용자 기능과 분리되어있지 않을 경우, 해당 기능의 경로가 노출되기 쉬우며, 노출된 경로를 통해서 일반 사용자의 접근 시도가 발생하거나 또는 악의적인 공격자에 의한 계속적인 공격을 유발할 수 있음.
+\\
+관리자 페이지는 적절한 접근 통제가 이루어져야 하며, 접근 통제 없이 임의의 위치에서 접근 가능할 경우, 해당 경로를 유추하거나 기타 다양한 방법에 의해서 위치가 노출될 수 있으므로 이를 통해서 악의적인 공격자에 의한 brute force 공격 등이 발생할 수 있음.
+=== 나. 보안 대책 ===
+관리자 페이지는 다음과 같은 보안 정책에 의해서 보호되어야함.
+  * 관리자 페이지는 일반 사용자용 인터페이스와 분리되어 작성되어야 함. (별도의 포트, 도메인 등)
+  * 관리자 페이지는 임의의 위치에서 접근할 수 없도록 적절한 접근 통제 절차가 적용되어야 함 (IP 접근 제어, SMS 인증 등)
+  * 추측하기 쉬운 디렉터리명이나 파일명을 사용해서는 안됨.
+<code | 추측가능한 관리자 페이지 예>
+http://www.abc.com/admin.html
+http://www.abc.com/admin_main.html
+http://www.abc.com/admin/index.html
+http://www.abc.com/admin/login.html
+http://www.abc.com/master.html
+http://www.abc.com/master/index.html
+</code>
+==== 16. WebDAV 취약점 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인 WebDAV가 계속 사용가능하도록 설정되어 있고, WebDAV 라이브러리 파일의 속성 및 홈페이지 디렉토리에 쓰기 권한이 모두 허용되어 있는 경우에 해커가 WebDAV 도구를 사용, 원격에서 홈페이지 디렉토리에 임의의 파일을 삽입하여 화면을 변조할 수 있다.
+=== 나. 보안 대책 ===
+만약 원격 웹 서버 관리를 하지 않는다면 반드시 웹데브 기능을 중지시켜야 한다. 웹데브는 앞서 설명한 취약점 외에도 버퍼오버플로 취약점 등이 존재하여 단지 웹데브 기능이 ‘사용가능’ 상태로 되어 있는 것만으로도 문제가 될 수 있다.
+== (1) IIS 를 사용하지 않을 경우 ==
+  *[시작]-[프로그램]-[관리 도구]-[컴퓨터 관리]-[서비스 및 응용 프로그램]-[서비스] > [World Wide Web Publishing Service] 속성 - [일반] > 서비스 중지 및 시작유형을 사용 안함으로 설정
+== (2) IIS 를 사용하는 경우 ==
+  * 레지스트리 편집기(Regedt32.exe)에서 다음 키를 찾아 값을 수정하거나 추가함
+<code>
+HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters
+값 이름: DisableWebDAV
+데이터 형식: DWORD
+값 데이터: 1
+</code>
+  * IIS 6.0 이상에서는 다음과 같이 인터넷정보서비스 관리에서 WebDAV 항목을 중지함
+{{:guide:iis관리.png?600|}}
+==== 17. 검색 엔진 중요정보 노출 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+Google 같은 검색엔진의 검색 결과는 해당 검색 엔진의 데이터베이스에 저장되거 유지되기 때문에 중요 정보가 검색 엔진의 검색 결과에 일단 노출이 되면 자신의 웹사이트에서 해당 정보를 삭제해도 검색엔진의 검색 결과에는 일정 기간 정보가 계속 남아있어 유출이 계속 발생하게 된다.
+\\
+따라서 중요한 정보는 반드시 인증을 거쳐아먄 접근할 수 있는 페이지에 게시하여 검색엔진에 의해서 임의로 정보가 유출되지 않도록 주의해야 하며, 노출된 것으로 확인된 정보는 해당 검색엔진에 직접 정보를 삭제해줄 것을 요구해야 한다.
+\\
+또한 주기적으로 웹사이트의 URL 및 중요정보의 keyword를 조합하여 검색엔진의 검색 결과를 점검해보고 노출되어서는 안되는 정보가 검색엔진에 노출되어 있는지 여부를 확인하도록 한다.
+\\
+노출되기 원하지 않는 정보에 대해서는 robots.txt 파일을 설정을 통해 검색을 거부하도록 한다.
+=== 나. 보안 대책 ===
+== (1) 검색엔진에 노출된 중요 정보의 삭제 ==
+검색 엔진에 중요 정보가 노출되어 있을 경우, 자신의 웹사이트에서 정보를 삭제해도 검색엔진에는 일정기간 동안 검색 결과가 유지되므로 해당 검색엔진에 내용의 삭제를 직접 요구하도록 한다.
+  * Google\\ 검색 결과 삭제를 위한 웹페이지 제공\\ https://www.google.com/webmasters/tools/removals?hl=ko
+  * Naver\\ 고객센터에 문의하여 삭제를 요청함\\ http://help.naver.com/ops/step2/mail.nhn?catg=362
+  * Daum\\ 아래의 고객 문의 양식에서 분류를 “사이트, 웹문서, 웹뉴스 문의” > “웹문서 삭제” 로 선택\\ http://cs.daum.net/mail/form/15.html
+== (2) 검색엔진에 의한 검색을 방지하기 위한 설정 ==
+== * robots.txt 설정 ==
+Google, Naver, Daum 등 대부분의 검색엔진은 robots.txt 파일에 의한 검색 거부 규약을 지키고 있으므로 규약에 맞게 robots.txt 파일을 작성하여 적용하면 검색엔진에 노출되는 것을 원치 않는 URL에 대해서 검색을 거부할 수 있다.
+\\
+robots.txt 작성 방법은 아래와 같다.
+<code | 모든 검색엔진이 자신의 웹사이트 검색을 금지함>
+User-agent: *
+Disallow: /
+</code>
+<code | 모든 검색엔진에게 자신의 특정 디렉토리에 대한 검색을 금지함>
+User-agent: *
+Disallow: /my_directory1/
+Disallow: /my_directory2/my_directory3
+</code>
+<code | 특정 검색엔진이 자신의 웹사이트를 검색하는 것을 금지함>
+User-agent: Googlebot
+Disallow: /
+</code>
+robots.txt 작성할 때는 다음 사향에 주의하도록 한다.
+  * robots.txt 파일은 웹 URL의 최상위 디렉토리에 위치해야 함
+  * robots.txt 에서 디렉토리 경로는 URL에서 도메인 주소를 뺀 나머지 디렉토리 트리 구조로 표현함
+  * robots.txt 파일은 텍스트 파일로서 누구나 URL을 통해서 열람이 가능한 파일이므로 관리자 페이지경로와 같은 민감한 경로는 포함해서는 안됨
+== * 메타 태그 설정 (특정 페이지에 대한 검색 거부) ==
+메타 태그를 이용하면 특정 페이지에 대한 정보 수집을 거부할 수 있다. 메타 태그를 사용하기 위해서는HTML의 <head> 태그 사이에 다음 구문을 삽입한다.
+<code>
+<meta name="robots" content="noindex, nofollow">
+</code>
+== Google 에서 검색결과 테스트 ==
+자신의 사이트의 주요 정보가 검색엔진에 노출되어있는지 테스트하기 위해서 다음과 같은 유형의 검색 keyword를 통해서 주기적으로 검색 결과를 점검하도록 한다.
+<code | Google 검색 키워드 예시>
+- inurl:www.myweb.co.kr filetype:doc
+- inurl:www.myweb.co.kr 고객명단
+- inurl:www.myweb.co.kr admin
+</code>
+==== 18. 특수 문자 취약점 ====
+=== 가. 취약점 상세 내용 및 보안 대책 ===
+웹서버 및 WAS는 제품과 버전에 따라 ‘Null’, ‘%00’, ‘%3f’, ‘#’, ‘::’ 등과 같은 특수 문자의 처리시 발생하는 버그로 인해 요청된 URL 의 소스 코드를 노출시키거나 디렉토리 목록 등을 출력하는 문제가 과거 여러 차례 보고된 바 있다.
+\\
+따라서 웹사이트 운영 담당자는 담당 웹사이트에서 사용하고 있는 제품의 Vendor에서 제공하는 패치 정보 및 보안 권고문을 항상 확인하도록 하고, 보안 이슈 사항에 대해서 자신의 서버가 영향이 있는지를 테스트하여 적절한 보안 대책을 적용하도록 한다.
+\\
+또한 자신이 운영하고 있는 웹사이트가 과거에 발생했던 특수 문자 처리 취약점의 영향을 받고 있는지를 테스트하여 만일 취약점을 갖고 있다면 이를 즉시 해결해야 한다.
+=== 나. 보안 대책 ===
+아래 사항을 점검 후, 취약한 것으로 확인된 경우는 자신의 Vendor 사의 보안 권고문을 확인하고 지시에따라 보안 패치를 설치하거나 웹서버 또는 WAS의 설정을 변경한다.
+== * Resin 2.x 이전 버전 / 기타 java 기반 웹 애플리케이션 서버 공통 ==
+아래와 같이 입력시 디렉토리 목록을 출력
+  * http://www.sample.com/sample/%3f.jsp
+== * JEUS  ==
+아래와 같이 입력시 요청 URL의 소스코드 또는 디렉토리 목록을 출력
+  * http://www.sample.com/sample/test.jsp#aaa
+  * http://www.sample.com/sample/#.jsp
+아래와 같이 입력시 URL의 소스코드를 출력
+  * http://www.sample.com/test.jsp::$DATA
+== * 플랫폼 공통 ==
+다음과 같은 특수문자가 삽입된 URL 을 테스트하여 웹서버의 반응을 확인한 후, 정상적인 400, 403, 404, 500 error가 아닌 특수한 반응(예: 소스코드 출력 또는 디렉토리 목록 출력)이 발생하는 경우, Vendor사의 보안 권고문에서 해당 내용을 검색하여 지시에 따라 대책을 적용해야 한다.
+<code | 테스트할 특수문자 목록>
+테스트할 특수문자 목록 : [.], [%2E], [+], [%2B], [%2A], [\], [%5C], [?], [%3F], [%20], [%00]
+</code>
+테스트할 URL 패턴은 다음의 두가지 케이스를 테스트한다. (예: %2E를 테스트 할 경우)
+  * http://www.sample.com/test/%2E
+  * http://www.sample.com/test/test.jsp%2E

추적: