1. 웹 애플리케이션 보안의 중요성(이번 호)
2. 웹 애플리케이션 방화벽 활용방법

웹 애플리케이션 취약점 방어기능 강화 ‘필수’

보안 공격 애플리케이션에 집중 …
웹 방화벽·정책 수립으로 안전한 웹 서비스 구현

남덕우
F5 네트웍스 코리아 지사장
dw.nam@f5.com

기업들이 점차 많은 애플리케이션들을 웹과 연결시킴에 따라 보안에 민감한 고객 데이터들이 해커의 공격에 더 많이 노출되고 있는 실정이다. 웹 애플리케이션들은 기업망의 외곽을 둘러싸고 있는 보안 경계선을 통과하기만 하면 사용자들에게 내부 시스템을 무제한 액세스할 수 있도록 한다. 따라서 대부분의 보안 공격이 애플리케이션에 집중되고 있는 것이 당연하다고 볼 수 있다.
이 글에서는 웹 애플리케이션이 가지는 취약성의 근본 원인과 일반적인 해커들의 공격 방법, 위험 완화를 위한 애플리케이션 방화벽의 필요성 및 혜택을 다양한 예시와 설명을 통해 제시하고자 한다. <편집자>

현재 대부분의 기업 비즈니스 형태가 웹으로 진화하고 있다. 웹 기반의 새로운 애플리케이션이 개발될 때마다 기존에 직접 액세스하지 못했던 백엔드 시스템들이 인터넷과 연결되게 되며 궁극적으로는 국제적으로 개방되게 된다. 그 결과 회사의 중요 데이터가 외부 공격에 노출되는 것이다.
그러나 오늘날의 애플리케이션에서 가장 위험한 보안상의 결함은 웜이나 바이러스도, 알려져 있는 애플리케이션 서버의 취약성도 아닌, 애플리케이션 자체의 취약성이다. 애플리케이션마다 각기 다른 취약성 때문에 기업의 웹 인프라는 사이트 간 스크립팅, SQL 주입, 쿠키 오염과 같은 공격에 노출된다. 업계에서는 개방형 웹 애플리케이션 보안 프로젝트(OWASP)라는 이름의 그룹을 결성하고, 이러한 유형의 취약성을 종합해 ‘10대 애플리케이션 취약성’이라는 중요한 목록을 발표했다(이 목록은 www.owasp.org에 수록되어 있다). 이 밖에도 각 보안업체들이 자사의 강점을 홍보하기 위해 작성하는 여러 목록이 있지만, 이러한 목록에서 강조하는 취약성은 모두 동일하다. 즉, 애초에 브라우저는 사용자가 애플리케이션에서 보내는 요청을 검증하도록 만들어진 것이 아니라는 점이다.
오늘날 애플리케이션이 가지는 취약성은 근본적으로 애플리케이션 고유의 성질 때문이다. 즉, 대부분의 웹 애플리케이션은 클라이언트/서버 애플리케이션의 방법론에 따라 개발 및 테스트됐다. 클라이언트/서버 애플리케이션으로 시작했다가 웹으로 ‘이식’된 경우도 있으며, 그 과정은 흔히 클라이언트 GUI를 웹 브라우저에서 다시 만드는 정도에 불과했다. 한편 웹용으로 개발된 애플리케이션도 있었지만 그 코딩 및 테스트 과정에서 웹 보안의 특수한 성질을 감안하지는 않았다.
이것이 왜 문제인가? 웹 애플리케이션에는 보안상 해결해야 할 특수한 과제가 있지만 클라이언트/서버 환경에 익숙한 사람의 눈에는 그것이 분명하게 드러나지 않기 때문이다.
전통적인 클라이언트/서버 개발 환경의 패러다임을 보면, 클라이언트/서버 애플리케이션의 개발 및 테스트 프로세스는 수 십년에 걸친 수정을 통해 최적화, 정교화되면서 매우 견고한 애플리케이션을 만들어냈다. 이러한 애플리케이션은 동시 작업을 목적으로 동시 작성된 서버 코드와 클라이언트 코드로 구성된다. 그러나 클라이언트/서버 애플리케이션의 구현과 유지보수에는 여전히 많은 비용이 들었다. 클라이언트는 여러 운영 체제에서 테스트하고 모든 클라이언트 컴퓨터에 설치한 후 소폭의 버전 변경이 있을 때마다 다시 설치해야 했다. 다수의 사용자를 위해 새 애플리케이션을 구현하거나 기존 애플리케이션을 유지 보수하는 비용은 결국 감당할 수 없는 수준이 됐다.
기업은 구축 및 유지보수 비용을 절약하기 위해 대부분은 아니더라도 많은 애플리케이션을 웹으로 옮겨갔으며, 클라이언트를 표준 웹 브라우저로 이식하는 동안 서버를 약간 변경하는 일도 흔했다. 오늘날의 클라이언트는 구축 비용이 없으며 독립적인 플랫폼을 유지하고 있다. 그러나 기업은 엄청난 위험에 노출됐다. 서버 코드는 믿을 수 있는 클라이언트를 기대하지만 실제로는 웹 브라우저 클라이언트가 있을 뿐이다. 이것이 왜 그렇게 위험한지 이해하기 위해, 두 모델의 주된 차이점을 살펴보자.

