관리 메뉴

엉망진창

최신 웹 애플리케이션 해킹 기법과 대응 방법 - 출처 : DBguide.net 본문

Study_DB/DB_MSSQL

최신 웹 애플리케이션 해킹 기법과 대응 방법 - 출처 : DBguide.net

엉망진창 2008. 3. 21. 13:59
네트워크 보안의 현실 그리고 해법찾기 Network Security


게임 업체의 명의 도용 사건으로 인해 보안 담당자들 뿐 아니라 일반인들도 보안에 대한 관심이 높아지고 있다. 한 보안 업체의 테스트 결과에 따르면 운영체제를 설치한 뒤 패치를 하지 않으면, 15분 내에 해킹에 노출된다고 한다. 국내 해커 뿐 아니라 최근 물밀 듯 밀려오는 중국 발 해킹, 네트워크를 놀이터 삼아 기하급수적으로 숫자를 늘리며 기생하는 웜까지 우리의 생활은 온통 해킹의 위험 투성이다.
이번 호에서는 네트워크 장비 및 운영체제별 취약점과 그 해결방법, 최근 유행하고 있는 해킹 패턴과 그에 대한 대처법 등에 대해 자세히 알아본다.


특집 1부 해킹과 보안의 소리 없는 전쟁 | 임채호
특집 2부 네트워크 취약점 분석과 대응방안 | 박종수
특집 3부 윈도우 시스템의 취약점과 방어법 | 정관진
특집 4부 웹 애플리케이션 해킹 기법과 대응 방법 | 김기흥
특집 5부 보안의 새로운 시작 모바일 | 김기흥

최신 웹 애플리케이션 해킹 기법과 대응 방법



김기흥|(주)세인트 시큐리티의 대표이사 (네트워크 보안)


최근 들어 중국발 한국의 웹 해킹이 폭증하고 있는 가운데 단순히 웹 애플리케이션의 제작 및 구현이 직접적인 서버 운영의 보안 문제까지 포함하게 되어 최근 많은 문제가 되고 있다.
이번 호에서는 이러한 최신 웹 해킹 기법을 분석하고 이에 대한 보안 대책을 함께 제시함으로써 웹 서버 관리자 및 웹 애플리케이션 개발자들이 최신 웹 해킹 기법을 이해하고 이에 효과적으로 대응 할 수 있는 방법을 모색해본다.


최근 많은 기업들이 대 고객 업무를 웹 기반으로 운영하고 있고 국가도 행정 서비스를 웹 기반으로 전환함에 따라 안전한 웹 서버 운영이 아주 중요한 이슈로 부각되고 있다. 이제 웹 서버는 회사 홍보나 정보를 제공하는 단순한 기능에서 벗어나 다양한 사회적 기능의 기반 시스템으로 자리 잡게 되었다. 사람들은 각자 자신의 집이나 회사에서 웹을 통해 증권·금융 업무를 볼 수도 있고, 항공·호텔 예약이나 쇼핑, 정부 행정 서비스 등의 업무도 처리할 수 있다. 사회 활동이 일어나는 장소가 물리적 공간에서 웹으로 이동하고 있는 것이다.
이렇게 웹에 대한 관심이 증대되고 있는 가운데 최근 중국발을 비롯하여 각종 웹 해킹 사고가 자주 발생하고 있어 웹 서버 보안의 중요성이 강조되고 있다. 최근 웹 서버 해킹 사고가 언론에 자주 보도되고 있는데 그 원인은 웹 서버가 사회적으로 중요한 기능을 담당하게 됨에 따라 웹 서버에 대한 해커들의 관심도 부쩍 늘었기 때문이라고 볼 수 있다. 또한 웹 서버는 다른 시스템에 비해 해킹이 비교적 쉽고 해킹의 효과가 높기 때문에 초보 해커들도 손쉽게 해킹할 수 있다는 것도 중요한 원인으로 작용하고 있다.
웹 서비스는 기능의 특성상 다른 서비스와는 달리 반드시 외부에 노출되어 있어야 하고 방화벽의 보호를 받기 어렵다. 그리고 다양한 애플리케이션들이 웹 서비스와 연동되어 있어 많은 보안 취약점들이 존재한다. 특히 새로운 웹 기술이 계속 개발되면서 전에는 없었던 새로운 형태의 보안 취약점들이 꾸준히 생겨나고 있다. 또한 제품의 질보다는 단순히 결과 중심의(특정 내용을 보여주기만 하면 된다는 식의) 웹 애플리케이션 개발이 대부분이다 보니 보안적인 문제는 시간이 갈수록 점점 더 커지고 있는 것이다.
웹 사이트는 방송 매체와 같이 대중에 대한 정보 전달력이 있어서 다른 해킹 방법에 비해 해킹 효과가 크다. 또한 대부분의 경우 해당 웹 사이트를 이용하는 고객 정보를 웹 사이트 자체에서 직접적으로 관리 및 운영하고 있기 때문에 해킹을 당했을 경우 그 피해는 측정이 불가능할 정도로 커진다.
이제부터 날이 갈수록 지능화되는 웹 애플리케이션 해킹의 기법들에 대해 알아보고 그에 대한 대응법을 함께 연구해보자.

