'2008/04'에 해당되는 글 3건

  1. 2008/04/26 개발자가 꼭 알아야할 보안가이드 라인
  2. 2008/04/26 [SSO] - DB를 이용한 도메인간 세션공유 처리
  3. 2008/04/26 AB 사용법 - Apache Benchmarking
2008/04/26 01:29

개발자가 꼭 알아야할 보안가이드 라인

웹에 대한 전반적인 보안 가이드 라인을 작성했습니다.

Guide 1. 세션유지를 위해서 Cookie를 사용할 경우, 위/변조에 대비해야한다.
 
■ 보안수단 없이 쿠키에 인증 정보를 저장해서 사용할 경우 해당 값들의 위/변조가 가능하며 이로 인하여 다른 사용자로
   위장 또는 권한 상승 등의 문제가 생길 수 있다. 따라서 쿠키를 사용할 경우, 쿠키 값의 불법 위/변조가 불가능하도록
   구현해야 한다.
■ 점검 방법: 사이트에 로그인 한 후, 웹 브라우저 주소창에 javascript:document.cookie; 입력해서 내용을 확인한후,
              해당 세션 쿠키를 사용하는 웹 어플리케이션 소스 점검을 통해 불법 변조 탐지 루틴이 있는지 확인한다.
■ 조치방법 : 1) 쿠키값 암호화를 통한 쿠키 불법 변조 방지( 서버에서  전송 받은 쿠키를 복호화한 후, 위/변조 여부 확인)
              2) 쿠키값에대한 Message Digest(예,MD5, SHA-1 등)값의 첨부 빛 검증을 통한 위/변조 탐지
              3) 쿠키에 세션 값을 저장하는 대신 어플리케이션 서버 세션 사용(사용하는 웹 어플리케이션 서버가 지원확인필요)
 
ASP 예제
secret_word = duronex_secret_value
// 쿠키설정
Id = duronex
Id_hash = md5(secret_word & id)
Response.Cookie(“id”) = id
Response.Cookie(“id_hash”) = id_hash
// 받은 쿠키가 변조되었는지 확인하기
Cookie_id = Request.Cookie(id)
Cookie_hash = Request.Cookie(id_hash)
If (md5( secret_word & cookie_id) = cookie_hash) Then
    // 변조 되지 않았으므로 계속진행
Else
    // 변조 경우라서 오류 처리
End If
 
JSP 예제
 
secret_word = “duronex_secret_value
// 쿠키설정
String Id = duronex
String id_hash = cryptoUtil.md5(secret_word & id)
Cookie[] cookies = new Cookie(“id”, id + “-” + id_hash );
Response.addCookie(userCookie);
// 받은 쿠키가 변조되었는지 확인하기
Cookie[] cookies = request.getCookies();
for(int i=0; i<cookies.length; i++){
    Cookie thisCookie = cookies[i];
    if( thisCookie.getName().equals(“id”)){
        String cookie_value = thisCookie.getValues();
        StringTokenizer st = new StringTokenzier(cookie_value, “-”);
        String cookie_id = st.nextToken();
        if( !cryptoUtil.md5( secret_word + cookie_id).equals(cookie_hash)){
            // 변죄된 경우라서 에러처리
        }
    }
}
Guide 2. 접근 제어가 필요한 모든 페이지에 로그인 체크 및 권한 체크를 구현하자.
 
■ 접근 제어가 필요한 페이지 및 모듈들에는 모두 통제 수단(로그인 체크.권한체크)이 적용되어야 한다.
   특히, 하나의 프로세스가 여러 개의 페이지 또는 모듈로 이뤄져 있을 때 권한 체크가 누락되었을 경우, 설정된 접근을 우회해서
   트랜젝션을 실행할 수 있는 위험이 존재한다.
■ 점검 방법 : 소스리뷰
■ 조치방법 : 1) 접근 권한이 필요한 모든 페이지/모듈에 해당 루틴 구현
              2) 이를 위해서 공통 모듈을 사용하는것을 권장한다.
 
Guide 3. 게시판 첨부파일 업로드 기능을 통한 스크립트 업로드 및 실행을 금지하자.
 
