securitory

취약점

Google 같은 검색엔진은 검색로봇을 이용하여 웹페이지를 수집하고 검색결과에 노출시키는데

이때, 노출되어서는 안되는 정보가 검색엔진에 노출될 수 있다.

따라서, 외부에 공개할 정보의 범위를 제한하는 설정을 해주자!

보안조치

작성해줘야할 파일은 robots.txt

이 파일은 검색엔진에 의해 참고된다.

#cd $Web_Root	//웹서버 루트로 이동한다

#vi robots.txt	//파일 생성해주자
User-agent: *	//모든 검색엔진을 지정한다 구글:Googlebot 
Disallow: /	//적용할 디렉토리를 지정 웹루트로부터 하위 디렉토리를 포함

User-agent: *	//모든 검색엔진이 수집하는 것을 허용
allow: /

User-agent: Googlebot	//구글 엔진만 허용
Allow: /

User-agent: Naverbot	//네이버 엔진만 허용
Allow: /

그밖에 엔진들
Daumoa
Msnbot
Bingbot

마무리

robots.txt 파일은 텍스트 파일로서 누구나 URL을 통해서 열람이 가능한 파일이므로 관리자 페이지경로와 같은 민감한 경로는 포함해서는 안됨

(예를들어, Disallow : /admin/admin.jsp)

참조

취약점

WebDAV는 웹서버 관리 프로그램으로 FTP와 유사하다.

윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인 WebDAV가 계속 사용가능하도록 설정되어 있고,

WebDAV 라이브러리 파일의 속성 및 홈페이지 디렉토리에 쓰기 권한이 모두 허용되어 있는 경우

해커가 WebDAV 도구를 사용, 원격에서 홈페이지 디렉토리에 임의의 파일을 삽입하여 화면을 변조할 수 있다.

따라서 윈도우 서버를 운용시에는 이 서비스를 사용안함으로 변경시켜준다!

보안조치

서버 환경이 리눅스인 관계로 내용만 기술하고 실습은 PASS

■ IIS 를 사용하지 않을 경우

 윈도우의 서비스 설정에서 [World Wide Web Publishing Service] 속성을 사용 안함으로 설정

■ IIS 를 사용하지 않을 경우

 레지스트리 편집기(Regedt32.exe)에서 다음 키를 찾아 값을 수정하거나 추가함                                                                                                                                               

"JSP 보안 개발 가이드" 에서

참조

취약점

웹사이트에서 중요 정보에 대한 데이터 암호화를 적용하여도 정보가 노출될 수 있다.

2가지 유형으로 살펴보면

 첫 째, 웹사이트 운영상의 단순한 실수로 발생할수있다.

예를 들어, 관리되지 않고 방치되는 게시판 또는 삭제되지 않은 구 버전 웹사이트, 백업 파일 관리 미흡, 관리자의 실수로 업로드된 엑셀 파일 또는 게시물, 비공개 게시물이 설정 실수로 인해 전원에게 공개되는 경우 등을 들 수 있다.

 둘 째, 웹사이트 설정 오류나 보안 취약점으로 발생할 수 있다.

예를 들어 암호화가 미흡하거나 파일 업로드 취약점이나 파일 다운로드 취약점을 통해 서버 측의 리소스가 직접 유출되는 경우, 디렉터리 인덱싱에 의해 파일 목록이 유출되는 경우, 파라미터 변조 취약점 등에 의해서 발생하는 경우, SQL Injection으로 인한 유출 등을 들 수 있다.

따라서, 운영 담당자의 상시 웹사이트 점검 노력과 보안 취약점의 제거 대책이 종합적으로 적용되어야 한다.

보안조치

마무리

웹사이트의 보안 조치는 기술적인 측면뿐 아니라 민감정보 와일드카드 처리나 개인정보 보관에 관련한 정책 등 관리적 측면에서도 수행되어야 한다.

참조

취약점

공격자가 대상 시스템의 현황을 파악하기 위하여 다양한 에러를 유발시킴으로써 반응하는 에러 결과값으로 웹 프로그램의 구조 및 환경설정을 추측하여 공격에 이용

예를 들어, 존재하지 않은 페이지를 요청하고 반환되는 서버 버전 정보를 파악하는 것

따라서, 지정된 에러페이지를 만들어 응답해주는 설정을 해주어야한다.

보안조치

먼저는 Error를 위한 별도의 페이지를 작성하고 web.xml을 수정해주자!

■ web.xml을 열어 다음 코드를 입력시킨다

앞으로 404에러코드가 발생하면 error_404.jsp파일이 응답하도록 설정되었다!

결과

적용 전 

적용 후

취약점

웹 디렉토리 내에 백업용 압축파일, 테스트 파일 등이 존재하고 유추 가능한 이름으로 되어 있는 경우, 별도의 과정 없이 다운로드가 가능하거나 내용이 브라우저 상으로 출력될 수 있으므로 이를 통해서 중요한 정보가 노출될 위협이 있음.

따라서, 백업 파일 및 테스트 파일을 관리를 해주자!

보안조치