<그림1> 최근 웹 해킹 사고 발생 건수 변화 추이


웹 해킹 사고 발생 현황


<그림 1>은 최근 웹 해킹 사고 발생 건수를 그래프로 표현한 것이다. 일단 그래프를 먼저 살펴보고 이야기를 계속하자.
그래프를 살펴보면 2005년 상반기에 웹 해킹 사고 건수가 많았던 것에 비해 시간이 지나면서 상당히 줄어드는 것을 알 수 있는데 이는 지속적인 보안 솔루션 도입 및 기업의 보안 의식 고취 등을 원인으로 들 수 있다. 하지만 2006년에 들어서면서 해킹 사고 발생 건수가 갑자기 늘어난다. 이런 현상은 중국발 한국 웹 해킹이 본격화되었고 각종 자동화 해킹 툴들이 중국 포털 사이트 등을 통해 배포된 것에서 그 원인을 찾을 수 있다.
이 통계자료의 성분을 분석해본다면 크게 4~5가지 정도의 공격 기법으로 압축할 수 있는데 기본 웹 서버 설정 및 운영의 문제, SQL Injection 공격, XSS(크로스 사이트 스크립팅) 공격, 각종 악성코드 혹은 웜, 자동화되어 있는 툴들에 의한 공격으로 나눌 수 있다.
<화면 1>는 외국에 공개되어서 운영되고 있는 해킹 침해 사고를 당한(웹 해킹 포함) 사이트 목록을 모아둔 사이트이다. 여기에서 ‘kr’로 한국 사이트를 검색해보면 엄청나게 많은 사이트 목록이 표시된다. 내용을 보면 알 수 있듯이 하루에도 몇 건씩 한국 사이트가 외국의 해커들로부터 해킹을 당하는 셈이다.

<화면1> 외국 사이트에 공개된 한국 웹 사이트 해킹 목록

<화면 1>는 외국에 공개되어서 운영되고 있는 해킹 침해 사고를 당한(웹 해킹 포함) 사이트 목록을 모아둔 사이트이다. 여기에서 ‘kr’로 한국 사이트를 검색해보면 엄청나게 많은 사이트 목록이 표시된다. 내용을 보면 알 수 있듯이 하루에도 몇 건씩 한국 사이트가 외국의 해커들로부터 해킹을 당하는 셈이다.


최신 해킹 기법 분석 및 보안 대책


<화면 1>에서 볼 수 있듯이 해킹은 유명무명 사이트를 가리지 않고 진행되며 운영체제 역시 가리지 않는다. 문제는 그뿐이 아니다. 아마 리스트에 나타난 사이트를 운영하는 회사 중 대부분은 자신들이 해킹을 당했고, 지금도 계속 해킹을 당하고 있다는 사실조차 인지하지 못하고 있을 것이라는 점이다. 멀쩡한 외양간을 고치는 것은 시간과 비용의 낭비처럼 느껴질지 모르지만, 소를 잃는 것보다는 나은 일이다. 이제부터는 해커들이 그렇게 많은 사이트를 제 집 드나들 듯이 드나들며 유린하는 데 사용하는 해킹 기법과 그에 대한 보안 대책을 통해 우리가 관리하는 외양간을 더욱 튼튼하게 하는 법을 연구해보자.

그만큼 윈도우 운영체제가 외부에 많이 노출되어 있고 공격자들의 대상이 되기도 쉽다는 뜻이다. 물론, 이것은 보는 관점에 따라 달라질 수 있지만 공격대상의 관점에서만 본다면 매력 있는 것임은 분명하다. 악성코드의 관점에서 예를 들어 보자. 악성코드 확산을 효과적으로 막는 방법은 무엇일까? 많이 사용되고 있는 운영체제 또는 응용프로그램을 이용하는 것이 보다 효과적일 것이다. 이러한 이유로 유닉스 시스템의 악성코드보다는 윈도우 환경의 악성코드가 많이 발견되는 것이다.


파일 업로드