■ 게시판 첨부파일 업로드, 사진 업로드 모듈 등 사용자가 임의의 파일을 서버로 전송할 수 있는 기능을 이용해 공격자가 작성한
   악의적인 스크립트를 서버에 업로드한 후, 이를 실행시킬 수 있다면 해당 서버에서 임의의 명령어 실행, Web DB 불법 접근및
   해당 Application Server와 신뢰관계를 맺고 있는 서버들(예, Web DB서버, 내부 연동 서버 등)을 공격 할 수 있는 위험이 있다.
   본 취약점은 게시판 업로드 모듈 뿐 아니라 그림 파일을 올리는 기능을 통해서도 발견되고 있기 때문에,
   사용자가 파일을 업로드할수 있는 모든 모듈에 적용된다.
■ 점검 방법 : 해당 Application Server 가 지원하는 Script 파일을 업로드한 후,
               이를 웹브라우저로 직접 접근해서 실행이 되는지 확인.
■ 조치방법 : 1) 해당 Application Server에서 Script로 실행될 수 있는 확장자(예, .jsp, .asp, .php, .inc 등)로 된
                 업로드를 차단한다.
                 가급적이면 업로드 되는 확장자를 막는것 보다 지정 할것을 권장한다.
              2) 첨부파일을 웹 디렉터리가 아닌 곳에 저장한 후,
                 다운로드 스크립트를 사용해서 사용자에게 전달할 수 있게 한다.
              3) 다운로드 스크립트를 구성할 때, 파일명을 Parameter로 받는 것보다 파일이름은 DB에 저장하고 해당 index만을
                 Parameter로 받아서 사용하면 더 안전하다. (폴도 경로 노출 안함)
 
* 주의사항
1)확장자를 비교할 경우, 대소문자를 무시한 문자열 비교를 해야만 한다. 이를 적용하지 않으면 공격자는
Test.Jsp,test.jsp 등과 같은 파일명을 사용해서 통제 루틴을 우회할 수 있기 때문이다.
2)웹 어플리케이션 서버에서 실행 스크립트로 설정한 모든 확장자에 대해서 점검해야 하며, 이들 확장자 목록은 웹 서버 관리자에게 문의 해서 확인해야 한다.
 
 
Guide 4. 첨부파일 다운로드 스크립트를 악용한 서버 파일 유출을 방지하자.
 
■첨부파일 다운로드 스크립트에 파일 경로를 포함한 parameter를 사용할 경우, 원하는 디렉토리를 벋어나서
  임의의 파일을 다운로드 할 수 있는 취약점이 있다.
  이로 인하여 공격자는 서버의 중요 파일 또는 웹 어플리케이션 소스 파일 등에 접근이 가능하다.
■ 점검 방법 : http://localhost/download.jsp?file=test.txt 와 같이 구현되어 있다고 가정하자.
1) Application Server 가 Unix/Linux인 경우
               http://localhost/download.jsp?file=../../../../../../../etc/passwd입력했을 경우
               Application Server의 /etc/passwd 파일을 획득할 수 없어야 한다.
2) Application Server가 Windows 계열인 경우
             파일을 획득할 수 없어야 한다.
 
■ 조치방법 : 사용자로 부터 전송 받은 디렉토리이름, 파일이름값에 “../” 또는 “..\”이 존재하면 오류 처리한다.
 
 
Guide 5. SQL Injection 공격에 대비하자.
 
■ 사용자로부터 입력 받은 값을 DB query에 사용할 경우, 공격자는 원하는 query문을 injection할 수 있는 취약점이 있다.
   로그인 모듈이 SQL Injection에 취약할 경우, 사용자의 비밀번호를 몰라도 정상적으로 로그인할 수 있는 위험이 있으며,
   게시판 등의 모듈이 취약할 경우 DB 내용이 외부로 유출 또는 임의의 DB Query가 실행될 수 있다.
 
■ 원리
ID, PASSWORD를 받아서 로그인 성공 여부를 처리하는 예를 들어보자.
Id = request(“id”);
Passwd = request(“passwd”);
query = “select * from test where id = ‘” + id + “’ and passwd = ‘” + passwd + “’”;
로 되어 있어서 결과 Record가 있을 경우 회원 로그인 성공 처리하는 경우, ID에 “’ or 1=1--”입력할 경우 비밀번호 관계없이
조건이 or 이기때문에 어떤 경우라도 만족하기 때문에 결과는 항상 첫번째 레코드가 반환되어 로그인이 성공적으로 처리되게 된다.
이와같은 원리를 이용해서 DB 를 조작할수 있는 위험이 존재한다.
DB계정을 select , insert, update , delete 권한만 가진 계정을 만들어 사전에 방지하자.
 
