웹 진단(모의해킹) 가이드 라인 OWASP10

 

개요	웹브라우저 주소창, ID 및 패스워드 입력화면 등에서 데이터베이스 SQL문에 이용되는 특수문자를 필터링하지 않아 데이터베이스에 인증절차 없이 접근하여 자료를 무단 유출하거나 변조할 수 있게 함
점검범위	웹사이트의 기본적인 “사용자 인증창 우회 SQL Injection 취약점 점검” 방법을 이용하여 취약점 존재 가능성을 점검
점검방법
1. 홈페이지 관리자 로그인 페이지로 이동합니다. 2. 관리자 아이디와 패스워드에 아래 문자열을 입력하여 결과를 확인합니다.   ① ‘or 1=1;- - ② ‘ ’ or 1=1- - ③ "or 1=1 -- ④ or 1=1-- ⑤ 'or 'a'='a ⑥ " or "a"="a ⑦ ')or('a'='a ⑧ sql' or 1=1- - ⑨ sql" or 1=1-- ⑩ + or 1=1- - ⑪ ';- -   3. 인증 실패 메시지가 나타날 경우, ‘SQL Injection 취약성’은 존재하지 않습니다. 4. 로그인 될 경우, SQL Injection 취약점이 존재합니다. 5. 홈페이지 오류 메시지가 나타날 경우, SQL Injection 가능성이 있으므로 세부적인 점검이 필요하다는 것을 의미합니다.
조치방법
1. ID, Password 란에 특수문자(따옴표, 공백 등)가 입력되지 않도록 소스코드를 수정합니다. 2. 웹 소스코드가 수정 된 후에 다시 한 번 취약점 점검 검증작업을 실시하여 취약점이 존재하지 않는지 확인합니다.

 

 