파일 업로드(File Upload) 공격은 공격자가 공격 프로그램을 해당 시스템에 업로드하여 공격하는 방법을 말한다. 파일 업로드는 공격이 쉬우면서도 영향력이나 파급 효과는 큰 공격 방법이다. 공격 방식은 공격자가 시스템 내부 명령을 실행할 수 있는 웹 프로그램(ASP, JSP, PHP)을 제작하여 자료실과 같이 파일을 업로드할 수 있는 곳에 공격용 프로그램을 업로드하는 것이다. 그리고 웹 브라우저를 이용해 공격용 프로그램에 접근하면 시스템 내부 명령을 실행시킬 수 있게 되는데, 이를 이용해 공격자는 리버스 텔넷(Reverse Telnet)과 같은 기법으로 자신의 컴퓨터로 피해 대상 시스템의 명령 창을 띄워 편하게 작업할 수도 있다. 쉽게 말해, 원격지에서 공격한 컴퓨터의 전권을 가지게 되는 것이다.
그렇다면 이러한 파일 업로드 공격에 어떻게 대응해야 할까? 가장 간단하고 효과적인 방법으로는 업로드할 때 파일 확장자 이름을 확인하는 것이다. 이때 asp나 jsp같이 업로드되는 확장자를 소문자만 체크하지 않도록 주의해야 한다. 시스템은 aSp나 jSp 같은 대소문자 혼합도 인식하기 때문에 모든 가능한 조합에 대해 필터링해야 한다. 반대로 특정 확장자 이름을 가진 파일만 업로드되도록 하는 것도 좋은 방법이다. 이때 또 한 가지 주의할 점은 필터링을 위해 자바스크립트 같은 클라이언트 스크립트 언어를 사용하지 말아야 한다는 점이다. 어느 정도 숙달된 해커라면 클라이언트 스크립트 언어쯤은 얼마든지 수정할 수 있기 때문에 asp나 jsp 같은 서버 쪽 스크립트 언어에서 필터링해야 한다.
필터링 이외에 파일이 업로드되는 디렉토리의 실행 권한을 없애는 방법이 있다. 이 경우에는 파일이 업로드되더라도 실행되지 않기 때문에 브라우저에 그대로 나타나거나 파일을 다운로드하게 된다.


디렉토리 탐색

디렉토리 탐색(Directory Traversal)은 웹 브라우저에서 확인 가능한 경로의 상위로 올라가서 특정 시스템 파일을 다운로드하는 공격 방법이다. 자료실에 올라간 파일을 다운로드할 때 전용 다운로드 프로그램이 파일을 가져오는데 이때 파일 이름을 필터링하지 않아서 생기는 취약점이다. 특정 파일을 다운로드할 때 다음과 같은 URL을 이용하여 다운로드한다고 하자.

http://www.stsc.co.kr/board/down.jsp?filename=saintsecurity.doc

공격자는 filename 변수에 해당하는 값을 다음과 같이 간단한 조작을 통해 상위 디렉토리로 거슬러 올라가 /etc/passwd 파일을 다운로드할 수 있다.

http://www.stscco.kr/board/down.jsp?filename=../../../../../../../ ../../../../etc/passwd

전용 파일 다운로드 프로그램을 이용할 때는 위의 예에서 보는 바와 같이 ‘..’ 문자열이나 ‘/’ 문자열에 대한 필터링이 없을 경우, 공격자는 상위로 올라가 특정 파일을 열어볼 수 있기 때문에 ‘..’와 ‘/’ 문자를 필터링해야 한다. 파일 업로드의 경우와 마찬가지로 자바스크립트와 같은 클라이언트 스크립트 언어로 필터링하면 공격자가 우회할 수 있기 때문에 반드시 jsp나 asp 등 서버 쪽 스크립트 언어에 필터링을 추가해야 한다.


디렉토리 리스팅

디렉토리 리스팅(Directory Listing)은 웹 브라우저에서 웹 서버의 특정 디렉토리를 열면 그 디렉토리에 있는 모든 파일과 디렉토리 목록이 나열되는 것을 말한다. 이것이 디렉토리 리스팅의 취약점이다. 물론 관리자가 어떤 목적을 위해서 웹 서버의 특정 디렉토리를 리스팅할 수 있도록 설정하기도 하지만, 어쨌든 공격자는 디렉토리 리스팅 취약점을 이용하여 웹 서버에 어떤 파일이 있는지 확인할 수 있고 추가적인 공격 취약점을 찾을 수 있다. 대부분의 웹 서버의 경우 해당 디렉토리 리스팅에 대한 여부를 가능 혹은 불가능하게 하는 옵션이 따로 준비되어 있다. 해당 설정 내용을 적절하게 변경하주면 디렉토리 리스팅을 이용한 공격은 통하지 않는다.


인증 우회

인증 우회란 관리자 페이지나 인증이 필요한 페이지에 대한 인증을 처리하지 않고 인증을 우회하여 접속할 수 있는 취약점을 말한다. 이 취약점에 노출되면 일반 사용자나 로그인하지 않은 사용자가 관리자 페이지에 접근하여 관리자 권한을 획득한 뒤에 모든 기능을 자신이 원하는 대로 악용할 수 있게 된다. 이런 취약점은 간단하지만 의외로 웹 개발자가 자주 범하는 실수이다. 인증 우회는 아주 간단한 방법으로 공격이 이루어진다. 일반적으로 관리자로 로그인한 뒤 관리자가 이용하는 웹 페이지에 접속해야 하는데 로그인하지 않고 직접적으로 관리자만이 이용할 수 있는 웹 페이지에서 특정 작업을 수행할 수 있도록 만들기 때문이다. 예를 들면 www.stsc.co.kr/admin/login.asp를 통해 관리자로 로그인한 뒤 www.stsc.co.kr/admin/data.asp에 접근할 수 있어야 하는데, 관리자로 로그인하지 않고도 www. stsc.co.kr/admin/data.asp에 바로 접근하여 관리할 수 있는 경우를 말한다.
관리자 페이지나 인증이 필요한 페이지에 대해서는 관리자 로그인 세션에 대한 검사를 수행하는 과정을 넣어야만 이러한 공격의 피해를 막을 수 있다. 따지고 보면 웹 공격의 다수는 관리자의 부주의나 관리 패턴을 악용하는 단순한 방법이다. 이런 약점을 노출시키지 않으려면 관리자는 자신이 좀 더 불편하더라도 안전한 방법을 이용해 사이트나 파일을 관리해야 한다.