■ 점검방법
 1) 검색어 필드 및 로그인 ID, PASSWD 필드에 큰 따옴표(“), 작은따옴표(‘). 세미콜론(;) 등을 입력한 후,
    DB error가 일어나는지 확인
 2) 로그인 모듈 점검
    MS SQL 인 경우 : ID 필드에 [‘ or 1=1 -- ], 비밀번호는 아무 값이나 입력한후 로그인을 시도한다.
■ 조치방법
 1) 사용자로부터 입력 받은 값에 큰따옴표(“), 작은따옴표(‘), 세미콜론(;) 문자가 있으면 이를 제거 또는 사용하는
    DB에 맞게 변환 한 후, DB query문장에 사용하도록 한다.
 2) PreparedStatement 방식으로 Query 를 실행하자.
 
Guide 6. Cross-Site Scripting 공격에 대비하자.
 
■ 사용자가 입력한 내용을 기반으로 페이지를 동적으로 생성하는 웹 어플리케이션을 악용하면, 해당 페이지를 보는 사용자의
   웹 브라우저에서 임의의 코드를 실행할수 있다. 이는 로그인 세션 hijacking, 악성 프로그램 설치 등의
   client hacking이 가능하다.
  
■ 점검방법 : 게시판의 제목, 내용 필드 등에 <script>alert(“test”);</script>를 입력한 후, 내용을 조회했을 때,
              해당 스크립트가 실행되면 취약하다.
■ 조치방법 : 사용자로부터 입력 받은 내용을 기반으로 페이지를 생성할 경우 “<“,”>”는 각 각 “&lt;”,”&gt;”로
              변경한 후 생성한다.
*비고
에디터를 사용할경우 HTML 직접입력 막아야 하며, 사용하더라도 관리자만 이용해야한다.
 
Guide 7. 사용자에게 전달된 값(hidden form 필드, parameter)를 재사용할 경우 신뢰해서는 안된다.
 
■ 주로 회원 정보 변경 모듈에 사용자의 key값(예,id)를 hidden form 필드를 전송한후, 이를 다시 받아서 update에
   사용하는 경우가있는데 공격자가 이 값을 변경할 경우 다른 사용자의 정보를 변경할 수 있는 취약점이 존재한다.
  
■ 점검방법 : 소스에서 FORM 필드 확인 후, 해당 값이 어떻게 사용되는지를 소스에서 확인해야한다.
■ 조치방법 : 해당 값의 무결성을 검사할 수 있는 루틴(예, 해쉬값 비교)추가 또는 서버 세션을 사용한다.
 
Guide 8. 최종 통제 메커니즘은 반드시 서버에서 수행되어야 한다.
 
■ javaScript 등을 사용한 사용자 입력 값 점검 루틴은 우회될 수 있기 때문에, 서버에서 최종 점검하는 것이 필요하다.
   물론 서버의 부하를 줄이기 위해서 1차적으로 클라이언트 레벨에서 점검할 수 있으나, 보안 통제 수단으로 사용할 수 없다.
   첨부파일 업로드 기능에 스크립트 파일의 전송 제한하기 위해서 파일 확장자 검사를  script를 사용해서 웹 브라우저 레벨에서
   수행할 경우, 공격자는 해당 script를 우회해서 서버에 원하는 스크립트 파일을 전송할수있다.
  
■ 점검방법 : HTML 및 웹 어플리케이션 소스 리뷰.
 
Guide 9. 클라이언트에게 중요 정보를 전달하지 말자.
 
■ Java Applet, ActiveX를 사용해서 C/S 어플리케이션을 작성하는 경우,
   클라이언트에서 실행되는 컴포넌트에 중요 정보를 코딩해서는 안된다.
   Cookie에 중요 정보를 전달할 경우, 암호화를 사용해야한다.
  
■ 점검방법
   1) HTML 소스 리뷰
   2) javascript:document.cookie; 입력해서 쿠키내용 확인
 
Guide 10. 중요 정보 전송시 POST method 및 SSL을 적용해야 한다.
 
■ 사용자로부터 중요 정보를 받을 때는 POST method를 사용해야하며,
   그 중요도에 따라 SSL을 사용한 암호화 통신을 적용해야한다.
   SSL은 자료 전송시 암호화를 지원하므로, 민감한 정보는 어플리케이션 레벨의 암호화를 고려해야한다.
  
■ 점검방법 : 중요 정보 전달 FORM ACTION에 사용된 프로토콜이 “HTTPS”로 되어 있는지 확인함.
 