중량급 클라이언트와 브라우저
웹 애플리케이션과 클라이언트/서버 애플리케이션의 근본적인 차이점 때문에 웹으로 가는 기업들이 커다란 위험에 처하게 되는 것이다. 이러한 애플리케이션의 두 가지 주된 차이점을 살펴보자.
클라이언트/서버 애플리케이션에 사용되는 특정 용도의 중량급 클라이언트는 리버스 엔지니어링하기 어렵기 때문에 해커가 서버에 대한 입력을 수정하기도 어려웠다. 한번 생각해 보자. PC에서 소프트웨어를 실행할 때 사용자는 그 소프트웨어가 서버로 보내는 메시지를 바꿀 수 없다. 소프트웨어에는 고정된 버튼과 도구가 있으며, 기본 코드에 액세스해 생성되는 명령을 조작할 방법은 없다.
그러나 브라우저는 매우 쉽게 조작할 수 있다. 웹 페이지에 액세스하는 사람은 누구나 클라이언트 쪽 코드의 소스를 보고 손쉽게 변경할 수 있다(그저 인터넷 익스플로러나 기타 브라우저의 ‘보기’ 메뉴에서 ‘소스 보기’를 선택해 코드를 변경한 후 페이지를 새로 고치면 된다). 실제로 현재 이런 유형의 조작을 자동화하는 ‘웹 프록시’ 등의 도구를 제공하는 해커 웹 사이트도 있다.
클라이언트/서버 애플리케이션은 서버 성능 개선, 네트워크 트래픽 감소, 사용자 사용 편의 등을 위해 상당량의 데이터를 클라이언트 쪽에서 검증한다. 웹 서버는 브라우저의 기능(HTML 및 자바스크립트)을 활용해 클라이언트에서 데이터를 검증하지만, HTML이 변경되거나 자바스크립트가 비활성화될 수 있다. 바꿔 말하자면, 개발자가 브라우저에 투입하는 어떤 검증 및 검사 방법이라도 사용자가 간단히 비활성화하거나 변경할 수 있다. 따라서 입력값 검증의 부담은 전적으로 서버 쪽에 전가되며, 프로그래머가 잠재적인 악성 입력을 피하기 위해 모든 값을 일일이 검사하는 것은 거의 불가능하다.
이로 인해 웹 애플리케이션은 버퍼 오버플로우, SQL 주입, 사이트 간 스크립팅과 같은 공격에 노출된다. 예를 들어, 사용자는 웹 양식의 입력 필드에 악성 코드를 입력할 수 있다. 어떤 온라인 경매 사이트에서는 전자 상거래 애플리케이션에서 특히 곤란한 취약성을 발견했다. 악의적인 사용자가 위험한 자바스크립트 명령을 품목 설명에 넣어 경매 목록에 올리고 있었다.
경매 소프트웨어는 사용자가 입력하는 설명을 검사하지 않았기 때문에 그 상품을 클릭한 모든 사람이 자바스크립트 명령을 받았으며, 그 명령은 브라우저에서 실행되면서 새 창을 열고 쿠키를 도용하는 등 전형적인 사이트 간 스크립팅 공격을 수행했다.