SQL Injection 공격

SQL Injection 공격은 세상에 공개된 지 약 4년이 넘었지만 아직도 수많은 사이트가 이 공격에 취약한 묘한 해킹 방법이다. 이런 일이 가능한 것은 많은 개발자들이 이 부분을 간과한 채 웹 애플리케이션을 개발하고 있기 때문이다. 먼저 SQL Injection 공격의 패턴에 대해 알아본 뒤에 그 대응 방법을 함께 살펴보자.


■ 기본 SQL Injection 공격 패턴
웹 애플리케이션에서 사용자에게서 SQL문을 입력받는 부분, 즉 데이터베이스와 연동되는 부분은 크게 로그인, 검색, 게시판으로 나눌 수 있다. 어느 사이트에서든 로그인을 하려면 아이디와 비밀번호를 넣어야 한다. 그리고 웹 애플리케이션 개발자는 정상적인 아이디와 비밀번호로 넣을 것을 기대하고 프로그래밍 한다. 그러나 모든 공격은 언제나 예상치 않은 곳에서 일어난다. 공격자는 아이디와 비밀번호를 정상적인 문자가 아닌 특정 SQL문을 넣어 공격한다. 이렇게 아이디나 비밀번호 부분에 엉뚱한 SQL문이 삽입되면 그것이 그대로 데이터베이스에 전송되어 공격자가 원하는 일이 일어난다.
SQL Injection 공격은 고난도 기술이 아니다. 물론 아주 어려운 SQL Injection 공격도 있지만 1분 만에 쉽게 배울 수 있는 SQL Injection 공격 방법도 있다. 그러면 SQL Injection 공격에 대응하기 위해서 무엇이 필요한지 살펴보자.
로그인 부분에 대한 SQL Injection 공격에 대한 이해를 돕기 위해서 로그인을 처리하는 간략한 웹 프로그래밍 코드를 살펴보자. 다음 코드는 로그인할 때 로그인 아이디와 비밀번호를 검사하여 사용자를 식별하는 ASP 코드의 한 부분이다.
일반 사용자가 웹에 접근하여 아이디와 비밀번호를 입력하면 위의 코드에 아이디와 비밀번호가 입력된다. 위의 코드는 사용자가 입력한 아이디를 strUser_id 변수에 저장하고 사용자가 입력한 비밀번호를 strPassword 변수에 넣는다. 그 뒤에 SELECT 문에서 사용자의 아이디와 비밀번호 입력에 대한 결과를 Query 변수에 저장한다. 그런 다음 GetQueryResult 함수를 이용해 Query 변수에 들어 있는 SQL문을 실행하고 그 결과를 strAuthCheck 변수에 넣는다. 쿼리 결과가 존재하지 않으면 strAuthCheck의 결과 값은 NULL이 되어 boolAuthenticated는 ‘거짓’이 되고 실행 결과 값이 있으면 boolAuthenticated는 ‘참’이 되어서 로그인 인증을 받을 수 있다.
이때 공격자가 아이디와 비밀번호에 ‘ or ‘’=’ 방식으로 입력하면 다음과 같은 결과가 나타난다.


<화면2> 자동화되어 있는 SQL Injection 공격 툴


<화면3> SQL Injection 공격 툴로 가입자 정보를 유츌한 화면


아이디: ‘ or ‘’=’
비밀번호: ‘ or ‘’=’

    ↓

SELECT user_id FROM member WHERE
user_id = ‘’ or ‘’ = ‘’ AND password = ‘’ or ‘’ = ‘’

이와 같은 쿼리문이 만들어지면서 조건문(Where문)은 항상 만족하고, strAuthCheck 값도 항상 ‘참’이 되기 때문에 공격자는 사용자 인증에 성공한다. 이처럼 위의 기법을 이용하면 아주 간단하게 로그인 창의 로그인을 우회하게 된다.
여기에서 설명한 SQL Injection 공격은 아주 기초적인 SQL Injection 공격 개념이라고 할 수 있는데 실제로 이와 같은 SQL Injection 공격을 자동화해놓은 툴들이 많이 있다. 이러한 툴을 이용하면 해당 공격 대상 서버의 시스템 명령까지 내릴 수 있으며 실제 데이터들의 조회와 수정도 가능하게 되어 심각한 문제를 야기할 수 있는 것이다.


