[아이티데일리] 웹 해킹이 점점 증가하고 있는 요즘, 침입방지시스템, 웹 방화벽 등 웹 해킹을 차단하기 위한 보안장비들이 존재하지만, 보안 장비만으로 웹 해킹 공격을 방어하기는 사실상 불가능하다. 무엇보다 안전한 소스코드의 개발과 적절한 서버의 보안 설정이 이루어져야 웹 해킹에 대해 효과적으로 대응할 수 있다.

하지만, 대부분의 개발자나 서버 운영자들은 보안에 대한 지식들이 많지 않기 때문에 취약점의 존재 여부를 확인하는 방법을 모르거나 취약점의 존재를 알아도 어떻게 조치를 취하여야 하는지 모르는 경우가 많다.

앞으로 소개할 내용은 웹 해킹에 대응하기 위한 취약점 확인 방법과 이에 대한 대응 방법에 대하여 소개하고자 한다. 취약점을 확인하는 방법은 해킹에 악용될 수 있기 때문에 간단한 방법만 소개한다.

첫째, 운영체제 명령실행 취약점은 사용자가 웹 서버에 요청한 URI(Uniform Resource Identifier-인터넷 주소를 나타내주는 도메인인 URL뒤에 서버에게 값을 전달하기 위해 사용하는 변수명과 변수값을 모두 포함한 전체 경로를 의미)의 변수 값에 대하여 정상적인 입력 값 외에 추가적으로 시스템 명령어(e.g. ls, netstat, dump 등)를 삽입하여 요청하는 경우 웹 서버가 이 요청을 일반 변수 값으로 인식하여 시스템 명령어가 실행되어 웹상에서 해당 명령어의 결과 값을 출력하게 되는 취약점이다.

취약점이 존재할 경우 아래 그림과 같이 파일 목록이 노출되는 것을 확인할 수 있다.

이러한 공격은 입력 값 검증을 통해 대응을 하여야 하는데 클라이언트 사이드 스크립트인 자바스크립트를 이용할 경우 공격자는 이를 우회하여 공격할 수 있기 때문에 입력 값 검증은 반드시 서버 사이드 스크립트로 처리 하여야 한다.

윈도우에서 사용하는 명령어들인 dir, move, rmdir, ipconfig, format 등과 리눅스의 ls, mk, mv, rm, chmod, kill, ps, ifconfig, reboot 등이 있으며, 다중 명령어를 실행할 수 있는 구분자인 “|”, “;” 등도 필터링 하여야 한다.

둘째, 전통적으로 오랫동안 사용되어 왔던 SQL 인젝션 취약점이다. SQL 인젝션(Structured Query Language Injection)은 게시판을 호출하는 URI의 변수 값 등 전송되는 문자열에 대해 웹 서버에서 해당 값의 유효성을 검증하지 않아, SQL 쿼리(Query)가 데이터베이스 서버로 전송되어 실행되는 취약점이다. 공격자는 SQL 인젝션을 이용하여 로그인 인증우회, 홈페이지 변조, 내부자료 유출 등의 공격을 시도할 수 있다.

취약점 존재 여부를 간단하게 확인하는 방법은 정상 URI가 ‘http://도메인명/board/view.php?db=free&no=1’과 같은 경우 ‘http://도메인명/board/view.php?db=free&no=‘1’ 또는 ‘http://도메인명/board/view.php?db=free&no=1’과 같이 특수문자를 추가하여 0x80040E14와 같은 에러 메시지가 출력되는지 확인하는 것이다.

에러 코드가 포함된 에러 메시지가 발생한다는 것은 입력한 값이 데이터베이스 서버까지 전달되어 특수문자가 데이터베이스의 쿼리문에 영향을 미친다는 증거이기 때문에 SQL 인젝션에 취약하다고 볼 수 있다.

또한 정상적인 URI인 ‘http://도메인명/view.jsp?idx=1’ 부분에 참인 조건(http://도메인 명/view.jsp?idx=1 and 1=1--)과 거짓인 조건(http://도메인 명/view.jsp?idx=1 and 1=2--)을 입력하여 결과값이 다르게 나타나는지 여부를 확인한다. 결과값이 다르게 나타날 경우 역시 취약점이 존재한다고 볼 수 있다.

SQL 인젝션 취약점에 대한 대응 방안은 다음과 같다.

1) 데이터베이스와 연동하는데 사용되는 모든 입력 변수 값들을 점검하여 사용자의 입력 값에 SQL 쿼리문에 이용되는 특수문자(‘, “, /, , ;, :, %, Space, --, +, <, >, (, ), #, & 등)등이 포함되지 않도록 필터링 하여야 한다.

2) 특수문자 필터링뿐만 아니라 쿼리 스트링(Query String)에 대한 길이를 제한하고, 데이터베이스와 연동하는 스크립트의 모든 변수들을 점검하여 사용자의 입력 값에 SQL 쿼리문이 허용되지 않는 문자열(@variable, @@variable, print, set, or, union, and, insert, openrowset 등)을 필터링 한다.

3) 데이터베이스의 에러 메시지는 사용자에게 불필요한 정보를 제공하여 누출된 정보를 이용하여 추가 공격 시도를 할 수 있다. 그렇기 때문에 에러 메시지는 사용자에게 보여주지 않도록 하여야 한다.

4) 웹 애플리케이션이 사용하는 데이터베이스의 사용자 권한은 제한하는 것이 좋다.

5) MS-SQL의 경우는 master..xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask와 같은 확장 프로시저는 운영체제 명령 실행, SQL 인젝션 등에 이용되기 때문에 제거하는 것이 안전하다.

6) 선처리 구문(Prepared Statement)을 통해 방어할 수 있는데 이는 SQL 쿼리문을 선 처리하여 컴파일하면, 이후 입력되는 변수 값을 항상 문자열 변수로 다루기 때문에 사용자가 어떤 악의적인 SQL 구문을 변수 값에 삽입하더라도 SQL 문에 영향을 미치지 않아 SQL 인젝션이 발생하지 않는다.