28. 쿠키변조(CC)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
적절히 보호되지 않은 쿠키를 사용하여 쿠키 인젝션 등과 같은 쿠키 값 변조를 통한 다른 사용자로의 위장 및 권한 상승 등이 가능한 취약점으로, 쿠키(Cookie)는 클라이언트에 전달되는 값으로 중용 정보로 구성되어 있는 쿠키는 정보의 조작으로 다른 사용자의 유효한 세션을 취득할 수도 있고, 항상 탈취의 위협을 받는 쿠키에 중요정보가 포함 되어있으면 공격자에게 사용자의 중요한 정보가 노출 및 변조의 위험이 있다.
- 취약점 점검 방법
① 쿠키의 내용 및 발행되는 쿠키에 중요한 정보(인증을 위한 아이디, 권한을 위한 구분자 등)의 노출 여부를 조사한다.
② 쿠키의 중요 정보를 변경하여 다른 사용자 및 권한으로 정상적 이용이 가능한지 확인한다.
- 취약점 조치 방안
쿠키대신 보안성이 강한 Server Side Session을 사용
Client Side Session 방식인 쿠키는 그 구조상 다양한 취약점에 노출될 수 있으므로 가능한 웹 서버에서 제공되는 Server Side Session을 사용하는 것이 바람직하다.
27. 데이터평문전송(SN)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
서버와 클라이언트간 통신 시 암호화 하여 전송을 하지 않아 중요 정보 등이 평문으로 전송되는 취약점으로, 개인 정보를 암호화하지 않고 평문으로 전송 처리하여 도청을 통해 노출되는 취약점으로 암호화를 통해 위험을 최소화 할 수 있다. 웹 상의 데이터 통신은 대부분 텍스트 기반으로 이루어지고 있으며 이는 간단한 도청을 통해 쉽게 개인 정보의 탈취 및 도용이 가능해 진다.
- 취약점 점검 방법
① 중요 정보(인증정보, 개인정보 등)를 송수신하는 페이지가 있는지 조사한다.
② 중요 정보 송수신 페이지가 암호화 통신(https, 데이터 암호화 등)을 하는지 확인한다.
- 취약점 조치 방안
웹 상에서의 전송 정보를 제한하여 불필요한 비밀번호, 주민등록번호, 계좌정보 와 같은 중요 정보의 전송을 최소화해야 하며, 중요 정보에 대해서는 반드시 SSL 등의 암호화를 사용하여 도청으로부터의 위험을 없애야 한다.
또한 쿠키와 같이 클라이언트 측에서 노출되는 곳에 비밀번호, 인증인식 값, 개인정보 등의 정보를 기록하지 않아야 한다.
26. 위치공개(PL)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
예측 가능한 폴더나 파일명을 사용하여 해당 위치가 쉽게 노출되어 공격자가 이를 악용하여 대상에 대한 정보와 민감한 정보가 담긴 데이터에 접근이 가능하게 되는 취약점이다.
- 취약점 점검 방법
① .bak, .backup, .org, .old, .zip, .log, .sql, .new, .txt, .tmp, .temp 확장작의 불필요한 파일이 존재하는지 조사한다.
② cgi-bin , manual, usage, iissamples, scripts, iisHelp, IISAdmin, _vit_bin, Printers, phpinfo.php, examples, jsp, servlets의 디렉토리 및 파일이 존재하는지 조사한다.
- 취약점 조치 방안
| 삭제해야 할 파일 확장자 | |||
| *.bak | *.backup | *.org | *.old |
| *.zip | *.log | *.! | *.sql |
| *.new | *.txt | *.tmp | *.temp |
웹 디렉터리를 조사하여 다음과 같은 백업파일을 모두 삭제 하고, *.txt 같이 작업 중 생성된 일반 텍스트 파일이나 이미지 파일 등도 제거한다.
백업파일은 백업계획을 수립하여 안전한 곳에 정기적으로 백업을 해야 하며 웹 서버상에는 운영에 필요한 최소한의 파일만을 생성해야 한다.
웹 서버 설정 후 Default Page 와 Default Directory 및 Banner를 삭제하여 Banner Grab에 의한 시스템 정보 유출을 차단한다.
Apache, IIS, Tomcat 등 각 웹 서버 설정 시 함께 제공되는 Sample 디렉터리 및 Manual 디렉터리, Sample Application을 삭제하여 보안 위험을 최소화 한다.
25. 경로추적(PT)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
공격자에게 외부에서 디렉터리에 접근 할 수 있는 것이 허가되는 문제점으로 웹 루트 디렉터리에서 외부의 파일까지 접근하고 실행할 수 있는 취약점이다.
- 취약점 점검 방법
① 표시할 페이지의 파일을 지정하는 변수 값에 다음 값을 입력하여 해당파일의 내용이 표시되는 것을 확인한다.
../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../winnt/win.ini
../../../../../../../../../../../../boot.ini
② 다음 인코딩을 적용하여 ①에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
URL인코딩-.(%2e), /(%2f), \(%5c)
16bit 유니코드인코딩-.(%u002e), /(%u2215), \(%u2216)
더블URL인코딩-.(%252e), /(%252f), \(%255c)
③ 다음 문자열을 적용하여 ①에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
…//, ….\\, ….\/, …./\
④ 다음 문자열을 적용하여 ①에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
[파일명]%00.jpg, [파일명]%0a.jpg
- 취약점 조치 방안
웹사이트에서 접근하려는 파일이 있는 디렉토리에 chroot 환경을 적용해서 경로 추적 공격을 최소화할 수 있다. chroot 디렉토리는 해당 디렉토리가 루트처럼 다뤄진다. chroot 파일 시스템은 대부분의 유닉스를 기반으로 한 플랫폼에서 지원이 가능하고, 윈도우 플랫폼에서는 적절한 시작 디렉토리를 새로운 논리 드라이브로 만들어 웹사이트에서 해당 드라이브를 통하여 접근하게 한다.
24. 관리자페이지노출(AE)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
단순한 관리자 페이지 이름(admin, manager 등)이나 설정, 프로그램 설계상의 오류로 인해 관리자 메뉴에 직접 접근할 수 있는 취약점으로, 관리자 페이지는 웹 서비스의 사용자나 데이터, 컨텐츠를 손쉽게 관리하기 위한 목적으로 다양한 기능과 권한을 갖고 있고 이는 홈페이지의 운영에 매우 중요한 역할을 하고 있으므로 일반사용자는 인증을 통과하지 못하게 할 뿐 아니라 일반사용자가 관리자 페이지를 볼 수 없게 해야 한다. 그러나 일반적으로 추측하기 쉬운 URL(ex: /admin, /manager)을 사용하고 있어, ID/패스워드에 대한 크랙 또는 접근 허가 정책에 대해 요청하는 부분의 정보를 변경함으로써 접근이 가능한 경우가 많다. 웹 관리자의 권한이 노출될 경우 홈페이지의 변조뿐만 아니라 취약성 정도에 따라서 웹 서버의 권한까지도 노출될 위험성이 존재한다.
- 취약점 점검 방법
① /admin, /manager, /master, /system, /administrator 등의 명칭의 폴더 및 파일의 관리자 페이지가 존재하는지 확인한다.
② 7001, 8080, 8443, 8888 포트의 접속으로 관리 페이지가 노출되는 것을 확인한다.
③ 관리자페이지에 기본 관리자 계정 및 패스워드를 입력하여 패스워드 취약점을 점검한다.(관리자 계정 예 : admin, administrator, manager 등)
④ 사용자 인증을 통과하여 접속한 페이지에 대하여 인증 과정 없이 중간페이지에 접속하여 접속이 가능한지를 점검한다.(예 : /admin/main.asp, /admin/menu.html 등)
- 취약점 조치 방안
일반사용자의 접근이 불필요한 관리자 로그인 페이지 주소를 유추하기 어려운 이름으로 변경한다. 중요한 정보를 가진 웹 서버의 특정 페이지들은 관리자 또는 특정 사용자만 접근할 필요가 있다. 이러한 주요 페이지들은 웹 서버에서 적절한 설정을 통하여 특정 사용자만 접근이 가능하게 사용자 접근제한을 할 수 있다.
23. 파일다운로드(FD)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
공격자는 파일 다운로드 스크립트를 이용하여 첨부된 주요 파일을 다운로드 할 수 있는 취약점으로, 홈페이지 상에서 파일을 다운받는 cgi, jsp, php, php3 등의 프로그램에서 입력되는 경로를 체크하지 않는 경우, 임의의 문자(../.. 등)나 주요 파일명의 입력을 통해 웹 서버의 홈 디렉토리를 벗어나서 임의의 위치에 있는 파일을 열람하거나 다운받는 것이 가능할 수 있다.
- 취약점 점검 방법
① 게시판 또는 공지사항, 자료실 등에서 cgi, jsp, php 등의 프로그램을 이용하여 파일을 다운받는 페이지가 있는지 조사한다.
② 해당 홈페이지의 파일 다운받기 주소에서 다운받는 파일명을 시스템의 중요한 파일(winnt\win.ini, /etc/passwd 등)의 위치와 이름을 상대경로(../)로 치환한 후 입력하여 중요 파일의 다운이 가능한지 확인한다.
../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../winnt/win.ini
../../../../../../../../../../../../boot.ini
③ 다음 인코딩을 적용하여 ②에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
URL인코딩-.(%2e), /(%2f), \(%5c)
16bit 유니코드인코딩-.(%u002e), /(%u2215), \(%u2216)
더블URL인코딩-.(%252e), /(%252f), \(%255c)
④ 다음 문자열을 적용하여 ②에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
…//, ….\\, ….\/, …./\
⑤ 다음 문자열을 적용하여 ②에서 입력한 값을 전송해서 해당파일의 내용이 표시되는 것을 확인한다.
[파일명]%00.jpg, [파일명]%0a.jpg
- 취약점 조치 방안
파일 다운로드의 취약성은 주로 파일의 이름을 조작하는 데서 비롯한다. 다운로드 파일의 이름을 데이터베이스에 저장하고 다운로드 수행 시 요청 파일 이름과 비교하여 적절한지 확인하여 사용자가 조작할 수 있는 변수를 제거하는 것이 바람직하다. 또한 다운로드 위치는 지정된 데이터 저장소를 고정하여 사용하는 것이 바람직하다.
프로그램 내에서 파일을 다운받을 수 있는 디렉토리를 특정 디렉토리로 한정하고 이 외의 다른 디렉토리에서는 파일을 다운받을 수 없도록 프로그램을 수정하고, ..\ 등의 하위 경로 탐색은 제한하게 수정한다.
PHP를 사용하는 경우 php.ini 에서 magic_quotes_gpc 를 On으로 설정하여 .\./ 와 같은 역슬래시 문자에 대해 대응도 가능하다.
22. 파일업로드(FU)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
파일을 업로드 할 수 있는 기능을 이용하여 시스템 명령어를 실행할 수 있는 웹 프로그램을 업로드 할 수 있는 취약점으로, 만일 게시판에 업로드 되는 파일의 확장자에 대한 적합성 여부를 검증하는 루틴이 존재하지 않으면 공격자가 조작한 Server Side Script 파일을 업로드하고 업로드 된 파일이 서버 상에 저장된 경로를 유추한 후 이 경로를 통해 Server Side Script 파일을 실행하여 쉘을 획득할 수 있고 이러한 과정을 통해 웹 서버의 권한이 노출될 수 있다. 쉘 권한 획득 후, 시스템의 명령어를 홈페이지를 통해 실행하고 웹브라우저를 통해 그 결과 값을 보며 시스템 관리자 권한이나 인근 서버의 침입을 시도 할 수 있다.
- 취약점 점검 방법
① 먼저 사용자 게시판에 파일첨부 기능이 있는지 조사한다.
② 첨부기능이 존재하는 경우, 확장자가 jsp, php, asp, cgi 등 Server Side Script 프로그램을 업로드 하여 업로드가 가능한지 조사한다. 이 때 클라이언트 프로그램에서 JavaScript, VBScript 등의 스크립트로 파일첨부를 차단하는 경우 차단기능을 수정하여 파일을 첨부한다.
③ 홈페이지에 있는 디렉토리 정보를 이용하여 첨부한 Server Side Script 프로그램의 위치를 조사한 후 브라우저 주소 창에서 해당 프로그램의 실행이 가능한지 확인한다.
- 취약점 조치 방안
사용자가 파일을 업로드 할 수 있는 모든 모듈에 적용한다.
① Upload 파일을 위한 디렉토리에는 실행설정을 제거하고(웹서버 보안설정) Upload 파일을 위한 전용 디렉토리를 별도 생성하여 httpd.conf와 같은 웹 서버 데몬 설정파일에서 실행설정을 제거함으로써, Server Side Script가 Upload되더라도 웹 엔진이 실행하지 않게 환경을 설정한다.
– IIS 보안 설정
설정→제어판→관리도구→인터넷 서비스 관리자 선택한다. 해당 업로드 폴더에 오른쪽 클릭을 하고 등록정보→디렉토리→실행권한을 “없음”으로 설정한다.
– Apache 설정
Apache 설정 파일인httpd.conf에 해당 디렉토리에 대한 문서 타입을 컨트롤하기 위해 Directory 섹션의AllowOverride 지시자에서 FileInfo 또는 “All”을 추가 한다.
| <Directory “/usr/local/apache”>AllowOverride FileInfo (또는 All)….
… <Directory> |
파일 업로드 디렉토리에 .htaccess 파일을 만들고 다음과 같이 AddType 지시자를 이용, 현재 서버에서 운영되는 Server Side Script 확장자를 text/html로 MIME Type을 재조정하여 업로드 된 Server Side Script가 실행 되지 않도록 설정한다. 또는 FileMatch 지시자를 이용하여 *.ph, *.inc, *lib 등의 Server Side Script 파일에 대해서 직접 URL 호출을 금지 시킨다.
| <.htaccess><FilesMatch “\.(ph|inc|lib)”>
Order allow, deny Deny from all </FilesMatch> AddType text/html .html .htm .php .php3 .php4 .phtml .phps .in .cgi .pl .shtml .jsp |
※ 주의사항
(1) Apache 서버의 경우 AllowOverride 지시자를 변경 시 apache restart가 필요하다.
(2) 파일 업로드 되는 디렉토리에 운영에 필요한 Server Side Script가 존재하는지 확인한다.
(3) 파일 다운로드 프로그램이 아닌 직접 URL 호출을 통해 파일을 다운받는 경우 FileMatch 지시자를 사용하면 차단 설정한 확장자의 파일 다운로드는 거부된다.
② 첨부파일의 확장자 필터링 처리하여 사용자가 첨부파일의 Upload 시도 시, Upload되는 파일의 확장자를 검토하여 적절한 파일인지 검사하는 루틴을 삽입하여, 적합한 파일의 확장자 이외의 파일에 대해서는 업로드 되지 않도록 하며, 이런 필터링 규칙은 서버에서 구현해야 한다.
③ 시스템 보안설정 시 웹 서버 구동은 반드시 관리자 권한이 아닌 일반 사용자 권한으로 구동 한다. 외부사용자가 첨부파일을 이용하여 권한을 획득할지라도 최소한 의 권한만을 사용할 수 있도록 한다. 업로드 된 디렉토리에서 실행 권한을 제거하는 방법은 임시적이기는 하지만 소스 코드의 수정 없이 간단히 수행될 수 있다.
21. 프로세스검증누락(PV)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
공격자가 응용의 계획된 플로우 통제를 우회 하는 것을 허가하는 취약점이다.
- 취약점 점검 방법
① 업무프로세스를 파악한다.
② 권한의 종류 및 범위를 파악한다.
③ 페이지의 모든 기능을 수집하여 프로세스 상에 통제된 페이지에 접근이 가능한 것을 확인한다.
- 취약점 조치 방안
우회 될 수 있는 플로우를 차단하여야 하며, 페이지 별 권한 매트릭스를 작성하여, 페이지에 부여된 권한의 타당성을 체크 후에 권한 매트릭스를 기준으로 하여 전 페이지에서 권한 체크가 이뤄지도록 구현 하여야 한다.
20. 자동화공격(AU)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
웹 애플리케이션에 정해진 프로세스에 자동화된 공격을 수행함으로서 자동으로 수많은 프로세스가 진행되는 취약점이다.
자동화 공격을 방치하면, 자동 로봇 또는 공격자가 반복적으로 웹 사이트 기능을 사용해서 시스템을 악용할 수 있다.
- 취약점 점검 방법
① 데이터 등록 및 메일 발송의 기능에서 반복적인 기능 이용을 통하여 대량의 데이터 등록이나 메일 발송이 가능한지 확인한다.
- 취약점 조치 방안
데이터 등록 및 메일 발송의 기능에서 사용자의 등록이 일회성이 될 수 있도록, 이미지를 이용하여 확인 값을 표시하고 사용자가 값을 등록하여 인증하는 등의 일회성 확인 로직을 구현하여야 한다.
자동화공격을 시도하면 짧은 시간에 다량의 패킷량이 전송되므로 이를 공격으로 감지하고 방어할 수 있는 IDS/IPS의 시스템을 구축하여야 한다.
서버에 요청되는 패킷량을 모니터링 할 수 있는 시스템을 구축하지 않고는 적시적절한 방어를 하기 어렵다.
19. 세션고정(SF)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
세션 값을 고정하여 명확한 세션 ID 값으로 사용자가 로그인하여 정의된 세션 ID가 사용 가능하게 되는 취약점으로, 사이트가 승인받지 않은 사용자에게 세션ID를 발행하고, 사용자는 로그인을 통해 정상적인 애플리케이션 이용이 가능해진다. 로그인한 후에 애플리케이션이 새로운 세션ID를 발행하지 않는다면session fixation에 관한 공격의 가능성이 존재하게 되는 것이다.
- 취약점 점검 방법
① 로그인 기능에서 세션ID가 발행되는지 확인한다.
② 로그인 전에 URL 및 파라메터에 세션ID와 값을 삽입하여 세션으로 사용되는 지 확인한다.
- 취약점 조치 방안
인증 기능에서 사용자가 인증을 받은 후에 새로운 세션ID를 할당 받도록 발행한다.
18. 불충분한세션만료(SC)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
취약점 설명
세션의 만료 기간을 정하지 않거나, 만료일자를 너무 길게 설정하여 공격자가 만료되지 않은 세션 활용이 가능하게 되는 취약점으로, 세션만료는 사용자 인증 후 웹 사이트 내에서 이벤트 없이 일정시간이 경과하면, 임의로 세션을 종료시켜 서비스 접근을 제한하는 기능으로, 특히 공개된 장소에서 사용자가 오랜 시간 자리를 비우는 경우 타 사용자에 의한 침해를 방지하기 위해서 필요하다.
취약점 점검 방법
① 인증 후 정상적으로 세션이 발행된 페이지의 리퀘스트를 취득하여 일정시간(10분이상)이 지난 후에 재전송 시 정상처리가 되는지 확인한다.
취약점 조치 방안
① 세션 타임아웃 기능이 구현되어 있지 않을 경우 장시간 부재중인 사용자에 대한 보호장치가 없는 것이며, 세션타임아웃 구현 시 타임아웃 시간은 10분으로 설정할 것을 권고한다.
– ASP
접속자 별로 세션을 생성하여 사용자의 정보를 각각 저장할 수 있는Session 오브젝트를 사용하여 타임아웃 기능을 구현한다. Session 오브젝트는 페이지의 접근을 허가하거나 금지할 때 또는 사용자 별로 정보를 저장할 때 많이 사용하며 접속자의 브라우저에서 쿠키기능을 지원해야 Session 오브젝트의 사용이 가능하다. 다음과 같은 설정이 적용될 경우 사용자가 로그아웃할 경우 세션은 바로 삭제 되며 로그아웃하지 않고 10분 동안 웹 서버로의 요청이 없을 경우 세션은 없어지게 된다.
예) Session.Timeout = 10
| 구분 | 설 명 | |
| Property | SessionID | 사용자마다 갖게 되는 고유한 세션값 |
| Timeout | 세션이 유지되는 기간 | |
| Method | Abandon | 강제로 세션을 소멸시키는 함수 |
| Event | Onstart | 각각의 사용자가 처음 방문할 때 발생 |
| Onend | 사용자의 세션이 끝나는 시점에 발생 | |
– JSP
세션타임아웃기능을 구현하는 방법은 session.getLastAccessedTime() 를 이용하여 세션의 마지막 접근 시간으로부터 일정 시간 이내에 다시 세션에 접근하지 않은 경우자동으로 세션을 종료
세션의 타임아웃은 두 가지 방법으로 설정할 수 있다.
(1) web.xml 파일에서 <session-config> 태그를 사용하여 타임아웃을 지정하는 방법
(2) session 기본 객체가 제공하는 setMaxInactiveInterval() 메소드를 사용 <% session.setMaxInactiveInterval(600); %>
유의할 점은 web.xml에선 타임아웃 시간이 분단위이지만 메소드에선 초단위이다.
17. 불충분한인가(IN)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
민감한 데이터 또는 기능에 대한 접근권한 제한을 두지 않은 취약점으로 접근권한에 대한 인증 로직이 구현되지 않아 다른 사용자의 민감한 정보나 인증 후 접근 가능한 페이지에 대하여 인증 없이 접근이 가능할 수 있다.
- 취약점 점검 방법
① 개인정보 수정 및 패스워드 수정 기능의 페이지에서 다른 사용자와의 구분을 아이디, 일련번호 등의 단순한 값을 사용하는지 조사한다.
② 다른 사용자와 구분하는 값을 변경하는 것만으로 다른 사용자의 개인정보, 패스워드에 접근이 가능한지 확인한다.
- 취약점 조치 방안
민감한 중요 데이터에 대한 접근 페이지에서 인증을 위한 로직이 구현되지 않았다면, 세션을 통한 인증 및 사용자에게 확인을 위한 인증 값 입력을 통한 인증 절차의 로직을 구현하여야 한다.
페이지 별 권한 매트릭스를 작성하여, 페이지에 부여된 권한의 타당성을 체크 후에 권한 매트릭스를 기준으로 하여 전 페이지에서 권한 체크가 이뤄지도록 구현 하여야 한다.
16. 세션예측(SE)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
단순히 숫자가 증가하는 방법 등의 취약한 특정 세션의 ID를 예측하여 세션을 가로챌 수 있는 취약점으로, 사용자에게 전달하는 세션 ID가 일정한 패턴을 가지고 있는 경우 공격자는 샘플을 수집해서 세션 ID를 추측할 수 있게 되고, 추측 과정에서 많은 시도와 에러가 생겨도(예를 들면 하나의 유효한 정보를 얻기 위해 1000번 정도 시도를 하는 것) 비교적 짧은 시간 안에 자동으로 공격해서 유효한 세션ID를 얻는 것이 가능하다.
- 취약점 점검 방법
① 각기 다른 IP주소와 다른 사용자명, 시간적 차이로 세션ID를 발급 받는다.
② 발급받은 세션ID에 일정한 패턴이 있는지 조사한다.
③ 일정한 패턴이 확인되고, 패턴의 의한 사용가능한 세션ID의 예측이 가능한가 확인한다.
- 취약점 조치 방안
아무리 길이가 길고 복잡한 항목으로 세션ID가 만들어져도 공격자가 충분한 시간과 자원이 있다면 뚫는 것은 불가능하지 않다. 강력한 세션ID를 생성하는 주된 목적은 수많은 대역폭과 처리 자원을 가지고 있는 공격자가 하나의 유효한 세션ID를 추측하는데 최대한 오랜 시간이 걸리게 해서 쉽게 추측하지 못하게 하는 것이다.
단순 조합 보다는 상용 웹서버나 웹 애플리케이션 플래폼에서 제공하는 세션ID를 사용하고, 가능하다면 맞춤형 세션 관리 매커니즘을 권고한다.
15. 크로스사이트리퀘스트변조(CSRF)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
CSRF 공격은 로그온한 사용자 브라우저로 하여금 사용자의 세션 쿠키와 기타 인증 정보를 포함하는 위조된 HTTP 요청을 취약한 웹 애플리케이션에 전송하는 취약점으로, 데이터를 등록, 변경의 기능이 있는 페이지에서 동일 요청(Request)으로 매회 등록 및 변경 기능이 정상적으로 수행이 되면 CSRF(Cross-Site Request Forgery) 공격에 취약한 가능성을 가지게 된다. CSRF(Cross-Site Request Forgery) 공격은 사용자의 브라우저가 취약한 애플리케이션에 직접 요청을 전송하게 해 사용자가 의도하지 않은 공격자에게 이익이 되는 행위를 수행하게 한다.
- 취약점 점검 방법
① 등록 및 변경 등의 데이터 수정 기능의 페이지가 있는지 조사한다.
② 데이터 수정 페이지에서 전송되는 요청(Request)을 취득 후에 재송하여 정상적인 데이터 수정의 기능이 재수행 되는지 점검한다.
- 취약점 조치 방안
데이터를 등록, 수정하는 기능에서 단순한 사용자의 인증이나 사용 권한에 대한 체크 이외의 데이터에 대한 등록, 수정 기능 수행 여부를 체크할 수 있도록 구현한다.
14. 취약한패스워드복구(PR)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
취약한 패스워드 복구 메커니즘(패스워드 찾기 등)에 대해 공격자가 불법적으로 다른 사용자의 패스워드를 획득, 변경, 복구할 수 있는 취약점이다.
- 취약점 점검 방법
① 재발행 되는 패스워드 몇 개를 획득한다.
② 패스워드 재발행 기능에서 사용자의 연락처, 주소, 메일 주소, 일정패턴을 패스워드로 이용하는 것을 확인한다.
- 취약점 조치 방안
사용자의 개인정보(연락처, 주소, 메일 주소 등)으로 패스워드를 생성하지 말아야 하며, 난수를 이용한 불규칙적이고 최소길이(6자 이상 권고) 이상의 패턴이 없는 패스워드를 발급 하여야 한다.
13. 불충분한인증(IA)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
민감한 데이터에 접근할 수 있는 곳에 취약한 인증 메커니즘으로 구현된 취약점으로 인증 기능은 구현하였으나 단순한 추측 가능한 값으로 구현되어 권한 외의 페이지에 접근이 가능할 수 있다.
- 취약점 점검 방법
① 개인정보 수정 및 패스워드 수정 기능의 페이지에 접근 전에 본인인증에 대한 재인증을 하고 있는 것을 확인한다.
② 인증 후 페이지에 아이디만을 인증 값으로 하여 변수로 관리 되는지 확인한다.
- 취약점 조치 방안
개인정보 및 패스워드 수정 페이지와 같은 중요정보를 표시하는 페이지에서는 본인 인증을 재확인하는 로직을 구현하고, 인증 후에 이용 가능한 페이지에 사용자가 접근할 때마다 승인을 얻은 사용자인지를 페이지 마다 검증하여야 한다.
접근 통제 정책을 구현하고 있는 코드는 구조화, 모듈화가 되어 있어야 한다.
접근제어가 필요한 모든 페이지에 통제수단(로그인 체크 및 권한 체크)을 구현해야 한다. 특히, 하나의 프로세스가 여러 개의 페이지 또는 모듈로 이루어져 있을 때 권한 체크가 누락되는 경우를 방지하기 위해서 공통 모듈을 사용하는 것을 권장한다.
인증 과정을 처리하는 부분에 Client Side Script(Javascript, VBScript 등)을 사용하면 사용자가 임의로 수정할 수 있으므로 Server Side Script(PHP, ASP, JSP 등)를 통하여 인증 및 필터링 과정이 수행되어야 한다.
12. 약한문자열강도(BF)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
사용자의 이름이나 패스워드, 신용카드 정보나 암호화 키 등을 자동으로 대입하여 여러 시행착오 후에 맞는 값이 발견되는 취약점이다.
- 취약점 점검 방법
① 인증 값에 단순 조합의 값을 삽입하여 정상적인 인증을 취득하는 것을 확인한다.
취약한 계정: admin, administrator, manager, guest, test, scott, tomcat, root, user, operator, anonymous
취약한 패스워드: Abcd, aaaa, 1234, 1111, test, password, public, blank 패스워드, ID와 동일한 패스워드
- 취약점 조치 방안
취약한 계정 및 패스워드를 삭제하고, 사용자가 취약한 계정이나 패스워드를 등록하지 못하게 패스워드 규정이 반영이 된 체크로직을 구현하여야 한다.
| (1) 다음 각 목의 문자 종류 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성
* 영문 대문자(26개) (2) 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고 (3) 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경 |
11. 크로스사이트스크립팅(XS)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/18
- 취약점 설명
웹 애플리케이션을 사용해서 다른 최종 사용자의 클라이언트에서 임의의 스크립트가 실행되는 취약점으로, 크로스사이트스크립팅(XSS) 취약점은 웹 페이지가 사용자에게 입력 받은 데이터를 필터링하지 않고 그대로 동적으로 생성된 웹 페이지에 포함하여 사용자에게 재전송할 때 발생한다.
자바스크립트처럼 클라이언트 측에서 실행되는 언어로 작성된 악성 스크립트 코드를 웹 페이지, 웹 게시판 또는 이메일에 포함시켜 사용자에게 전달하면, 해당 웹 페이지나 이메일을 사용자가 클릭하거나 읽을 경우 악성 스크립트 코드가 웹 브라우저에서 실행이 된다.
이와 같이 공격자는 XSS 취약점이 존재하는 웹 사이트를 이용하여 자신이 만든 악의적인 스크립트를 일반 사용자의 컴퓨터에 전달하여 실행시킬 수 있는데, 이러한 공격방법을 통해 사용자 쿠키를 훔쳐서 해당 사용자권한으로 로그인하거나 브라우저를 제어할 수 있다.
- 취약점 점검 방법
① 게시판에 글쓰기와 같이 단문이상의 입력 가능한 부분에 실행 가능한 형태의 스크립트 태그(‘> <script> alert(‘XSS’); </script>, “> <script> alert(‘XSS’); </script> 등) 입력이 가능한지 확인한다.
② 다음 인코딩을 적용하여 ①에서 입력한 값을 전송해서 입력이 가능한지 확인한다.
URL인코딩-‘(%27), “(%22), ((%28), )(%29), /(%2f), ;(%3b), <(%3c), >(%3e), space(%20)
③ 입력한 스크립트 태그가 브라우져 화면에 표시되어 실행 가능한지 확인한다.
- 취약점 조치 방안
① 사용자 입력값에 대한 Positive 필터링을 구현하여 XSS 공격으로부터 웹 응용시스템을 방어한다. 응용시스템 차원에서 HTTP 헤더, 쿠키, 쿼리 스트링, 폼 필드, 히든 필드 등의 모든 인자들에 대해 허용된 유형의 데이터만을 받아들이도록 입력값 검증을 실시하는 방법이다. 해당 검증 방법은 현재의 컨텐츠를 파악하여 필터링을 수행하려고 해서는 안된다. 컨텐츠의 종류는 상당히 많으며 필터링을 우회하기 위한 인코딩 방식에도 여러 가지가 있다. 일반적으로 공격자는 <script> 태그를 이용해 공격하므로 <script> 문자열이 들어오면 <xxscript>나 다른 문자로 변환해 스크립트 태그가 실행되지 않도록 설정해야 한다. 공격자는 <script>태그 외에 다양한 기법을 이용해 공격하기 때문에 아래 표와 같이 필터링을 할 것들을 정해서 막는 ‘negative defence’가 아닌 입력 가능한 문자만 정한 뒤 다른 문자가 들어왔을 때 전부 막는 ‘positive defence’를 하는 것이 좋다. 입력값의 필터링은 명시적으로 허용되는 것을 지정하여 받아들이는 방식(positive Filtering)의 보안 정책을 강하게 권고한다. 허용되지 않는 것을 지정하는 방식(negative Filtering)의 보안 정책이나 공격 패턴(시그너처)에 기반한 보안 정책은 유지 보수가 힘들며 불완전하다.
② 사용자 입력값에 대한 표시 치환은 사용자 입력으로 사용 가능한 문자들을 정해놓고, 그 문자들을 제외한 나머지 모든 문자들을 필터링 하는 것을 말한다. 필터링 해야 하는 대상은 GET 질의 문자열, POST 데이터, 쿠키, URL, 그리고 일반적으로 브라우저와 웹 서버가 주고받는 모든 데이터를 포함한다. 아래는 특수문자에 대한 Entity 형태를 표시한 것이다.
| 변경전 | < | > | “ | ( | ) | # | & |
| 변경후 | < | > | " | ( | ) | # | & |
– 게시판에서 HTML 포맷을 사용할 수 없도록 설정한다.
– 필요한 경우 모든 HTML을 사용하지 못하게 설정 후 필요한 HTML tag만 쓸 수 있도록 설정한다.
10. 악성콘텐츠(CS)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
웹 애플리케이션에 정상적인 컨텐츠 대신에 악성 컨텐츠를 주입하여 사용자에게 악의적인 영향을 미치는 취약점이다.
- 취약점 점검 방법
게시판 등의 페이지에서 강제적으로 이뤄지는 악의적인 프로그램 다운로드나 악의적인 사이트로의 이동이 발생하는지 확인한다.
- 취약점 조치 방안
악성콘텐츠가 삽입되어 있는 페이지에 대하여 증적(화면, 소스 등)을 남기고, 삽입된 악성콘텐츠를 삭제 및 페이지의 삭제 등을 실시하여야 한다. 또한 취득한 증적을 가지고 악성콘텐츠의 삽입 원인에 대하여 분석하여 원인을 제거 하여야 한다.
9. 정보누출(IL)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
웹 사이트의 민감할 수 있는 부분의 데이터가 노출되는 것으로 개발과정의 코멘트나 에러 메시지 등에서 중요한 정보가 노출되어 공격자에게 2차 공격을 하기 위한 중요한 정보를 제공할 수 있는 취약점이다.
- 취약점 점검 방법
① html 소스 내에 개인정보(화면엔 마스킹처리 되지만 소스에는 그대로 표시), 인증정보, DB접속 정보 등의 중요 정보가 노출되고 있는지 확인한다.
② 에러 메시지에서 중요한 정보(시스템 정보, 절대경로 정보, 컴파일 소스 정보 등)가 노출되고 있는지 확인한다.
- 취약점 조치 방안
html 소스 단에 기록되는 정보는 사용자가 웹브라우저의 소스보기 기능만을 사용해도 간단히 내용을 볼 수 있으므로, html 소스 레벨에서 중요 정보를 코멘트 처리 및 hidden 등의 값으로 기록하지 말아야 한다.
일반적으로 웹에서 발생하는 에러 메시지는 400,500 번대 의 에러코드를 return하게 되는데 이러한 에러 코드에 대해 별도의 에러 페이지로 Redirect 하거나 적절한 에러 처리루틴을 설정하여 처리 되도록 한다.
① APACHE 설정
|
ErrorDocument 500 “Error Message”
ErrorDocument 404 “/your web root/error.html”
ErrorDocument 404 “/your web root/error.html”
ErrorDocument 402 http:/xxx.com/error.html |
위와 같이 특정 에러코드에 대해 에러 메시지를 출력할 수도 있고 특정 웹 페이지로 redirect 시킬 수 있다. 위 설정은 httpd.conf 의 전역 설정에 추가 하거나 원하는 가상 호스트의 <VirtualHost> </VirtualHost> 사이에 추가하면 된다.
② IIS 설정
|
(1) IIS 관리자에서 로컬 컴퓨터를 두 번 클릭하고 웹 사이트 폴더, 개별 웹 사이트 폴더, 가상 디렉터리 또는 파일을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭한다.
참고: 웹 사이트 수준에서 만든 구성 설정은 서버에 있는 모든 웹 사이트로 상속됩니다. 개별 사이트 또는 사이트 요소를 구성하여 상속을 무시할 수 있다.
(2) 사용자 지정 오류 탭을 클릭한다.
(3) HTTP 오류에 대한 오류 메시지 목록에서 변경하려는 HTTP 오류를 클릭한 다음 편집을 클릭한다.
참고: 오류 400, 403.9, 411, 414, 500, 500.11, 500.14, 500.15, 501, 503 및 505는 사용자 지정할 수 없다.
(4) 메시지 유형 목록 상자에서 파일을 클릭하여 사용자 지정 오류 파일을 반환하거나 URL을 클릭하여 로컬 컴퓨터의 사용자 지정 오류 URL로 요청을 보낼 수 있다.
중요: 사용자 지정 오류가 .asp 페이지라면 URL을 선택해야 합니다. URL을 선택하지 않으면 클라이언트로 .asp 소스 코드가 반환될 위험이 있다.
(5) 파일을 선택했다면 파일에 대한 경로를 입력하거나 찾아보기를 클릭하여 파일을 찾습니다. 사용자 지정 오류 메시지는 기본적으로 systemroot\Help\IisHelp\Common 폴더에 설치됩니다. 파일 이름은 특정 HTTP 오류에 해당되는 번호 즉 400.htm, 401-1.htm 등이 된다.
또는 URL을 선택했다면 웹 사이트나 가상 디렉터리에 대한 경로를 입력합니다. URL은 로컬 컴퓨터에 있는 웹 사이트나 가상 디렉터리여야 하며, 사용자 지정 오류 URL은 요청을 사용자 지정 오류 URL로 보내는 응용 프로그램 풀에 있어야 한다.
사용자 지정 오류 페이지를 가상 디렉터리에 저장한 경우 해당 가상 디렉터리는 웹 사이트의 다른 부분과 동일한 응용 프로그램 풀에서 실행되어야 합니다. 그렇지 않으면 작업자 프로세스가 요청된 사용자 지정 오류 페이지를 처리할 수 없다.
(6) 확인을 클릭하고 다시 확인을 클릭한다. |
8. 디렉토리인덱싱(DI)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
본 페이지(index.html, home.html, default.asp 등)의 파일이 존재하지 않을 때 자동적으로 디렉토리 리스트를 출력하는 취약점으로, 웹 서버 운영 시 특정 디렉터리에 초기화 파일이 없을 경우(index.html, default.html 등…) 해당 디렉터리의 파일 리스트를 브라우저에 보여주게 되며 이는 공격자에게 웹 응용시스템의 구조를 파악 할 수 있도록 하며 민감한 정보가 포함된 설정 파일을 노출 하여 보안상 심각한 위험을 초래 할 수 있으므로 반드시 해당 기능을 중지 시켜야 한다.
- 취약점 점검 방법
① URL 경로 중 확인 하고자 하는 디렉터리까지만 주소 창에 입력하여 인덱싱 여부를 확인한다.
② 디렉터리 끝에 %3f.jsp 문자열을 붙여 디렉터리 인덱싱이 되는지 확인한다.
- 취약점 조치 방안
웹 서버 환경설정에서 디렉터리 인덱싱 기능을 제거한다. 각 웹 서버에 따른 설정 방법은 다음과 같다.
① APACHE 설정
|
Httpd.conf 파일에서 DocumentRoot 항목의 Options 에서 Indexes를 제거한다. Indexes가 해당 디렉터리의 파일 목록을 보여주는 지시자 이다.
<Directory “/var/www/html”>
Options Indexes
</Directory> |
② IIS 설정
|
설정 > 제어판 > 관리도구 > “인터넷 서비스 관리자” 선택 후 해당 웹사이트에 오른쪽 클릭을 하고 등록정보의 [홈 디렉토리] 탭에서 [디렉토리 검색] 체크를 해제 한다.
 |