■ SQL Injection 공격에 대한 대응 방법
SQL Injection에 대한 가장 훌륭한 해결책은 포괄적인 입력 검증을 수행하는 것이다. 모든 스크립트에 존재하는 모든 변수들을 점검하여 사용자의 입력 값이 SQL Injection을 발생하지 않도록 수정한다. 웹 애플리케이션 코드를 수정하여 사용자 입력이 SQL 문장으로 사용되지 않도록 한다. 모든 사용자 입력의 앞뒤에 따옴표를 붙이고, 사용자 입력에 존재하는 따옴표가 제거되도록 설정한다. 따옴표를 제거하는 것보다 더 확실한 방법은 사용자 입력에 따옴표가 존재하는 경우 이를 에러 처리하도록 하는 것이다. 만약 따옴표가 제거된 사용자 입력을 계속 처리하도록 허용한다면 이를 우회하는 공격에 언제나 노출되어 있는 셈이다.
따옴표에 대한 검증을 수행한 다음에는 사용자 입력으로 사용이 불가능한 스트링을 제거하고, 사용 가능한 문자집합에 포함되지 않은 모든 문자들을 제거하도록 설정한다. 이 경우에도 마찬가지로 허용되지 않은 문자열이나 허용되지 않은 문자가 포함된 경우를 에러로 처리하는 것이 더욱 안전하다.
현재 알려져 있는 공격 패턴을 기반으로 해서 사용자 입력으로 사용이 불가능한 스트링을 결정한다. 또한 새로운 공격 기술에 대비해서 사용자 입력으로 사용 가능한 최소의 문자집합을 결정한다. 사용이 허용된 문자들의 조합으로 공격 스트링을 만들 수 있기 때문에 이 두 가지 방법을 동시에 사용해야 한다. 최소 사용 가능 문자집합에는 가급적 숫자만을 포함하도록 하고 그것이 어렵다면 숫자와 문자만을 포함하도록 해야 한다. 만약 사용자 입력으로 기호문자나 구두문자 같은 문자들을 사용해야 한다면 꼭 필요한 최소의 문자만을 포함하고 허용된 문자를 HTML 문자로 변환해서 처리하도록 한다.
공격자는 리턴되는 에러 메시지에 대한 역공학 분석을 통하여 공격에 성공할 수 있는 SQL Injection 스트링을 알아낸다. 따라서 SQL 서버의 에러 메시지를 외부에 제공하지 않도록 한다. 보통 개발 과정에서 디버깅을 목적으로 에러가 리턴되도록 허용했다가 개발이 끝난 후 그 기능을 제거하는 것을 잊는 경우가 많다. 에러가 발생한 경우 에러 발생 사실을 보여주기보다 메인 페이지로 돌아가도록 하는 것이 좋다. 500 Internal Server Error Page 자체가 그 서버에 대해 SQL Injection 공격이 가능하다는 의미를 제공하는 것이다.
웹 애플리케이션이 사용하는 데이터베이스 유저의 권한을 제한시킨다. 가능하면 일반 유저 권한으로는 모든 system stored procedures에 접근하지 못하도록 한다. 이렇게 하며 웹 애플리케이션의 SQL Injection 취약점을 이용하여 데이터베이스 전체에 대한 제어권을 얻거나 데이터베이스를 운용 중인 서버에 대한 접근이 불가능하도록 한다. 이외에도 데이터베이스에 대한 보안 지침 문서를 참조하여 데이터베이스 서버의 보안 수준을 제고하도록 한다.


SQL Injection 공격 대응 방법

◆ 사용자 입력이 SQL Injection을 발생시키지 않도록 사용자 입력을 필터링한다.
◆ SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정한다.
◆ 웹 애플리케이션이 사용하는 데이터베이스 유저의 권한을 제한시킨다.
◆ 데이터베이스 서버에 대한 보안 설정을 수행한다.


크로스 사이트 스크립팅(XSS) 공격


버퍼 오버플로우는 공격기법의 이름에서도 어느 정도 유추할 수 있듯이 지정된 범위의 버퍼이상의 데이터를 기록할 때 발생된다. 현재 발생하고 있는 취약점 중에 많은 것들이 이 버퍼 오버플로우에 의해 일어나고 있다. 이것은 개발 시 지정된 범위 이상의 값으로 받아들이지 않도록 코딩을 하거나 안전한 함수 등을 사용하여 막을 수 있는 부분임에도 불구하고 여전히 그 피해가 끊이지 않는 대표적인 취약점 중 하나이다. 구글과 같은 검색엔진에서 ‘buffer overflow’로 검색해 보면 상당히 많은 자료를 찾아 볼 수 있다.
간단한 입력을 받는 다음의 코드를 살펴보자. array[30]으로 버퍼의 크기를 지정하였고 받은 내용을 출력하도록 프로그래밍되어 있다. 그런데 만약 사용자가 버퍼 크기 이상의 데이터를 입력하였다면 어떻게 될까? <화면 1>과 같은 화면이 나타날 것이다. * A는 16진수로 41이다.


기본적인 공격 기법 분석

공격자는 XSS 취약점이 존재하는 웹 사이트에 자신이 만든 악의적인 스크립트를 일반 사용자의 컴퓨터에 전달하여 실행시킬 수 있다. 이러한 공격으로 사용자 쿠키를 훔쳐서 해당 사용자 권한으로 로그인하거나 브라우저를 제어하는 것이다.
XSS 취약점은 다음과 같이 동적으로 웹 페이지를 생성하는 사이트에 주로 존재한다.