통제력 유지 대 통제력 상실
기존 클라이언트/서버 환경과 웹의 두 번째 주요 차이점을 살펴보자. 클라이언트/서버 환경에서는 각 사용자와 서버 간에 연속적인 세션이 유지된다. 일단 사용자가 애플리케이션에 로그인하면 연결이 계속 이어지면서 사용자에게 적절한 정보가 제공된다. 반면 웹 환경에는 세션이 없다. 사용자가 페이지를 요청하면, 다음 번 페이지를 요청할 때까지 서버에게 그 사용자는 보이지 않는다.
이 때문에 웹 애플리케이션은 여러 가지 공격에 무방비 상태가 된다. 가장 흔한 공격은 액세스 제어 차단(broken access control)이라고도 부르는 강제 브라우징(forceful browsing)이다. 이것은 그저 액세스가 허용되지 않는 페이지나 리소스를 웹 서버에 요청하는 공격이다. 경우에 따라서는 어떤 애플리케이션의 내부 페이지를 즐겨찾기에 추가한 다음 나중에 인증 페이지를 통과하지 않고 그 페이지로 직접 이동할 수도 있다. 잘 알려진 어떤 금융 서비스 회사에도 최근 이런 문제가 발생했다. 내부 페이지의 주소를 아는 사용자들은 실제로 로그인 페이지를 우회할 수 있었다. 뿐만 아니라, 보고싶은 정보의 URL을 사용자가 추측할 수 있는 경우도 있다.
최근에 ‘깜짝 시사회’를 열었던 어떤 대형 음반 회사에서는 곧 발매할 앨범의 첫 곡에 /track1.mp3로 끝나는 URL을 사용했다. 당연히 젊은 소비자들은 ‘track2.mp3’ 또는 ‘track3.mp3’만 입력하면 앨범의 전곡에 액세스할 수 있다는 사실을 금새 알아냈다. 좀더 심각한 사례로, 미네소타주 경찰국은 최근 누구든 공공 웹 사이트 주소에 ‘/personsearch/personsearch.asp’만 추가하면 경찰국의 치안 기록에 액세스할 수 있다는 것을 발견했다(이 문제는 그 후에 바로잡았다).
웹의 통제력 상실에 관한 또 다른 근본적 한계는, 웹 애플리케이션은 사용자 및 그가 요청한 정보 유형을 식별하기 위한 정보를 브라우저에 남겨야만 한다는 것이다. 예를 들어, 웹 서버가 가격이나 사용자 그룹 정보를 담은 비밀 필드를 페이지에 남겨두면 사용자는 그 페이지의 소스를 보고 변경해 다시 제출할 수 있다.
서버가 사용자를 추적하는 가장 일반적인 방법은 세션 쿠키이다. 다시 말하지만, 쿠키는 사용자의 PC에 상주하므로 사용자가 액세스하고 변경할 수 있다. 월 스트리트 저널의 리 고메즈(Lee Gomes)는 최근 게이트웨이 컴퓨터사의 이러한 결함을 밝혀냈다. 고메즈의 보도에 따르면, 사용자가 쿠키를 변경하고 www.gateway.com에 다시 방문하면 “x님 환영합니다”라는 인사가 나왔으며 이들은 x의 신용 카드 정보에 액세스하여 일을 처리할 수 있었다. 쿠키를 다시 변경하면 또 다른 사람으로 ‘인증’되는 것이다.
기존 보안 시스템의 문제점
이렇듯 기업의 데이터와 애플리케이션들이 공격에 의해 무방비로 노출되어 있지만, 기존의 보안 시스템들은 나날이 새로워지는 악성 공격들을 막아내기에는 많은 문제점을 안고 있다. 해커들의 공격 방법이 점차 교묘해지고 있는데 반해, 보안 솔루션들의 대응이 이를 뒷받침할 수 없기 때문이다.
해커들은 기존 방어벽을 뚫고 들어갈 새로운 방법들을 끊임없이 모색하고 있다. 최근 CSI/FBI 조사 자료에 따르면, 응답자의 52% 가량이 2004년 한 해 동안 회사 외부로부터 시스템 침투가 있었다고 밝혔다. 물론 응답자의 98%는 방화벽을 갖춘 상태였다. 이와 같은 공격으로 인한 시스템 파괴, 웹 애플리케이션 오용, 웹사이트 신뢰도 저하, 중요 정보 도난, 서비스 거부 등 금전적인 손실은 269개 응답 기업에서 총 1조4천100억달러 규모로 집계된 바 있다.
기존 방화벽은 지금까지 기업망의 불법 액세스를 차단하는 훌륭한 수단으로 기능해 왔으나 현재 이것 만으로는 충분하지 못하다. IDC에서 2002년에 지적한 바와 같이 방화벽 내부의 포트들은 통신에 개방되어 있어야 하기 때문에 방화벽이 애플리케이션 레이어에 미치는 보호 효과는 극히 미약하다.
최근, 기존 방화벽 공급업체들이 IDS(Intrusion Detection Systems)와 IPS(Intrusion Prevention Systems)를 자사 제품에 적용하기 위한 ‘애플리케이션 레이어 보안’ 기능 개발을 시작했다. 하지만 이들 솔루션들은 다음의 두 가지 이유로 인해서 특별한 효과가 없는 것으로 드러났다.

첫째 - 이 솔루션들은 서명 공격이나 기타 비정상적 사용자 행위 패턴에 의존한다. 따라서 새로운 형태의 공격(제로 데이 공격)에 노출돼 있으며, 공격 형태를 정상 트래픽으로 간주하여 간과한다. 뿐만 아니라 특정 애플리케이션의 취약성을 집중적으로 공략하는 목적형 공격에 대해서도 반응을 일으키지 않는다. 이들 공격은 일반적인 패턴이 없기 때문이다.