개요	게시판에서 글쓰기를 하는 경우, 입력 내용 중 실행코드인 스크립트의 태그에 대한 필터링을 하지 않아서 악의적인 스크립트 등록을 통해 일반 이용자 PC로부터 쿠키(cookie) 등 유출 가능
점검범위	홈페이지 게시판에 글쓰기 기능이 존재하는지 여부를 점검하고, 간단한 스크립트 문장을 입력하여 게시를 시도
점검방법
1. 게시판, 의견쓰기, 게시마당, 민원신청, 여론마당 등에 대해 일반 사용자들이 글을 게시할 수 있는 기능이 있는지 점검합니다. 글쓰기 기능이 전혀 없으면 ‘XSS 취약점’은 존재하지 않습니다. 2. 글쓰기 기능이 있는 게시판에 대해 본문에 다음과 같은 스크립트 문장을 입력하고 게시를 시도합니다.   <script>alert('XSS 취약점 존재‘);</script>   3. 글을 게시하는 중에 스크립트 태그 사용에 대한 ‘에러’나 ‘경고’ 메시지가 뜨면서 등록이 안 되거나 윈도우 경고창이 전혀 뜨지 않고 글 본문에 스크립트 문장이 입력한 대로 나오면 XSS 취약점이 존재하지 않는 것입니다. 4. 윈도우 경고창을 통해 ‘XSS 취약점 존재’ 나 “XSS&nbsp;취약점&nbsp;존재”와 같은 형태의 팝업창이 뜨면 ‘XSS 취약점’이 존재하는 것입니다.
조치방법
1. XSS 취약점은 웹 서버 설정으로는 조치할 수 없습니다. 글쓰기가 가능한 게시판 페이지에서 이용자들의 입력 중 스크립트에 대해 필터링을 해야 됩니다. 2. 스크립트 문장에 존재할 수 있는 <, >, (, ), #, & 등의 메타 문자를 다른 문자로 변환하거나 글 게재 시점에서 스크립트가 있는 경우에는 게재를 차단합니다. 3. 웹 소스코드 수정이 된 후에 다시 한 번 취약점 점검 때와 같은 시도를 통해 취약점이 존재하지 않는지 확인합니다.

 

개요	인증과 세션 관리와 연관된 어플리케이션 기능이 올바르게 구현되지 않아, 공격자로 하여금 다른 사용자로 가장하여 패스워드, 키, 세션, 토큰 체계를 위태롭게 하거나, 구현된 다른 결함들을 악용할 수 있도록 허용
점검범위	운영 중인 어플리케이션 인증 구간에서 안전하게 세션 및 인증이 이루어지는지 점검
점검방법
1. 로그인 기능에서 세션ID가 발행되는지 확인합니다. 2. 로그인 전에 URL 및 파라메터에 세션ID와 값을 삽입하여 세션으로 사용되는지 확인합니다.   예시 - URL Rewriting을 지원하고 URL 상에 세션 ID가 포함된 시스템이 있으면 세션이 URL에서 노출되면서 악의적으로 사용자가 이용자의 세션을 가로 챌 수 있음 Sample : http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
조치방법
1. 강력한 인증 및 세션 관리 통제의 단일 체계를 구축해야 합니다. 2. OWASP의 어플리케이션 보안 검증 표준(ASVS) 항목의 V2(인증)와 V3(세션관리)에 정의되어 있는 인증 및 세션 관리 요구사항을 모두 충족시켜야 합니다. ASVS : http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project 3. 개발자를 위한 간단한 인터페이스를 갖추어야 한다. 특히, ESAPI 인증자와 사용자 API를 좋은 예를 삼아 구축 시 참고하여야 합니다. ESAPI : http://www.owasp.org/index.php/ESAPI_Swingset 4. 세션 ID를 도용하는데 사용될 수 있는 XSS 취약점을 막아야 합니다.

 

 

개요	홈페이지 구성 시 파일, 디렉토리, 데이터베이스 값을 URL이나 폼 매개변수로 노출시킬 때 발생 가능성이 존재함. 참조(첨부파일 및 파일경로)에 대한 접근 권한 확인이 적절히 이뤄지지 않으면 이러한 참조를 조작함으로써 다른 객체에 인증 없이 접근할 수 있음
점검범위	모든 웹 어플리케이션 및 홈페이지를 점검
점검방법
1. 직접 참조를 수정하여 권한없는 객체(시스템 파일등)에 접근할 수 있는지 확인합니다. http://www.example.com/app?file=test.txt?arcno=10 => http://www.example.com/app?file=../phpinfo.php?arcno=10 2. 사용자가 특정 파일 이름이나 경로를 사용자가 입력하도록 되어 있는지 확인합니다. - “../../../../etc/passwd%00"같은 문자열을 입력(널바이트 인젝션)하여 공격받을 수 있음 3. 권한 없는 데이터베이스 키에 대한 참조가 가능한지 확인합니다. 예) cartID를 공격자가 임의로 수정할 수 있는 경우 int cartID = Integer.parseInt( request.getParameter( "cartID" ) ); String query = "SELECT * FROM table WHERE cartID=" + cartID;
조치방법
1. 사용자가 직접 객체 참조에 노출되는 것을 방지 합니다. - 인덱스, 간접 참조 또는 검증이 쉬운 다른 간접적인 방법을 사용 2. 직접 객체 참조를 사용해야 한다면, 사용 이전에 사용자가 권한을 부여 받았는지 확인합니다. 3. 웹 어플리케이션 참조에 대한 표준을 정립합니다. - 직접 객체 참조(DB 키 또는 파일명)가 사용자에게 노출되지 않도록 설정 - 모든 참조된 객체에 대한 권한 검증 - 매개변수 변조 공격 방지를 위해 인덱스 값이나 참조맵을 사용 http://www.example.com/app?file=test.txt => http://www.example.com/app?file=1 - 데이터베이스 구조에 대한 직접 참조를 노출해야 한다면 권한 부여된 레코드만 허용하도록 확인 예) 인증된 유저만이 해당 cartID에 대한 정보를 조회 가능 int cartID = Integer.parseInt( request.getParameter( "cartID" ) ); User user = (User)request.getSession().getAtrribute( "user" ); // 유저에 대해 세션 값 요청 String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" + user.getID();

 

개요	공격자가 “로그온 한 피해자의 브라우저”를 통하거나 “보안이 취약한 웹 어플리케이션”에 요청을 보내도록 하여 피해자 대신 선택된 작동을 수행함
점검범위	모든 웹 어플리케이션을 점검
점검방법
1. 취약한 작동에 대한 권한 확인이 없는지 확인합니다. 2. 요청 범위 내에 기본 로그인 정보가 주어지면 요청을 처리하는지 확인합니다. (예: http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin) 3. 자동으로 제출된 자격 인증만을 기반으로 요청에 대한 권한 판단을 수행하는지 확인합니다. - 자동으로 제출된 자격 인증의 예 • 통합된 인트라넷의 일부로서 제출된 커버로스 토큰 • 웹 어플리케이션에 로그인 시 제공되는 세션 쿠키 4. CSRF 테스트 프로그램 활용 (영문) : http://www.owasp.org/index.php/CSRFTester 5. 해당 웹페이지가 크로스사이트스크립트(OWASP A2) 공격에 취약한지 확인합니다.
조치방법
1. 웹 어플리케이션 내에 XSS 취약점이 없도록 확인합니다. 2. 모든 폼과 URL 내에 브라우저에 의해 자동으로 제출되지 않도록 특별히 설계되고 불규칙한 토큰을 삽입합니다. 예) <form action="/transfer.do" method="post"> <input type="hidden" name="8438927730" value="43847384383"> … </form> 제출된 토큰이 현재 사용자에게 적합한지 검증합니다. 3. 민감한 데이터나 값에 대한 처리 시 재인증 프로세스 구현합니다. - e-mail을 이용한 확인 페이지 요청이나 휴대폰 SMS 인증 프로세스 구현

 