● 입력한 검색어를 다시 보여주는 검색엔진
● 입력한 스트링을 함께 보여주는 에러 페이지
● 입력한 값을 사용자에게 다시 돌려주는 Form
● 사용자에게 메시지 포스팅이 허용된 웹보드

XSS 취약점이 존재하는 사이트의 특징은 사용자의 입력을 검증하지 않고 그대로 동적으로 생성되는 웹 페이지에 포함해서 다시 보여준다는 점이다. XSS 공격은 <그림 3>과 같이 이루어진다. 공격자는 XSS 취약점이 존재하는 웹 페이지의 사용자 입력으로 ‘test’와 같이 정상적인 스트링을 입력하는 것이 아니라 <script>로 시작하는 악성 스크립트 코드를 입력한다. 그러면 웹 서버는 공격자가 입력한 악성 스크립트 코드가 포함된 웹 페이지를 생성해서 클라이언트에게 되돌려준다. 이 웹 페이지에 포함된 스크립트 코드는 클라이언트 측 브라우저에서 실행된다.
공격자는 웹 메일이나 게시판 등을 이용하여 리턴되는 웹 페이지를 공격 목표가 되는 일반 사용자에게 전달한다. 공격자는 웹 메일에 악성 스크립트 코드를 포함하여 전달하거나 게시판에 악성 스크립트 코드가 포함된 웹 페이지를 생성해서 클라이언트에게 되돌려준다. 이 웹 페이지에 포함된 스크립트 코드는 클라이언트 측 브라우저에서 실행된다.
공격자는 웹 메일이나 게시판 등을 이용하여 리턴되는 웹 페이지를 공격 목표가 되는 일반 사용자에게 전달한다. 공격자는 웹 메일에 악성 스크립트 코드를 포함하여 전달하거나 게시판에 악성 스크립트 코드가 포함된 글을 포스팅한 뒤에 그 글을 읽도록 한다. 일반 사용자가 공격자로부터 수신한 웹 메일을 여는 순간 혹은 공격자가 포스팅한 게시물을 읽는 순간이나 해당 웹 페이지에 읽는 순간 해당 웹 페이지에 포함된 스크립트 코드가 실행된다.
이러한 방법 외에도 악성 스크립트를 URL에 포함시켜서 전달하는 방법도 있다. 공격자는 URL의 변수 값으로 악성 스크립트를 넣은 링크를 공격 대상자에게 전달하여 그 링크를 클릭하도록 유도한다. 공격자는 이 링크를 공격 대상자에게 친숙한 내용의 HTML 메일에 포함시켜 전달하는데 메일은 공격 대상자가 반드시 그 링크를 클릭하도록 내용을 구성한다. 공격 대상자가 그 링크를 클릭함과 동시에 악성 스크립트가 포함된 웹 페이지를 수신하게 된다.

XSS 공격에 대한 대응 방법

XSS 취약점은 대부분 웹 애플리케이션 개발자가 사용자 입력을 받아들이는 부분에서 사용자 입력에 대해 어떠한 검증도 하지 않았기 때문에 일어난다. 그럼 웹 애플리케이션 개발자나 사이트 관리자는 어떤 방식으로 XSS 취약점에 대응해야 할까?

- 사용자를 식별하기 위해서 쿠키에 비밀번호와 같은 민감한 정보는 담지 않아야 한다.

- 스크립트 코드에 사용되는 특수문자에 대해 이해하고 정확한 필터링을 해야 한다. 가장 효과적인 방법은 사용자가 입력 가능한 문자(예를 들면 알파벳, 숫자, 몇몇의 특수문자)만을 정해놓고 그 문자열이 아니면 모두 필터링한다. 이 방법은 추가적인 XSS 취약점에 사용되는 특수문자를 사전에 예방할 수 있다는 장점이 있다.
<표 1> 같은 특수문자 필터링을 적용하기 위해서는 다음과 같은 함수를 이용할 수 있다.

정당화

의미

<
태그의 시작
>
태그의 끝
&
캐릭터 개체 또는 매개변수의 구별자
"
속성 값
'
속성 값
space

tab
속성 값, URL의 끝

URL의 끝
new line
URL의 끝
Non-ASCII
Iso-8859-1일 때, 2바이트 코드
%
HTTP escape sequence
" 안의!
Server Side Script
<script></script> 안의, (), {}, New Line
 

Function RemoveBad(InStr) {
InStr = InStr.replace(/\</g,“”);
InStr = InStr.replace(/\>/g,“”);
InStr = InStr.replace(/\”/g,“”);
InStr = InStr.replace(/\’/g,“”);
InStr = InStr.replace(/\%/g,“”);
InStr = InStr.replace(/\/g,“”);
InStr = InStr.replace(/\(/g,“”);
InStr = InStr.replace(/\)/g,“”);
InStr = InStr.replace(/\&/g,“”);
InStr = InStr.replace(/\+/g,“”);
Return InStr;
}

- 게시판에서 HTML 포맷의 입력은 사용할 수 없도록 설정한다. 최근에 만들어진 게시판들은 대부분 사용자들에게 다양한 효과를 제공하기 위해 HTML Tag 기능을 제공하고 있지만 꼭 필요한 경우가 아니라면 HTML을 사용할 수 없도록 제한해야 한다.