둘째 - 이 솔루션들은 애플리케이션 레이어가 아닌 네트워크 레이어에서 실행된다. 대다수의 네트워크 보안 제품들은 해석할 수 있는 정보가 제한적이기 때문에 근본적으로 제한적인 기능을 갖는다. 방화벽과 IPS 시스템들은 패킷을 전체 요구 내에서가 아닌 회선 내에서 감시하기 때문에 정상 요구와 비정상 요구를 구분할만한 지식을 애플리케이션 별로 갖지 못한다. 실제로 대부분의 제품들은 간단한 SSL 암호도 감시할 수 없는 실정이다.

따라서, 기업들은 현재 자사 애플리케이션들에 높은 수준의 보안 기능을 구축하기 위해 노력하고 있다. 애플리케이션 스캐너와 같은 도구들을 이용해 두드러진 취약점을 식별해 낼 수는 있지만, 이들을 일일이 스캐닝해 패칭하는 일에는 상당한 인력과 시간이 필요하다.
뿐만 아니라 스캐닝을 통해 애플리케이션 상의 취약점을 모두 밝혀낼 수도 없다. 확인해야 할 파라미터가 지나치게 많을 뿐 아니라 입력점 또한 많은 것이 사실이다. 개발자들은 수천 개의 취약점을 패치할 수 있으나 해커 한 사람은 단 한 개의 취약점을 통해서도 치명적인 피해를 입힐 수 있는 것이다.

애플리케이션 취약점 해결 방법
이러한 취약점을 해결할 방법은 현재 두 가지이다. 첫째는 애플리케이션 코드 자체에 명시적인 안전장치를 넣는 것이다. 소위 ‘안전한 코딩’의 도입을 위한 교육과 프레임워크를 제공하는 컨설팅 회사는 수도 없으며, 이런 서비스를 통해 애플리케이션을 전보다 크게 개선할 수 있다. 또한 애플리케이션 개발 플랫폼은 SQL 주입 공격을 예방하기 위한 입력값 검증 도구 등 개발자에게 유용한 도구를 점점 더 많이 도입하고 있다.
마이크로소프트는 웹 양식의 검증 기능을 채택했고, 자바 역시 스트러츠(Struts)와 같은 도구를 통해 비슷한 기능을 제공한다. 물론 이러한 도구는 모두 개발자가 실행해야만 유용하며 그러지 않으면 무용지물이다. 게다가 플랫폼 취약성을 막는 코딩은 불가능하다. 예를 들어, 알고있는 주소나 추측한 주소에 강제 브라우징(forceful browsing)하여 무방비 상태로 웹 서버에 남겨진 구성 파일 또는 시스템에 액세스할 수 있다.
더구나 대부분의 회사는 취약성으로 가득한 구형 웹 애플리케이션을 수백개까지는 아니더라도 수십개씩 사용하고 있다. 애플리케이션 개선 작업의 출발점으로 가장 좋은 것은 스캐닝 도구를 사용하는 것이다. 이 도구는 플랫폼 및 코드 차원에서 애플리케이션의 취약성을 파악하는 데 도움이 된다.
두 번째는 가장 이상적인 방법으로 애플리케이션별로 상세한 정보를 보유하고 있어 악의적인 요구들을 걸러낼 수 있는 새로운 네트워크 어플라이언스에게 보안 기능을 부담시키는 것이다. 관리 및 감사가 쉬운 중앙의 장치에 애플리케이션 계층 보안을 맡김으로써, 특정/불특정 다수를 목표로 하는 애플리케이션 공격에 대하여 비용 효율적이고 적극적인 고성능 애플리케이션 계층 보안을 제공하게 된다.
이 보호 기능은 마치 방화벽과 같은 역할을 하지만 일반적 트래픽 패턴이 아닌 애플리케이션 별 특수 로직을 이용한다. 이런 형태의 장치는 애플리케이션 트래픽 형태를 정확히 인지하고 있어 이에 위배되는 모든 트래픽을 차단시킬 수 있을 것이다. 이와 같은 요구에 부응하는 새로운 차원의 보안 솔루션이 애플리케이션 방화벽(Application Firewalls)이다.
애플리케이션 방화벽은 웹 서버의 전방에 자리잡고서 각 요청에 악성 콘텐츠나 강제 브라우징이 있는지를 검사한 다음 적합한 트래픽만 후방의 웹 서버로 전달하는 리버스 프록시이다. 이 솔루션은 웹인스펙트(AVDL로 공유되는 공개 소스 애플리케이션 취약성 기술 언어)와 같은 스캐너에서 감지되는 취약성을 차단하거나, 고유의 애플리케이션 맵을 처음부터 새로 작성해 모든 비인증 요청을 차단할 수 있다.