관리자는 웹 디렉토리를 조사하여 *.asp.bak , *.jsp.bak, *.php.old와 같은 백업파일을 모두 삭제!

■ 다음은 모든 백업 확장자를 찾아 지우자

$ find $Web_Root -name *.bak -exec rm {} \; 

*$Web_Root는 웹 루트 디렉터리를 담고있음

■ 주기적으로 삭제 명령이 실행되도록 설정해주자

#crontab -e 	//일정 설정
0 4 * * 2 rm -rf $WebRoot/WebContent/*.bak /*매주 화요일 오전4시에 rm명령어 수행*/

#crontab -l	//내용 확인

*crontab은 명령어를 예약해주는 서비스이다. 분/시/일/월/요일 명령어 순으로 작성한다.

참조

취약점

기본적으로 제공되는 자원이 공격에 단서가 될수있다. Tomcat이 제공하는 관리 콘솔인 admin과 manager이 그러하다.

admin의 기능으로 페이지 동작상태를 확인하거나 서버정보, JVM, OS정보를 열람할 수 있다.

따라서 기본 관리 콘솔이 불필요시 다음을 찾아 제거해주자!

보안조치 

루트 웹디렉토리 내에 admin과 manager 디렉터리가 있는지 확인

참조

취약점

웹서버 설정상의 오류나 개발 과정의 편의를 위해서 웹 디렉토리 내부의 파일 리스트가 웹브라우져를 통해서 출력되도록 설정되어 있을 수 있음

웹 디렉토리의 파일 목록이 노출되면 공격자에게 웹사이트 구조 및 환경과 관련된 정보가 노출될 수 있으며

백업 파일이나 설정 파일 등이 웹 디렉토리 내부에 존재할 경우, 공격자가 이 파일을 다운로드하여 웹사이트의 핵심적인 정보를 획득할 수 있음

따라서, 서버의 자원을 한눈에 보여주는 디렉터리 인덱싱 기능을 비활성화 시켜주자!

보안조치

손볼 설정파일은 하나, web.xml 인덱싱 기능을 꺼주면된다.

■ 적용 전, 디렉터리 인덱싱 기능이 활성화됨

■ 톰켓홈디렉토리 web.xml에서 listings를 false로 설정

■ 결과

인덱싱 기능이 비활성화 되었다!

서버정보가 노출되는 데, 이것은 에러페이지 설정을 해줄 것

취약점

공격자는 웹 URL의 GET/POST 파리미터 또는 HTML 코드의 <INPUT> 변수, Hidden field, javascript 변수 등에서 노출되는 데이터를 통해서 서버측 프로그램의 로직 및 역할 등을 유추할 수 있다.

또한 해당 변수의 값을 고의적을 변조하여 특정한 값을 입력하여 전송하므로서 서버측 프로그램이 자신이 원하는 특정 작업을 수행하도록 조작을 시도할 수 있다.

만일 웹사이트 로직이 신중하계 설계되지 않는다면 공격자가 전송한 조작된 입력값에 의해서 서버측 프로그램이 의도되지 않은 오동작이나 정상적인 처리 범위를 벗어난 불법적인 작업이 발생할 수 있다.

■ 대표적인 취약점 예시

[1] 게시물 번호 조작을 통한 타 사용자의 게시물에 대한 무단 열람/수정/삭제
[2] Role based 웹사이트에서 사용자 Role 등급의 임의 변경
[3] 온라인 결재시 상품 금액 등 결재 데이터의 변조
[4] 아이디, 사번 등의 변조를 통해 타 사용자 정보의 무단 열람 및 수정
[5] 회원 가입시 실명 인증에 대한 우회
[6] 접근이 제한되어 있는 정보에 대한 무단 열람 또는 변조
[7] 인증 로직의 우회, 악성 파일의 업로드, 서버측 리소스에 대한 무단 다운로드

1번에 대한 실습을 진행한다.

실습

[1] 게시물 번호 조작을 통한 타 사용자의 게시물에 대한 무단 열람/수정/삭제

■ 글은 보이지 않지만 2번 글이 존재함을 유추할 수 있다.

■ 글번호 2를 입력하여 열람해보았더니 열람성공!

■ 보안조치

삭제 유무를 표시하는 컬럼을 추가해주자!

앞으로 이값이 1일 때에만 열람을 허용한다.

결과

똑같이 2번글에 대한 요청을 보내보았으나 이제는 열람이 불가능하다!

취약점

Web Application 의 download 관련 모듈의 파라미터에 path traversal 문자열을 삽입하여 웹 루트 디렉토리의 상위 경로에 위치하는 OS파일 시스템까지 접근할 수 있으며, 이를 이용해서 시스템의 각종 중요 파일 및 웹 프로그램의 소스 코드를 다운로드할 수 있음. 예를 들어, 파일 요청 URL에 ../를 넣어 특정 디렉토리의 파일을 다운로드할 수 있다.

따라서, 입력값 필터링을 해주자!!

실습

웹서버 : 리눅스/ 172.30.1.53:8080

http://172.30.1.53:8080/downloadAction?file=../../../../../etc/passwd

◾ 다음과 같이 파일명을 변조하여 요청하자, 다운이 된것을 확인 할 수 있다.