- 스크립트를 대체하여 무효화한다. javascript라고 들어오는 문자열은 무조건 x-javascript와 같이 대체하여 스크립트 실행을 무효화시키는 방법도 있다.


지금까지 살펴본 바와 같이 웹 해킹의 대부분은 웹 설정의 문제나 기본적으로 웹 환경에서 작동하는 웹 애플리케이션 제작 시 보안적인 요소를 고려하지 않고 단순히 목표로 하는 결과만 나올 수 있는 결과 중심의 프로그램 제작이 가져온 결과라고 할 수 있겠다. 더욱이 요즘처럼 웹이라는 환경에서 다루고 있는 각종 정보들이 직·간접적으로 악용되어 2차, 3차까지 이어지는 추가 해킹 사건까지 일어나고 있는 실정인데 웹 개발자들은 이제 단순히 결과만 보여주기 위한 프로그래밍보다는 그 내용 및 프로그램의 퀄리티까지 확보할 수 있는 단계가 될 수 있도록 주의해야 한다.
여기에서 다룬 해킹은 웹 사이트가 크고 웹 애플리케이션이 많을수록 더욱 쉽게 노출된다. 모든 애플리케이션에 여기에서 설명한 내용들을 적용하거나 코드를 수정하는 것이 너무 번거롭고 어렵다면 시중에 나와 있는 웹 애플리케이션 방화벽을 도입하는 것도 좋은 방안이 될 수 있을 것이다. 하지만 자신의 환경에 얼마나 잘 맞는지, 그리고 단순히 불필요한 기능들 때문에 전체 웹 시스템에 영향을 주는 솔루션을 도입을 하는 것은 벼룩 잡기 위해서 초가삼간을 모두 태운 격이 되므로 주의해야 한다.
가장 좋은 보안은 처음 애플리케이션을 개발하는 단계에서 보안에 신경을 쓰는 것이다. 약간만 신경 써서 개발한다면 수많은 개발자가 ‘각종 웹 해킹 보안 위협’에 골머리 썩으며 밤을 새는 일은 없을 것이다.


XSS 취약점에 대해 일반 사용자들이 주의할 점

XSS 취약점은 서버뿐만 아니라 해당 웹 사이트를 이용하는 일반 사용자에게도 문제를 일으킬 수 있는 소지가 있다. 다음 내용들을 숙지하여 XSS 취약점으로 인한 피해를 입지 않도록 대비하자.

◆ 우선 E-Mail이나 링크가 있으면 링크를 바로 클릭하여 이동하지 말고 직접 URL에 주소를 입력하여 사이트를 방문하는 방법이 있다. 이 방법은 어떻게 보면 상당히 불편할 수 있는데 URL 스푸핑이나 XSS 공격에 대응하는 좋은 방법 중 하나이다.

◆ 인터넷 익스플로러의 최신 패치를 적용하여 인터넷 익스플로러 자체의 취약점으로 인한 공격에 미리 대응해야 한다.

◆ 웹 브라우저의 인터넷 옵션에서 개인 정보 등급을 상향 조절하여 불필요한 쿠키 값을 전송하지 않는 방법도 있다. 보안 설정을 가장 높게 설정하면 쿠키 값이 필요한 사이트에서 서비스를 사용하기 힘든 경우가 있기 때문에 보안 설정을 최상위로 높이는 것은 권장하지 않는다.


전직 해커가 SME 보안 담당자들에게

유명 해커 출신 게임업체의 보안 담당자 | 서승현 씨

누구나 자신의 재능이나 삶을 위해 올바른 방향을 찾고자 하지만, 인간의 삶이란 그리 쉽게 좋은 길을 보여 주지 않는다. 그런 면에서 서승현 씨(28세)는 운이 참 좋은 편인 듯하다. 이제 막 사회에 첫발을 내딛을 나이의 그는 유명한 전직 해커이자 보안 전문가로 자리매김한 지 이미 오래다. 그에게 이러한 길을 안내해준 사람은 대학 시절 OS 커널에 정통했던 교수님이었다. OS의 중요성을 강조하던 교수님의 가르침에 따라 커널 등 해당 분야를 다양하게 파고들었던 그는 점점 해킹에 눈을 뜨기 시작했다. 여러 해킹 자료를 모으고 번역하고 연구하다 보니 익힌 기술을 써보고 싶은 생각이 머릿속에 또아리 틀기 시작했다. 그렇다고 범죄를 저지를 수는 없는 일이기에 그가 선택한 일은 학교 연구실에 가상 시스템을 만들어두고 모의실험을 통해 각종 이론들을 확인해보는 것이었다. 다양한 이론으로 무장하고 실제로 테스트를 해보면서 실력을 쌓아가다 보니 학교에서 발생하는 여러 가지 보안 관련 문제들에 단골 해결사 노릇을 하기도 했다. 시간이 지날수록 보안과 해킹의 심각성을 절감하기 시작한 그는 화이트 햇(컴퓨터 시스템이나 네트워크에서 보안상 취약점을 찾아내 다른 해커들에게 공격 받기 전에 원조할 목적으로 그 취약점을 노출시켜 알리는 해커) 해커 철학을 떠올렸다. 자신이 연구한 취약점을 공유하기 위해 khdp라는 해킹 및 보안 기술 사이트를 오픈했다. 이때, 사이트에 올린 4세대 해킹 기법인 ‘format string attack’의 연구 자료가 폭발적인 인기를 끄는가 싶더니, 급기야 2000년 12월 스물두 살의 나이로 한국정보보호진흥센터(현 한국정보보호진흥원)에서 주관하는 제4회 해킹 방지 워크샵에서 강연을 하기에 이르렀다. 이후 각종 해킹 대회를 휩쓸며 보안업계와 인연을 맺어온 그는 이제 어엿한 보안 전문가로서의 길을 걷고 있다. 해커와 보안 전문가의 두 길을 모두 경험한 서승현 씨가 중소기업의 보안 담당자들에게 전하는 메시지를 들어보자.