Guide 11. 중요한 트렉젝션이 일어나는 프로세스에 사용자의 비밀번호를 재확인 하도록 하자.
 
■ 사용자의 개인정보 변경 프로세스에 비밀번호를 재확인 하는 루틴을 추가할 경우 불법적인 위장으로 인한 추가 피해를
   줄일 수 있다.
  
■ 점검방법 : 해당 프로세스 확인.
Guide 12. 중요 정보를 보여주는 페이지는 캐쉬를 못하게 설정하자.
 
■ 중요 정보를 보여주는 화면에 no-cache 설정을 하지 않을 경우, 로그아웃을 한 이후에도
   [뒤로가기]버튼을 사용해서 해당 내용을 볼수 잇는 위험이 존재한다.
  
■ 점검방법 : 중요 정보 페이지를 열어본 후, 로그아웃을 한다.
              웹브라우저의 “뒤로” 버튼을 눌렀을때 이전 내용이 보이는지 확인.
■ 조치방법 : no-cache 설정을 위하여 HEAD 부분에 언어별 또는 HTML 헤더에 추가한다.
 
Guide 13. 암호화를 올바르게 이해하고 사용하자.
 
■ 자체 개발한 암호화 알고리즘 사용을 지양하며, 공인된 암호화 알고리즘(3DES, SEED, AES 등등)을 사용하는 것을 고려한다.
   암호화 키를 사용하지 않는 알고리즘은 암호화 알고리즘이 아니라, 단순 인코딩 알고리즘으로 기밀성을 보장할수 없다.
   암호화 키는 소스에 hard-coding되어서는 안되며, 제한된 사람만이 접근이 가능하도록 해야한다.  
 
Trackback 0 Comment 0
2008/04/26 01:22

[SSO] - DB를 이용한 도메인간 세션공유 처리


서로 다른 도메인의 로그인 정보를 공유하긴 위한 목적으로 구현했습니다.
나름 보안에 취약하지 않게(?) 만들었었고요.

잘 응용해서 사용하시기 바랍니다.^^

사용자 삽입 이미지


Trackback 0 Comment 0
2008/04/26 01:10

AB 사용법 - Apache Benchmarking

AB 사용법 - Apache Benchmarking

$./ab -V
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

$./ab -h

Usage: ./ab [options] [http://]hostname[:port]/path
Options are:
    -n requests  Number of requests to perform : 벤치마킹을 위한 요청수
    -c concurrency Number of multiple requests to make : 하나의 요청당 체크할 다중 요구수 (기본값 : 1)
    -t timelimit Seconds to max. wait for responses : 제한시간
    -p postfile  File containg data to POST : POST 할 파일 지정
    -T content-type Content-type header for POSTing
    -v verbosity    How much troubleshooting info to print : 자세한 헤더정보 출력 (유용함)
    -w              Print out results in HTML tables : HTML 형태로 출력 (유용함)
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234' (repeatable) : 쿠키 사용시
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: zop'
                       Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                       are a colon separated username and password. : 사용자 인증을 요하는 페이지 체크시 아이디:비밀번호
    -P attribute    Add Basic Proxy Authentication, the attributes
                       are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature : 하나의 세션을 맺은 상태에서 여러개의 요구가 하나의 세션으로 인식
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -h              Display usage information (this message)

Example)

$./ab -c 30 -n 10 http://www.naver.com/

This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.naver.com (be patient).....done
Server Software:        Apache
Server Hostname:        www.naver.com
Server Port:            80

Document Path:          /
Document Length:        58985 bytes

Concurrency Level:      30
Time taken for tests:   0.979 seconds
Complete requests:      10
Failed requests:        9
   (Connect: 0, Length: 9, Exceptions: 0)
Broken pipe errors:     0
Total transferred:      1102138 bytes
HTML transferred:       1094313 bytes
Requests per second:    10.21 [#/sec] (mean)
Time per request:       2937.00 [ms] (mean)
Time per request:       97.90 [ms] (mean, across all concurrent requests)
Transfer rate:          1125.78 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1     6   13.1      2    44
Processing:   327   672  228.5    666   978
Waiting:      325   671  228.2    665   977
Total:        327   677  222.9    668   979

Percentage of the requests served within a certain time (ms)
  50%    668
  66%    866
  75%    892
  80%    909
  90%    979
  95%    979
  98%    979
  99%    979
 100%    979 (last request)

* ab 실행파일은 아파치를 설치한 디렉토리/bin 에 있습니다.

Trackback 0 Comment 0