개요	보안은 어플리케이션, 프레임워크, 어플리케이션 서버, 웹 서버, 데이터베이스 서버와 플랫폼에 대해 보안 구성이 정의되고 적용하기를 요구함. 대부분 보안이 기본적으로 탑재되기 않기 때문에 이 모든 설정은 정의, 구현, 유지되어야 하는데, 어플리케이션에서 사용되는 코드 라이브러리를 포함하여 모든 소프트웨어가 최신의 상태를 유지하는 것을 포함함
점검범위	운영 중인 모든 어플리케이션, 아키텍처 구조 등을 파악하고 적절한 보안 여부를 수행하고 있는지 점검
점검방법
1. 모든 소프트웨어를 최신 버전으로 유지하기 위한 프로세스를 수립하고 있는지 확인합니다. 2. 불필요한 서비스(포트, 페이지, 권한, 계정 등)가 제거되거나 설치되지 않았는지 확인합니다. 3. 수립된 프로세스가 운영체제, 웹, 어플리케이션 서버, 데이터베이스 등 모든 것들이 프로세스에 반영될 수 있는지 확인합니다. 4. 운영 중인 시스템의 계정 중 디폴드 계정 및 패스워드 설정 여부를 확인합니다. 5. 개발 프레임워크 내에 보안설정 및 구성된 라이브러리들이 적절한지 확인합니다. 6. 운영 중인 시스템의 에러가 확인 및 관리되는지 확인합니다.
조치방법
1. 적절한 시스템 구축 프로세스 수립이 필요하며 이는 개발,품질보증, 생산환경 모두에서 동일하게 구성되어 적용될 수 있어야 합니다. 2. 모든 새로운 소프트웨어 업데이트와 패치를 각각의 환경에서 시기적절하게 배포 및 최신 수준으로 유지하기 위한 프로세스가 정의되어야 합니다. 3. 향후 보안 문제를 확인 및 조치하기 위해 정기적으로 시스템에 대한 스캐닝 및 보안감사를 수행하여야 합니다.

 

개요	악의적인 공격자가 암호화되지 않은 데이터를 획득하여 명의 도용이나 신용카드 사기 등의 범죄를 저지를 수 있음
점검범위	민감한 데이터를 취급하는 모든 시스템을 포괄하여 점검
점검방법
1. 백업데이터와 같이 장기간 보관하고자 하는 민감한 데이터가 암호화 되어 있는지 확인합니다. 2. 허가된 사용자만이 복호화된 데이터에 접근할 수 있는지 확인합니다. 3. 강력한 표준 암호화 알고리즘이 적용 되어 있는지 확인합니다. 4. 강력한 키를 생성하고 있는지, 비인가 접근자로부터 보호되고 있는지 확인합니다. 5. 패스워드는 강력한 표준 알고리즘과 적절한 salt를 사용하여 해시되었는지 확인합니다. * salt : (패스워드 해시를 변환하는데 사용되는 무작위 문자열) 6. 모든 키와 패스워드는 비인가 접근으로부터 보호되었는지 확인합니다.
조치방법
[참조문헌] - 암호화에 대한 ASVS 요구사항_V7(영문) : http://www.owasp.org/index.php/ASVS - ESAPI Encryptor API (영문) : http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encryptor.html - OWASP 개발 가이드-암호화(영문) : http://www.owasp.org/index.php/Guide_to_Cryptography - OWASP 코드 검토 가이드-암호화(영문) : http://www.owasp.org/index.php/Codereview/Cryptography

 

 

