WAF 단독 적용 현 단계선 위험 … 제품 방어 능력·기능 꼼꼼히 살펴야
김동주 / 유니포인트 CTO / djkim@unipoint.co.kr
1. 보안의 위협
2. 웹 애플리케이션 보안 위협에 대응하는 현실
3. 웹 애플리케이션 보안 위협 대응 방안(이번호)
처음 1회에는 위협에 대해, 2회에는 웹 애플리케이션 보안 위협에 대응하는 현실에 대해 알아봤다. 이어서 이번호에서는 웹 애플리케이션에 대한 보안 위협에 대응하는 방안에 대해 알아본다. <편집자>
다시 한번 OWASP 10대 취약점을 살펴보자.
OWASP(Open Web Application Security Project)에 대한 내용은 몇 차례 인용한 바 있다. 이제 이들 위협에 대응하는 방안을 알아보기 위해 다시 상기해보자.
1. 입력값 검증 부재
웹 애플리케이션 서비스를 요청하기 위해 애플리케이션에 데이터를 전송할 때 HTTP를 통해 URL, 쿼리(Query), 헤더(Header), 쿠키(Cookie), HTML 폼에 대한 정보를 전송한다. 이때 이 데이터 값을 악의적으로 변경해 시스템에 피해를 가할 수 있다.
2. 취약한 접근 통제
가장 심각한 위협은 외부에서 관리자의 접근을 허용하는 것으로 루트 권한이나, 시스템 환경 구성 관리 권한을 제공하면 이 통로를 통해 전 시스템에 대한 접근이 허용될 수 있다.
3. 취약한 인증 및 세션 관리
인증 관련 정보를 제어하는 프로그램에 대한 통제는 상대적으로 느슨하다. 세션에 실려 다니는 정보가 유출돼 위협이 발생할 수도 있다.
4. 크로스 사이트 스크립팅
특정 사이트에서 사용자가 정보를 받을 때 그 정보 내에 악의적인 코드를 숨겨놓아 이를 클라이언트에서 실행되도록 하는 기법이다.
5. 버퍼 오버플로우
웹 서버, 웹 애플리케이션 서버에 대한 공격 유형이다. 웹 애플리케이션 자체의 버퍼 오버플로우에 대한 공격 유형과 비슷하다.
6. 삽입 취약점
삽입 취약점은 웹 애플리케이션이 자체 로직을 이용해 외부의 모듈을 호출하는 것이다.
7. 부적절한 에러처리
애플리케이션 실행 도중 에러가 발생한 경우에 해당 에러의 내용을 직접 사용자 화면에 보여주는 경우가 있다. 이 정보가 자바 익스프레션 덤프(Exception Dump)라면 사용자는 애플리케이션이 어떤 계층 구조로 이뤄져 있고 어디에서 어떤 문제가 발생하는지 알 수 있으며 이를 통해 시스템에 대한 공격을 할 수 있다.
8. 취약한 정보저장 방식
웹 애플리케이션이 데이터베이스나 파일 시스템이 민감한 정보를 저장할 필요가 있다. 이들 정보는 외부에서 접근이 허용되지 않는 내부 망에 저장되는 경우가 대부분이지만 웹 서버에 저장돼 외부 취약점이 발생하기도 한다.
9. 서비스 방해공격
서비스 방해 공격은 웹 애플리케이션의 취약점을 이용해 해당 애플리케이션이 서비스 중단 상태로 가도록 하는 것이다.
10. 부적절한 환경 설정
서버 환경 설정에서 일반적으로 일어나는 유형은 운영 팀에서 적절한 보안 패치를 하지 않았을 때 발생한다.
애플리케이션 개발 단계에서 보안성이 검증되지 않은 애플리케이션은 취약점을 가지고 있을 수밖에 없다. 이를 해소하는 방법은 다음과 같은 방법들이 있다.
가. 전체 애플리케이션 보안성 검토
이 방법은 기업 내의 모든 애플리케이션에 대한 보안성을 검증해 취약점 보완이 필요한 애플리케이션을 찾아 이를 수정 보완하는 방법이다. 이 방법은 기업/기관의 보안 정책에 대한 검토가 선행돼야 하고, 취약점을 가진 애플리케이션을 수정해야 하는데, 방대한 기업 애플리케이션을 모두 찾는다는 것은 현실적으로 불가능하다.
나. 웹 애플리케이션 방화벽 기능으로 대응
이 방법은 효율적인 WAF를 도입해 차단할 수 있는 부분은 사전 차단하는 방법이다. 그러나 웹 애플리케이션 방화벽이 가진 기능상의 제약으로 OWASP 10대 취약점을 모두 해소할 수 없다는 단점이 있다. 또한 웹 애플리케이션에 적용할 폴리시를 만드는 것부터 고난의 행군이 될 가능성이 농후하다.
다. 취약점 스캐닝 후 WAF 적용
일부 웹 애플리케이션 방화벽은 스캐닝 도구를 활용해 탐지된 취약점을 폴리시에 적용하는 방법이 있다. WAF의 폴리시를 탐색할 수 있다는 점에서는 위의 ‘나’ 방법보다는 진일보한 방법이지만 여전히 WAF가 모든 취약점을 제어할 수 없다는 점에서 제약점이 있다.
정책을 자동으로 설정할 수 있는 기능을 가진 도구와 함께 사용할 수 있는 툴들도 있으나, 자동으로 설정된 정책이 취약점을 방어할 뿐만 아니라 반드시 통과시켜야 하는 트래픽을 차단하는 오탐도 있을 수 있으므로 제한성이 여전히 상존한다.
라. 자동 취약점 탐지 또는 학습이 가능한 부분은 WAF로 적용하고 나머지는 수작업으로 적용하는 방안
현실적으로 가장 적절하다고 판단되는 부분이다. 웹 애플리케이션 방화벽과 함께 제공되는 자가 학습에 의한 정책(Policy) 적용 기능을 가진 웹 애플리케이션 방화벽을 사용하거나, 스캐닝 도구에 의해 탐지된 취약점을 웹 애플리케이션 방화벽에 적용해 방어하고, 나머지 취약점은 별도의 프로젝트를 통하여 개선하는 방식이다. 이 방식이 현실적으로 가장 유용한 방식이다. 물론, 신규로 착수하는 프로젝트에는 보안성 검토, 애플리케이션 보안 표준 마련, 개발표준안 반영, 애플리케이션 적용이라는 흐름이 적용돼야 한다.
이런 방안들은 10대 취약점에 대해 상호 보완적으로 대응이 가능하므로 각 사이트 환경에 적절하게 대응해야 한다. 어느 한 솔루션으로 모든 것을 다 방어할 수 있다는 것은 불가능한 일이다. 그럼 각 취약점 별로 웹 애플리케이션 방화벽을 통한 대응 방법에 대해 알아보자.
WAF 업체들의 대응과 우려
<표 1>에서 본 바와 같이 웹 애플리케이션 방화벽을 어떤 방식으로 적용하든 OWASP의 취약점을 완벽하게 방어하는 것은 현실적으로 불가능하다. 그러나 국내외의 많은 웹 애플리케이션 방화벽 업체들은 자신들의 제품이 모든 취약점에 대해 완벽하게 방어가 가능한 것으로 표현하고 있다. 한 예를 보자.
<표 2>는 각 웹 애플리케이션 방화벽의 기능을 설명한 백서와 브로셔 또는 시장에 배포하는 자료의 내용을 발췌한 것이다. 시장에 배포하는 것만으로 보면 어떤 웹 애플리케이션 방화벽이든 10대 취약점을 완벽하게 방어할 듯이 표현돼 있다. 심지어 2~3개의 기능만을 제공하는 C사의 경우는 프리젠테이션 자료를 보면 IPS에 UTM 기능을 일부 추가하고는 이를 10대 취약점 모두를 완벽하게 방어하는 것으로 표현하고 있다.
앞에서도 본 바와 같이 10대 취약점, 더 나아가서 웹 애플리케이션에 일반적으로 포함될 가능성이 있는 보안상의 취약성은 웹 애플리케이션 방화벽 한가지 기능으로 완벽하게 해결될 수 없는 것이 현실이다. 현실이 이런데도 모든 취약점에 대해 완벽하게 방어한다고 표현하는 것은 고객이 웹 애플리케이션을 사용해보고는 그 기능에 실망해 전체 시장을 축소시킬 위험성이 다분히 있다.
더욱이 특정한 취약점을 방어하는 기능을 가진 경우에도 WAF로 대응하는 경우 문제점은 상존한다. 만약에 학습기능을 가진 웹 애플리케이션 방화벽이 애플리케이션 취약점을 완벽하게 방어하며, 애플리케이션이 버퍼 오버플로우 취약점을 가지고 있다고 가정하자.
웹 애플리케이션 방화벽을 공급한 업체와 고객은 학습기능을 통해 버퍼 오버플로우 취약점은 완벽히 방어가 된다고 판단하게 될 것이고 이 취약점에 대해서 학습기간이 종료된 이후에는 이를 정책으로 설정하면 이 취약점은 더 이상 문제가 되지 않는다고 판단하게 된다. 그런데, 애플리케이션 입력 값 버퍼를 100바이트에서 101바이트로 늘리게 되면 어떤 일이 벌어질까? 프로그램 작성자가 보안성 검토 없이 애플리케이션을 배포하게 되면 그날부터 입력 값의 길이는 100바이트에서 101바이트로 늘어난다.
웹 애플리케이션 방화벽은 입력 값의 길이를 100바이트로 인식하고 101바이트가 입력되는 경우는 취약점에 대한 공격으로 분류할 가능성이 높아지며, 이 애플리케이션을 사용하는 순간 웹 애플리케이션 방화벽은 이를 공격으로 간주해 시스템에 접근을 못하게 만들 것이다. 그 결과로 이 기업의 애플리케이션은 더 이상 정상 동작하지 않을 것이다. 이런 경우를 접한 고객의 반응은 당연히 웹 애플리케이션 방화벽을 더 이상 믿을 것이 못 되는 제품으로 치부하게 될 것이고, 웹 애플리케이션 방화벽 시장은 확산단계에서 시장 자체에 대한 위협을 받게 된다.
따라서 현 단계에서 웹 애플리케이션 방화벽을 만들고 공급하는 업체들은 자신들의 웹 애플리케이션 방화벽이 어느 부분은 방어하고 어느 부분은 못하는지에 대한 정보와 각 취약점을 방어하더라도 적용 이후에 어떤 후속 조치가 필요한지를 솔직하게 고객에게 전달해야 전체 시장에 대한 위협을 줄이면서 웹 애플리케이션 방화벽 웹 애플리케이션 방화벽 시장이 커 나갈 수 있을 것이다.
웹 애플리케이션 방화벽과 오탐
스팸 메일로 괴롭힘을 당하면 메일 필터링에 대해 심각하게 고려하고 이를 실제 사이트에 적용하는 경우가 생긴다. 그런데, 메일 필터링에서도 스팸 메일로 고통을 받는 것 보다 오탐으로 인해 반드시 전달받아야 하는 메일을 놓치는 경우에 발생하는 사업적/개인적 손실이 더 크게 발생한다. 이런 이유로 인해 스팸 메일 차단 기능이 있어도 활용할 때에는 매우 제한적으로 조심스럽게 적용해 사용한다.
마찬가지로 웹 애플리케이션 방화벽도 공격에 대한 적절한 방어도 중요하지만 오탐에 의해 서비스를 제한했을 경우 서비스가 중단돼 입는 피해가 더 클 가능성이 상존한다. 위에서 본 입력 길이의 변경을 은행 인터넷 뱅킹의 초기화면에 적용했다고 가정하자. 웹 애플리케이션 방화벽이 잘 작동하는 이 사이트에서 변경된 내용이 즉시 정책으로 적용되지 못하고 학습기능에만 의존하면, 인터넷 뱅킹의 초기 화면 서비스는 제한될 것이다. 이는 전체적인 인터넷뱅킹 서비스 중단으로 이어져 큰 혼란을 야기하게 될 것이다. 여기에서는 입력 값 검증 부분을 예로 들었지만, 다른 기능들도 역시 마찬가지이다.
따라서 웹 애플리케이션 방화벽을 단독으로 적용하는 것은 현 단계에서 매우 위험하며, 스캐닝 도구, 보안 정책, 형상관리 정책, 웹 애플리케이션을 종합적으로 검토해 이들에 대한 프로젝트 단계별, 서비스 실행 단계별 대응책을 마련하고 웹 애플리케이션 방화벽을 적용하는 것이 바람직하다.
WAF 시장의 형성과 과당 경쟁
OWASP 10대 취약점은 이제 대부분의 보안 전문가나 애플리케이션 프로젝트 전문가들은 그 내용을 알고 대응책을 심각하게 고려하고 있다. 그런데 현재 국내에서만 웹 애플리케이션 방화벽이라는 이름을 걸고 제품을 만들어 공급하는 업체가 국내산/외국산 포함해 모두 20개 가까이 된다. 이는 한정된 시장(올해의 경우 예측되는 시장 규모가 작게는 20억에서 크게는 50억 정도로 보인다)에서 과당 경쟁을 불러올 것으로 보인다.
하나의 어플라이언스 보안장비를 개발하는데 수 억원이 소요되고, 소프트웨어 개발 비용까지 포함하면 더 많은 비용이 소요되는데, 20여개 업체가 이 시장에서 경쟁을 시작하면 필연적으로 가격이 붕괴되고 시장이 교란돼 몇몇 업체는 퇴출돼야 하는 운명에 처할 것이다. 그 와중에 유지보수와 관련된 문제는 고객을 괴롭히게 되어 장기적으로 웹 애플리케이션 방화벽 시장의 성장에 걸림돌로 작용할 것으로 예상된다.
자사 환경 먼저 검토하고 WAF 고려해야
웹 애플리케이션 보안은 1회 기고에서 말한 바와 같이 보안 정책, 애플리케이션 표준화, 애플리케이션 유지보수, 형상관리, 네트워크, 기존 보안 시스템, 권한관리 등과 밀접하게 연관돼 있다. 이런 환경에서 애플리케이션 보안은 단순히 어느 한 장비, 어느 한 소프트웨어가 무두 해결해야하는 문제가 아니다.
<그림>에서 보는 바와 같이 보안 정책이 개발돼 각 단계별로 충분한 통제가 이뤄진 상태에서 애플리케이션이 개발되고 품질이 유지돼야 한다. 또한 웹 애플리케이션 방화벽의 적용도 기존의 각 애플리케이션 및 업무 특성에 따라 신중하게 이뤄져야 한다. 특히 웹 애플리케이션 방화벽 공급 업체의 생존 가능성도 염두에 둔 도입 제품이 선정돼야 할 것이다.