◾ 열어보니 웹서버의 /etc/passwd 파일을 다운한 것을 확인할 수 있다.

서버의 중요 파일이 파일명 수정만으로 다운로드 되었다!!

보안조치

보안조치로서 3가지 방법이 있다.

 1)파일 다운로드 모듈 구현시 파일 경로를 처리하는 파라미터 변수에서 디렉토리 상위 경로를 의미하는 path traversal 문자열을 필터링하여 사용할 수 없도록 함(Path Traversal 문자열 : [..], [../], [..\])

 2)실제 파일 경로는 DB에 저장하도록 하고 사용자에게 노출되는 URL의 파라미터에는 인덱스 번호를 통해 다운로드 할 파일을 표시함으로서 사용자에게 조작을 시도할 수 있는 경로 정보가 노출되지 않도록 구현함

 3)다운로드를 허용할 디렉토리를 지정하여 해당 디렉토리를 벗어나는 위치의 다운로드 요청에 대해서는 경고메시지와 함께 다운로드를 금지하도록 함

여기서 1번 방법을 적용하도록하겠다!

상위 경로를 의미하는 path traversal 문자열을 필터링해주자

◾ 다운로드를 수행하는 자바 파일에 다음과 같이 추가해주는데

이것은 입력값을 검사하여 상위 경로 문자가 포함되어있다면 해당 요청을 거부한다.

...

String blockchar[] = {"..", "../", "..\\"};
		 
		 
		boolean checkResult = true;
		
		for(int i=0; i<blockchar.length;i++) {
			if( fileName.indexOf(blockchar[i]) != -1 ) checkResult = false;
		}
		
		if(checkResult == false) {
			response.setContentType("text/html; charset=UTF-8"); 
			PrintWriter script = response.getWriter();
			script.println("<script>alert('올바르지 않은 요청입니다.');");
			script.println("history.back()"); //location.href='http://127.0.0.1:8080'
			script.println("</script>");
			script.close();

			return ;
		}
...

결과

◾ 필터링에 의해 요청이 거부된 것을 볼수있다!

취약점

웹 사이트는 DBMS와 연동하므로 웹 어플리케이션에서 사용자의 입력값을 통하여 데이터 트랜잭션이 발생함.

만일 사용자 입력값에 대한 유효성 검증이 누락될 경우,

악의적인 사용자는 정상적인 입력값 대신 SQL 쿼리문이 포함된 조작된 입력값을 전송하여 서버측 쿼리문의 구조를 변경할 수 있으며, 이를 통해서 사용자 인증을 우회하거나 데이터베이스의 정보를 유출시키고 서버의 시스템 명령어를 실행시킬 수도 있음.

실습

◾ 비밀번호를 다음과 같이 입력해준다

◾ 관리자로 로그인 성공!

공격원리

◾ 다음은 일반적으로 로그인을 처리하는 자바파일에 주요 SQL문장이다

"SELECT * FROM USER WHERE userID='아이디' AND userPassword='비밀번호' ";

아이디를 지목하고 해당하는 저장된 비밀번호와 입력값이 일치하는지를 검사한다

AND로 묶여있기때문에 만일 ID만 맞고 비밀번호를 틀리면 SQL은 False를 반환한다. 

◾ SQL인젝션 공격의 핵심은 SQL문이 무조건 참이 되게하는 것이며 따라서 입력값을 다음과 같이 바꾸어주면 그만이다

"SELECT * FROM USER WHERE userID='admin' AND userPassword='' or 1# '";

' or 1#을 추가해주므로써 AND에 뒷 구문을 참으로 만들어주었다.

#은 주석처리를 의미(마지막 '를 지워주기 위함) 

보안조치

보안조치 방법으로 다음 2가지가 있으며 여기서는 2번째 방법을 적용한다.

(1) 소스코드 레벨에서 필터링 코드를 통한 SQL Injection 방어

: ' 또는 #과 같은 SQL관련 문자를 필터링하여 악의적 입력값을 차단한다.

(2) 소스코드 레벨에서 Prepared Statement 구문을 통한 SQL Injection 방어

: Prepared Statement 구문은 SQL 쿼리를 선처리하여 컴파일 한 후, 이후 입력되는 변수값을 항상 문자열 변수로 다루기 때문에 사용자가 어떤 악의적인 SQL 구문을 변수에 삽입해도 SQL 문에 영향을 미치지 않아 SQL Injection이 발생하지 않는다. 

즉, 숫자나 or 또는 #과 같은 문자들이 갖는 의미가 사라지기 때문에 구문 조작을 미연에 방지한다.

public int login(String userID, String userPassword) {
    	String SQL = "SELECT userPassword FROM USER WHERE userID = ?";
        try {
            pstmt = conn.prepareStatement(SQL);
            pstmt.setString(1, userID);
            rs = pstmt.executeQuery();
            if(rs.next()){
                if(rs.getString(1).equals(userPassword))
                    return 1;  
                else
                    return 0; 
            }
            return -1; 
            
        } catch (Exception e) {
            e.printStackTrace();
        }
        return -2; 
    }

◾ 조치 결과

참조