③ %3f.jsp 취약점 제거
|
웹 서버를 아파치를 사용한다면 아래와 같이 설정하여 %3f.jsp 문자를 필터링 해야 하며 resin 이나 tomcat 을 사용한다면 최신 버전으로 업그레이드 해야 한다.
<LocationMatch “/(%3f|\?)\.jsp”>
AllowOverride None
Deny from all
</LocationMatch>
Resin 2.1.x 에서는 최신 버전으로 업그레이드 하거나 아래와 같이 설정 할 수 있다.
Resin 환경 설정 파일 (resin.conf) 에서 가상 디렉터리 설정 부분인 “web-app id”를 찾아서 아래 내용을 추가한다.
<directory-servlet>none</directory-servlet>
주의: 모든 가상 디렉터리에 전부 적용해야 한다. |
7. XPath인젝션(XI)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
조작된 XPath(XML Path Language) 쿼리를 보냄으로써 비정상적인 데이터를 쿼리해 올 수 있는 취약점으로, XML 문서에 데이터를 저장하는 웹사이트는 사용자가 입력한 내용의 데이터를 찾기 위해 XPath를 사용하고, 이런 입력이 필터링이나 보안을 고려하지 않은 채 XPath 쿼리 안에 입력된다면 웹사이트의 로직을 손상시키거나 특정 데이터를 추출할 수 있게 된다.
- 취약점 점검 방법
① [‘and’a’=’a, ‘and’a’=’b], [ and 1=1, and 1=2]의 셋트의 값을 각각 삽입하여 정상 변수 값을 보낸 화면과 [동일화면, 다른화면]의 반응이 있는지 확인한다.
② 다음 값을 입력해서 에러가 발생하지 않는지 확인한다.
‘ or count(parent::*[position()=1])=0 or ‘a’=’b
‘ or count(parent::*[position()=1])>0 or ‘a’=’b
1 or count(parent::*[position()=1])=0
1 or count(parent::*[position()=1])>0
- 취약점 조치 방안
XPath 쿼리에 입력 값이 입력되는 경우에는 엄격한 입력 값 검증을 통해 필요한 문자만을 받아들이게 해야 한다. ( ) = ‘ [ ] : , * / 등 XPath 쿼리를 파괴하는 특수문자는 입력하지 못하게 해야 하며, 특정 특수문자만을 필터링하는 것이 아닌 허용된 문자 이외의 모든 입력을 허용하지 않아야 한다.
6. SSI인젝션(SS)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
SSI(Server-side Include)는 “Last modified”와 같이 서버가 HTML 문서에 입력하는 변수 값으로, 웹서버상에 있는 파일을 include 시키고, 명령문이 실행되게 하여 데이터에 접근할 수 있는 취약점이다.
- 취약점 점검 방법
① 변수 값에 <!–#echo var=”DOCUMENT_ROOT” –>를 삽입하여 표시 페이지에 사이트의 홈디렉토리가 표시되는지 확인한다.
② 변수 값에 <!–#exec cmd=”ls -al” –>를 삽입하여 표시 페이지에 디렉토리의 파일 리스트가 표시되는지 확인한다.
- 취약점 조치 방안
사용자 입력으로 사용 가능한 문자들을 정해놓고, 그 문자들을 제외한 나머지 모든 문자들을 필터링 한다. 필터링 해야 하는 대상은 GET 질의 문자열, POST 데이터, 쿠키, URL, 그리고 일반적으로 브라우저와 웹 서버가 주고받는 모든 데이터를 포함한다. 아래는 특수문자에 대한 Entity 형태를 표시한 것이다.
| 변경전 | < | > | “ | ( | ) | # | & |
|---|---|---|---|---|---|---|---|
| 변경후 | < | > | " | ( | ) | # | & |
5. SQL인젝션(SI)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
SQL문으로 해석될 수 있는 입력을 시도하여 데이터베이스에 접근할 수 있는 취약점으로, 대부분의 웹 사이트들은 사용자로부터 입력받은 값을 이용해 데이터베이스 접근을 위한 SQL Query를 만들고 있다. 사용자 로그인 과정을 예로 들면, 사용자가 유효한 계정과 패스워드를 입력했는지 확인하기 위해 사용자 계정과 패스워드에 관한 SQL Query문을 만든다. 이때 SQL injection 기법을 통해서 정상적인 SQL query를 변조할 수 있도록 조작된 사용자 이름과 패스워드를 보내 정상적인 동작을 방해할 수 있다. 이러한 비정상적인 SQL Query를 이용해 다음과 같은 공격이 가능하다.
– 사용자 인증을 비정상적으로 통과할 수 있다.
– 데이터베이스에 저장된 데이터를 임의로 열람할 수 있다.
– 데이터베이스의 시스템 명령을 이용하여 시스템 조작이 가능하다.
- 취약점 점검 방법
① 변수 값에 큰따옴표(“), 작은따옴표(‘), 세미콜론(;) 등을 입력한 후, DB error가 일어나는지 확인한다.
② [‘and’a’=’a, ‘and’a’=’b], [ and 1=1, and 1=2]의 셋트의 값을 각각 삽입하여 정상 변수 값을 보낸 화면과 [동일화면, 다른화면]의 반응이 있는지 확인한다.
③ 로그인 화면의 경우 아이디나 패스워드 변수 값에 [‘or 1=1 –],[‘or ”=’]를 입력한 후 로그인이 되는지 시도한다.
- 취약점 조치 방안
데이터베이스와 연동을 하는 스크립트의 모든 파라미터들을 점검하여 사용자의 입력 값이 SQL injection을 발생시키지 않도록 수정한다.
사용자 입력이 SQL injection을 발생시키지 않도록 사용자 입력 시 특수문자(‘ ” / \ ; : Space — +등)가 포함되어 있는지 검사하여 허용되지 않은 문자열이나 문자가 포함된 경우에는 에러로 처리한다.
SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정한다. 공격자는 리턴 되는 에러 메시지에 대한 분석을 통하여 공격에 성공할 수 있는 SQL Injection 스트링을 알아낼 수 있다. 따라서 SQL 서버의 에러 메시지를 외부에 제공하지 않도록 한다.
웹 애플리케이션이 사용하는 데이터베이스 사용자의 권한을 제한한다.
가능하면 일반 사용자 권한으로는 모든 system stored procedures에 접근하지 못하게 하여 웹 애플리케이션의 SQL Injection 취약점을 이용하여 데이터베이스 전체에 대한 제어권을 얻거나 데이터베이스를 운용 중인 서버에 대한 접근이 불가능하게 한다.
php.ini 설정 변경 : php.ini 설정 중 magic_quotes_gpc 값을 On으로 설정한다.
|
Magic quotes Magic quotes for incoming GET/POST/Cookie data magic_quotes_gpc = ON ; Off에서 On으로 변경한다. Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc. magic_quotes_runtime = Off Use Sybase-style magic quotes (escape ‘ with ” instead of \’). magic_quotes_sybase = Off |
4. 운영체제명령실행(OC)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
웹사이트의 인터페이스를 통해 웹서버를 운영하는 운영체제 명령을 실행하는 취약점으로, 대부분의 웹서버 플랫폼은 서버의 운영체제에서 어떤 요청에 대한 응답을 수행하기 위해 내장된 API를 가지고 있다. 개발자들은 이런 유용한 API들을 이용해서 파일 시스템에 접근하거나 다른 프로세스와 통신하거나 안전한 방식으로 네트워크 통신을 할 수 있다. 개발자들은 서버상에 직접 운영체제 명령어를 실행할 수 있는 좀 더 강력한 기술을 이용해야 하는 경우도 많다. 이런 기술은 간단하고도 강력하기 때문에 상당히 매력적인 기술이고 이런 기술을 이용해서 특정 문제를 해결할 수도 있다. 그러나 애플리케이션이 사용자가 입력하는 부분에 운영체제 명령어를 실행할 수 있게 통과시켜 버린다면 명령어 삽입 취약점이 생기게 되고, 공격자는 해당 입력 부분에 특정한 시스템 명령어를 삽입해 원하는 결과를 얻을 수도 있다.
- 취약점 점검 방법
① 변수 값에 운영체계 명령어(ls, ifconfig, dir 등)를 삽입한다.
② 삽입한 운영체계 명령어에 대하여 시스템 내부에서 실행되어 결과 값으로 출력되는 것을 확인한다.
- 취약점 조치 방안
일반적으로 운영체제 명령어 삽입 취약점을 막는 가장 효과적인 방법은 애플리케이션이 운영체제로부터 어떤 명령어를 직접적으로 호출하지 못하게 모두 막는 것이다. 가상적으로 웹 애플리케이션이 수행하기 위해 필요하다고 생각할 수 있는 작업은 추가적인 명령어를 수행하기 위해 조작될 수 없는 내장된 API를 이용해서 실행된다.
사용자가 입력한 데이터가 운영체제 명령어 해석기에 바로 전달되는 부분이 있다면 애플리케이션은 취약점이 발생하는 것을 막기 위해 엄격한 보안을 수행해야 한다. 가능하다면 사용자가 입력하는 값에 대해 화이트 목록을 이용해서 해당 목록에 없는 갑에 대해서는 엄격하게 제한해야 한다. 반면 입력을 알파벳이나 숫자와 같이 매우 좁은 영역에 대해서만 제한할 수도 있다. 입력은 메타 문자나 빈칸을 포함해 상상할 수 있는 어떤 데이터든지 입력될 수 있다는 것을 고려해야 한다.
추가적인 보호 계층을 통해 애플리케이션은 명령어 연결이나 재전송을 지원하는 쉘 해석기에 명령어 문자열을 전달하는 것보다 이름과 명령어 라인 변수를 통해 특정한 프로세스를 실행하는 API를 사용하게 해야 한다. 자바 API Runtime.exec와 ASP.NET API Process.Start는 쉘 해석기를 지원하지 않고 있으며, 명령어는 오직 개발자에 의해서만 수행될 것이라고 확신하는데 사용된다.
3. LDAP인젝션(LI)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
LDAP(Lightweight Directory Access Protocol)쿼리를 주입함으로서 개인정보 등의 내용이 유출될 수 있는 문제를 이용하는 취약점으로, LDAP는 조직이나, 개체, 그리고 인터넷이나 기업 내의 인트라넷 등 네트워크 상에 있는 파일이나 장치들과 같은 자원 등의 위치를 찾을 수 있게 해주는 소프트웨어 프로토콜로, 일부 웹사이트에서 사용자 입력 부분을 LDAP 쿼리로 수행하고, 입력값 필터링을 제대로 처리하지 못할 경우 LDAP 구문을 변경하여 개인정보 등의 내용을 취득할 수 있다.
- 취약점 점검 방법
① LDAP에서 와일드 문자로 사용되는 * 기호를 입력하여 반환되는 데이터 량의 변화를 확인한다.
② [*);cn;], [*));cn;], [*)));cn;], [*)));cn;]의 방법으로 ) 기호를 추가하여 에러가 발생하는지 확인한다.
- 취약점 조치 방안
입력이 LDAP 쿼리에 포함되어야 하는 경우라면, 입력한 값은 허용된 문자로만 검증이 되어야 하고, ( ) ; , * | & =와 같은 LDAP 쿼리에 영향을 주는 특수문자는 입력되지 못하게 허용된 특수문자 이외의 입력을 막아야 한다.
2. 포맷스트링(FS)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
스트링을 처리하는 부분에서 메모리 공간에 접근할 수 있는 문제를 이용하는 취약점이다. 여기서 포맷스트링(“%f”, “%p”, “%n” 등)을 사용하면 dumpcode 함수를 사용한 것과 비슷하게 메모리의 내용을 출력해볼 수 있다.
- 취약점 점검 방법
① 변수값에 다음과 같은 패턴을 삽입한다.
– %n%n%n%n%n%n%n%n%n%n,
– %s%s%s%s%s%s%s%s%s%s,
– %1!n!%2!n!%3!n!%4!n!%5!n!%6!n!%7!n!%8!n!%9!n!%10!n!
– %1!s!%2!s!%3!s!%4!s!%5!s!%6!s!%7!s!%8!s!%9!s!%10!s!
② 위의 값을 삽입 시 다음과 같은 응답이 발생하면 취약할 수 있다.
– 다른 변형된 입력에서는 발생하지 않던 500에러 코드나 에러 메시지가 긴 입력 값에서만 발생할 때
– 내부의 일반 코드에서 어떤 에러가 발생했다는 메시지를 표시할 때
– 서버에서 완전하지 않거나 이상한 응답을 할 때
– 응답을 받지 못하고 갑자기 끊어질 때
– 전체 웹사이트가 반응이 없을 때
- 취약점 조치 방안
웹 서버 응용프로그램(Apache, Tomcat, IIS 등)에서 발견된 취약점에 대해서는 프로그램 제공사에서 제공되는 패치가 있는지 확인하여 최신 보안패치가 반영되도록 유지한다.
웹사이트 입력값에 대하여 처리 중에 발생할 경우에는 사용자가 입력하는 값에 대하여 타당성에 대한 체크로직을 구현해야 한다.
1. 버퍼오버플로우(BO)
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 취약점 설명
메모리나 버퍼의 블록 크기보다 더 많은 데이터를 넣음으로써 결함을 발생시키는 취약점을 말한다. 프로그램이 버퍼 오버플로우 취약점을 내재하고 있을 경우, 해커는 이 공격을 이용하여 자신이 원하는 실행코드를 수행할 수 있고, 이 취약점을 이용해 쉘 코드를 실행함으로써 원격에서 Shell을 얻을 수 있게 된다.
공격자는 웹 애플리케이션의 실행 가능한 스택을 덮어쓰기 위해 버퍼 오버플로우 기법을 사용한다. 공격자는 웹 애플리케이션에 조작한 입력 값을 보내어 웹 애플리케이션이 임의의 코드를 수행하게 할 수 있으며, 이를 이용해 시스템을 효과적으로 장악할 수 있다.
- 취약점 점검 방법
① 변수 값에 1100, 4200, 33000과 같이 일반적인 버퍼 길이보다 긴 문자열을 입력하여 다음과 같은 현상이 발생하는지 확인한다.
– 다른 변형된 입력에서는 발생하지 않던 500에러 코드나 에러 메시지가 긴 입력 값에서만 발생할 때
– 내부의 일반 코드에서 어떤 에러가 발생했다는 메시지를 표시할 때
– 서버에서 완전하지 않거나 이상한 응답을 할 때
– 응답을 받지 못하고 갑자기 끊어질 때
– 전체 웹사이트가 반응이 없을 때
- 취약점 조치 방안
웹 서버 응용프로그램(Apache, Tomcat, IIS 등)에서 발견된 취약점에 대해서는 프로그램 제공사에서 제공되는 패치가 있는지 확인하여 최신 보안패치가 반영되도록 유지한다.
웹사이트 입력값에 대하여 처리 중에 발생할 경우에는 사용자가 입력하는 값에 대하여 길이 및 입력 범위에 대한 체크로직을 구현해야 한다.
웹 취약점별 대응 방안
게시자: rokmc843, 카테고리: Vulnerability, 날짜: 2011/04/06
- 웹 취약점 점검 항목
[전자정부 표준 웹 취약점 관리기준]의 취약점 항목
| No. | 코드 | 진단 항목 | 비고 |
| 1 | BO | 버퍼오버플로우 | Buffer Overflow |
| 2 | FS | 포맷스트링 | Format String |
| 3 | LI | LDAP인젝션 | LDAP(Lightwegiht Directory Access Protocol) Injection |
| 4 | OC | 운영체제명령실행 | Operatingsystem Command |
| 5 | SI | SQL인젝션 | Sql Injecion |
| 6 | SS | SSI인젝션 | Server-Side Include Injection |
| 7 | XI | XPath인젝션 | XPath Injection |
| 8 | DI | 디렉토리인덱싱 | Directory Indexing |
| 9 | IL | 정보누출 | Information Leak |
| 10 | CS | 악성콘텐츠 | |
| 11 | XS | 크로스사이트스크립팅 | Cross Site Script |
| 12 | BF | 약한문자열강도 | Brute Force attack |
| 13 | IA | 불충분한인증 | Insufficient Authentication |
| 14 | PR | 취약한패스워드복구 | Password Recovery |
| 15 | CF | 크로스사이트리퀘스트변조(CSRF) | The Cross-Site Request Forgery |
| 16 | SE | 세션 예측 | Session Expect |
| 17 | IN | 불충분한 인가 | Insufficiency |
| 18 | SC | 불충분한 세션만료 | Session Close |
| 19 | SF | 세션고정 | Session Fasten |
| 20 | AU | 자동화공격 | |
| 21 | PV | 프로세스검증누락 | Process Vulnerability |
| 22 | FU | 파일업로드 | File Upload |
| 23 | FD | 파일다운로드 | File Download |
| 24 | AE | 관리자페이지노출 | Administrator page Exposure |
| 25 | PT | 경로추적 | Path Tracing |
| 26 | PL | 위치공개 | Path Location |
| 27 | SN | 데이터평문전송 | |
| 28 | CC | 쿠키변조 |