웹 개시 10분이면 침투 당하고 마는 웹 사이트가 태반
최근에는 중소기업이라 하더라도 사내 시스템이나 많은 서비스를 웹 기반으로 제공하고 있다. 하지만 대기업이나 해킹의 심각한 피해를 입은 적이 없는 중소기업의 경우 이런 웹 기반 환경의 위험성에 대해 실감하지 못하는 것이 현실이다. 상황이 이렇다보니 투자를 하지 않는 것은 당연한 일이고 심지어 해킹을 당하고도 그것을 인지하지 못하는 곳이 태반인 실정. 모의침투 테스트결과 보안이 검토되지 않고 개발된 웹 애플리케이션(웹 사이트)의 경우 인터넷 서비스를 개시한지 5~10분 내에 침투가 가능했습니다. 심지어 내부의 네트워크로 침투해 들어가 어드민 계정은 물론 네트워크를 장악하는데 까지도 1시간이 채 걸리지 않는 실정입니다.

보안 솔루션, 맹신은 금물
중소기업의 경우 보안 담당자가 있다 하더라도 실제로 담당해야 하는 업무에 비해 인원이 턱없이 부족하기 때문에, 보안 솔루션을 도입하고 그에 의존하게 되는 경우가 많습니다. 하지만, 어떤 해커도 보안 솔루션을 감안하지 않고 침투를 시도하지 않는다는 점을 간과해서는 안 됩니다. 실제 사고는 각종 솔루션을 우회하는 것에서 시작되게 마련이고 안전하다고 믿는 시스템일수록 더 큰 문제를 발생시키는 경우가 많습니다. 보안 담당자가 과도한 업무를 핑계로 IT 동향의 파악을 게을리 하거나 보안 담당자와 시스템만 믿고 다른 사람들은 보안을 등한시하는 회사는 골키퍼 없는 골대와 같습니다. 최근에 발생한 리니지 사태도 대량의 회원정보 노출로 이어질 수 있는 웹 애플리케이션 보안이라는 새로운 보안 트렌드를 읽지 못한 여러 기관과 기업들의 문제로 귀결될 수 있을 것이다. 담당자들은 이번 사건을 통해 항상 새로운 IT 트렌드와 보안의 상관관계를 읽고 있어야 한다는 것을 교훈으로 새겨야겠다.

웹 애플리케이션 웜에 대비하라
작년에 공개 소프트웨어인 아파치+PHP 게시판의 버그를 이용한 웜이 큰 이슈가 된 적이 있다. 해킹사건의 역사를 살펴보면 공개 소프트웨어 기반에서 사건이 터지고 나면 그와 유사한 기법들이 상용화 솔루션에서 반복되어 온 것을 알 수 있다. 이런 내용을 기반으로 전망할 경우 머지않은 시점에 웹 애플리케이션의 취약점(MS 솔루션 계열)을 타깃으로 한 웜이 고개를 들 것이라는 예상이 지배적이다. 대기업이나 보안조직이 있는 기업들은 이미 이에 대한 대책들을 마련하고 있지만, 중소기업의 실정은 그렇지 못한 듯하다.

만약, 이런 웜이 정말 활동을 시작하게 된다면 웹 애플리케이션 주도인 우리나라의 경우 심각한 파장을 일으킬 것이 불 보듯 훤한 일이다. 이 글을 읽는 독자가 보안 담당자라면 이 점에 유의하여 대비할 수 있기를 바란다.
보안이란 사슬과 같다. 수없이 많은 사슬 중 하나만 끊으면 해킹은 성공하고 사슬은 그 의미를 잃게 마련이다. 모든 사슬을 완벽하게 보호하는 것은 불가능하지만 각 사슬을 더욱 튼튼하게 만들고 자주 관리하여 완전히 끊어지기 전에 보수하는 것은 보안 담당자가 할 수 있는 일이라는 점을 잊지 말자.

정희용 기자 | flytgr@imaso.co.kr



제공 : DB포탈사이트 DBguide.net


출처 : 마이크로 소프트웨어 [2006년 4월호]