개요	인가되지 않은 사용자의 허용되지 않은 URL 접근에 대한 통제 정책 및 기술 조치가 필요함
점검범위	모든 웹 애플리케이션에 대한 URL 접근통제 여부를 점검
점검방법
1. 웹페이지 접근을 위해 인증절차 필요 여부를 먼저 확인합니다. 2. /admin/adduer.php 나 /approveTransfer.do 등과 같이 숨겨진 URL 접근 시 인증받은 관리자나 허가받은 사용자만 접근할 수 있는지 확인합니다. 3. 웹 취약점 분석 도구 등을 통해서는 URL 접근 통제에 대한 검증이 어려움이 있기 때문에 소스 코드에서 확인 및 테스트를 병행하는 것이 필요합니다. 4. 모의 침투 테스트를 통해 적절한 보호가 적용되는지 확인합니다.
조치방법
1. 효율적이고 정확한 접근방법은 접근통제 메커니즘을 검증하기 위해 코드 검토와 보안 테스트를 병행합니다. 2. 각 페이지별 접근 통제 강제성을 확인하며 모든 URL이 사용자의 역할/권한 부여 여부를 확인하는지 점검해야 합니다. 3. 숨겨진 URL, API 등에 대한 무작위적 접근 허용 금지 및 권한 설정 확인하며 알려진 값이나 파일 타입 이외의 것은 접근을 금지해야 합니다.

 

개요	어플리케이션은 가끔 민감한 네트워크 트래픽의 인증, 암호화 그리고 비밀성과 무결성을 보호하는데 실패할 수 있음. 대체로 안전하지 않은 알고리즘을 사용하거나, 유효하지 않은 인증서를 사용하는 등 올바로 이용하지 않을 때 문제가 발생함
점검범위	운영 중인 모든 웹페이지에서 주민번호, 비밀번호 등 중요 개인정보를 전송할 때 암호화하는지와 암호화 한다면 안전한 알고리즘으로 하는지를 점검
점검방법
1. 운영하는 모든 웹페이지에서 주민번호, 비밀번호 등 중요 개인정보를 전송하는 구간 여부를 확인합니다. 2. SSL을 사용하여 중요 개인정보를 전송하는 구간에서 암호화 시 실제 암호화 여부를 패킷분석을 통해 확인합니다. 3. SSL 인증서가 유효한지 확인합니다. 4. 중요 개인정보를 전송하는 구간에서 SSL를 통해 암호화 전송하고 있다면 강력하고 안전한 알고리즘인지 확인합니다. 5. 웹페이지와 세션으로 생성되는 쿠키에 'secure' 플래그가 설정되어 있는지 확인하며 평문으로 전송되는지 여부를 확인합니다.
조치방법
1. 모든 웹페이지에서 중요 개인정보를(ID/PW, 주민번호 등) 전송하는 경우 SSL을 적용해야 합니다. 2. 중요 개인정보를 전송하는 페이지에 대한 non-SSL 요청시 SSL페이지로 연결되도록 조치해야 합니다. 3. 모든 민감한 쿠키는 ‘secure’ 플래그를 설정해야 합니다. 4. 강력한 알고리즘(FIPS 140-2 호환)을 지원하는 SSL를 사용합니다. 5. SSL 인증서가 유효한지, 모든 도메인에 적용되는지 확인해야 합니다.

 

개요	웹 어플리케이션은 간혹 사용자를 다른 페이지로 연결(리다이렉트, 포워드)등 목적 페이지를 결정하기 위해 신뢰되지 않은 데이터를 사용함. 적절한 확인이 없다면 공격자는 이용자를 피싱, 악성코드 사이트로 연결시키며 공격자는 권한 없는 페이지 접근을 위해 사용할 수 있음 - 리다이렉션(Redirect) : 클라이언트 해당 페이지로 재 요청이 발생 - 포워드(Forward) : 서버 단 자체에서 페이지 변경이 발생
점검범위	모든 웹페이지에 대해 승인되지 않은 파라미터로 리다이렉트 및 포워드가 발생하는지 점검
점검방법
1. 리다이렉트 및 포워드 사용에 대한 소스코드를 검토합니다. 2. 리다이렉트 및 포위드 시 목적 URL에 포함되는 파라미터 값을 확인합니다. 3. 확인한 파라미터 값 이외에 다른 값들이 포함되지 않도록 조치합니다. 4. 리다이렉트 및 포워드 시 HTTP 응답코드(300~307)를 확인합니다. 5. 리다이렉트 및 포워드 발생을 일으키는 파라미터를 제거 및 방지시킵니다.   예시 - URL에서 특정 파라미터를 가진 “redirect.jsp“라는 페이지가 존재 - 점검자는 다른 사이트로 사용자를 리다이렉트 시키는 테스트 URL를 생성하여 연결되는지 확인 Sample : http://www.example.com/redirect.jsp?url=evil.com
조치방법
1. 단순히 리다이렉트와 포워드의 사용하지 않거나 피해야 합니다. 2. 목적지를 계산하는 사용자 파라미터를 포함시키지 말아야 합니다. 3. 목적 파라미터를 피할 수 없다면, 제공된 값이 유효한지, 그 사용자에게 허용된 것인지를 확인하여 조치하여야 합니다.

참조 : 공공기관 홈페이지 개인정보 노출방지 가이드라인(2011년)