|
|
|
|
2. 웹 애플리케이션 보안 위협에 대응하는 현실 |
| Tech Guide - 웹보안 |
 |
2006년 08월 02일 00:00:00 |
|
 |
|
|
웹 애플리케이션 보안 강화로 우리 사이트를 지키자
애플리케이션 정책 정의·형상 관리 등 절차 준수 중요 … 개발 표준안 활용 필수
연재순서
1. 보안의 위협
2. 웹 애플리케이션 보안 위협에 대응하는 현실(이번호)
3. 웹 애플리케이션 보안 위협 대응 방안
지난번에는 보안의 위협에 대하여 알아봤는데, 이번에는 우리의 현재 상황이 어떤가를 알아보겠다. 우리가 얼마나 보안 위협에 직면해있는지, 이런 보안위협들에 어떻게 대처하고 있는지 여러 사이트를 다니면서 확인해 보았다. 이는 우리의 현재 상황을 판단하고 향후 대책을 수립하는데 있어 많은 도움이 돼 줄 것이다. <편집자>
김동주
유니포인트 CTO
djkim@unipoint.co.kr
유니 포인트 DTOEJUDJ 에러가 나면서 차이 바뀌었다...
어느 사이트에서 찾은 에러
자주 다니는 사이트에서 게시판을 보다 보니 갑자기 에러가 나면서 창이 바뀌었다. 아래 그림은 그 사이트의 에러 표시 정보이다.
아래 그림 1의 내용을 보면 “home/hosting_users/hungni17/inc/db_connect_shop.php”라는 파일을 “……/customer/board_view.html”의 세번째 라인에서 읽다가 실패했다는 것을 알 수 있다. 여기서 생각해보자. 내가 만약 해커라면 무슨일을 할 수 있을까?
이 그림에서 알 수 있는 것은 다음과 같다.
1. html 파일의 특정 부분에서 시스템 내의 특정한 파일을 부르는 형식으로 프로그램이 되어있다.
2. 호출하는 파일은 DB와 직접 무슨 작업인가를 수행한다.
3. 이 시스템의 온라인용 파일 구조는 /home/hosting_ users/hungni17/inc 디렉토리에 php에서 사용하는 파일들을 모아놓고 있다.
4. 디렉토리 이름으로 보아서 hosting을 한 경우 같은데 이 시스템은 hungni17아래의 디렉토리내에 아마 이 서비스 전체가 위치해 있을 것 같다.
5. html에 대한 소스 보기를 하면 더 많은 정보를 찾을 수 있다.
7. 일반 사용자 권한 아니면 최소한 웹 상의 사용자 권한으로 여러 파일을 시스템 내에서 구동한다. 그렇다면 시스템 명령어를 호출할 수도 있을 것이다.
악의적인 사용자라면 이런 수준의 정보만 가지고도 애플리케이션을 통한 시스템 공격 방법을 수없이 찾을 수 있을 것이다.
OWASP의 10개 항목 중에서 이 시스템이 위배하고 있는 것은 다음과 같이 보여진다.
1. 삽입 취약점이 존재한다.
2. 에러처리의 잘못으로 시스템 정보가 공개된다.
3. 시스템 환경 구성 정보가 노출된다.
4. html에 의한 압력값이 사전에 제어되지 않는다.
이는 단순히 한 사이트에서만 발견되는 문제가 아니다. 4시간 정도의 웹 서핑으로 이런 종류의 웹 애플리케이션 정보를 5개 사이트에서 얻을 수 있었다. 이는 일반적으로 공개된 웹 애플리케이션 보안 수준이 어느 정도인지를 잘 보여주는 사례이다.
애플리케이션 보안 위협에 대한 애플리케이션 수준 점검
그럼 이제 필자가 관리하는 웹 사이트의 애플리케이션 보안 수준을 살펴보기로 하자. 지난번에 애플리케이션 취약점이 잘 해소되지 않는 10대 원인을 말한 바 있다. 이를 기준으로 나를 돌아보기 위해 그 10대 원인을 보자.
애플리케이션 취약점이 잘 해소되지 않는 10대 원인
·보안 정책이 애플리케이션까지 강제하지 않는다.
·보안 담당자가 애플리케이션 개발과정이나 유지보수 과정에 별로 관심이 없다.
·개발표준이 없거나 있어도 잘 지켜지지 않는다.
·문서화가 잘 안되어 있다.
·애플리케이션의 수가 너무 많다
·입력 패턴이 다양하다.
·업무 개발 프로젝트에서 빨리 개발해 실행시키는데 주된 관심을 가진다.
·기존 애플리케이션의 유지보수 담당자가 땜질식으로 수정해 왔다
·업무별로 유지보수 조직이 다른 경우 이 조직 사이에 알력이 크다.
·아웃소싱 개발자가 프로젝트 완료 후 사후 관리에 관심을 가지지 않는다.
그럼 이런 사항을 기반으로 10가지 질문에 답을 해보자. 각 문항에 대하여 항상 그렇다는 2점, 그럴수도 있고 아닐수도 있다면 1점, 아니다는 0점을 주고 그 합을 구한다.
애플리케이션 보안에 대한 수준 점검표
1. 우리회사의 보안정책에는 애플리케이션에 적용할 상세 내용이 정의돼 있다.
2. 애플리케이션 개발 표준안이 있고 이는 개발과정에서 항상 지켜진다.
3. 애플리케이션 개발 표준안이 있고 이는 유지보수 과정에서 항상 지켜진다.
4. 개발된 애플리케이션은 개발 보고서 문서만으로도 충분히 그 내용이 파악된다.
5. 업무별 애플리케이션의 종류와 수는 정확히 파악되고 있으며 재사용하고 있다.
6. 입력 항목은 패턴별로 정의되어 항상 사전 정의된 규칙에 의하여 확인된다.
7. 개발 프로젝트가 지연되어도 테스트 과정에서 필요한 요건들은 건너뛰지 않는다.
점검표에 의한 점수별 판단
◆ 0~7점 : 우리의 애플리케이션은 취약점이 많이 노출되어 있을 가능성이 있으며 즉시 이에 대한 대응이 필요하다. 해커가 관심만 가지면 취약점을 통하여 시스템에 위해를 가할 수 있다.
◆ 8~13점 : 그리 심각하지는 않으나 애플리케이션 보안에 대하여 보다 더 관심을 가져야 한다. OWASP 10대 취약점을 줌심으로 장기적인 해결책을 모색한다.
◆ 14점 이상 : 애플리케이션 보안이 잘 이루어지고 있는 편이다. 그러나 취약점이 있을 수 있으므로 지속적인 관심을 가져야 한다.
점검표의 각 항목에 대한 이해
1. 우리 회사의 보안정책에는 애플리케이션에 적용할 상세 내용이 정의되어 있다.
일반적으로 보안 정책에는 권한관리, FW, IPS 등 보안 장비에 대한 환경 구성 내용, 내부 망에 대한 설계 기준, 애플리케이션 사용 규정, 외부 망 접근 규정을 정의하고 있으나 애플리케이션 취약점은 간과하고 있는 경우가 많다. 이런 경우 애플리케이션을 개발하고 유지보수하는 단계에서 애플리케이션이 취약점을 내포한 채로 운영 단계로 넘어가게 된다. 이를 방지하려면 보안정책에 반드시 애플리케이션 취약점에 대한 정의와 그에 대한 대응 방침이 마련돼야 한다.
2. 애플리케이션 개발 표준안이 있고 이는 개발과정에서 항상 지켜진다.
애플리케이션 보안 취약점을 정의하고 이를 회피하기 위한 방안이 마련되었으면 이는 반드시 개발 표준안에 포함시켜 전 개발자에게 공지되어 지켜져야 한다. 많은 경우 애플리케이션 개발 표준안은 개발용 코드 작성 기준, 제어규칙, 프레임웍 정의, 문서화 규정, 코드내의 설명문 규칙, 버전 관리 방법 등을 포함하지만 애플리케이션 취약점은 빠져있는 경우가 있다. 이는 앞의 보안 표준에서 애플리케이션 취약점 대응방침이 정의되지 않은데서도 기인하지만, 취약점 대응방침이 있더라도 실제 개발 표준안에는 이를 간과하여 빠지는 경우가 발생한다.
또한, 만들어진 표준안은 개발자에 의하여 반드시 지켜져야 한다. 시간에 쫓기는 프로젝트인 경우 개발자는 프로그램 코딩을 빨리 마무리하려는 데에 관심을 주로 관심을 가지게 되며 개발 표준안을 지키는데는 상대적으로 소흘히 하게 된다.
3. 애플리케이션 개발 표준안이 있고 이는 유지보수 과정에서 항상 지켜진다.
유지보수 과정에서도 애플리케이션 개발 표준안은 아주 중요하다. 개발과정에서 품질관리를 통하여 개발 표준안이 지켜져도, 유지보수 과정에서의 품질활동은 상대적으로 잘 이루어지지 않게 된다. 이렇게 되면 개발 프로젝트 종료 이후 수정되거나 새로 만들어진 애플리케이션 프로그램들은 취약점을 내포한 채로 운영환경에 적용될 가능성이 높아진다.
개발자와 유지보수자가 다른 경우이거나 업무의 변경이 빈번히 일어나는 기업인 경우 유지보수과정에서도 적용시간을 단축시키는데 주된 관심을 가지게 되고, 이 과정에서 개발표준안은 점점 더 지켜지지 않게 된다.
4. 개발된 애플리케이션은 개발 보고서 문서만으로도 충분히 그 내용이 파악된다.
개발표준안에 문서와 규정이 없거나, 있더라도 잘 지켜지지 않은 경우 그 애플리케이션을 이해하려면 프로그램의 원시 코드를 처음부터 분석할 필요가 발생하게 된다. 이에 따라 프로그램의 유지보수성은 더 떨어지게 되고, 유지보수자는 프로그램을 분석해 필요한 부분을 고치려고 하기보다는 자기가 코드를 새롭게 만들어 넣으려는 유혹에 빠지게 된다. 이런 유혹은 프로그램 재사용성을 떨어뜨릴 뿐만 아니라, 유지보수 과정에서 시간이 늘 부족하게 만들고, 프로그램의 품질은 저하된다. 또한 테스트 과정에서도 정교한 테스트가 불가능하여 취약점이 프로그램에 남아있게 된다.
5. 업무별 애플리케이션의 종류와 수는 정확히 파악되고 있으며 재사용하고 있다.
기업내의 업무 애플리케이션은 종류도 아주 다양하고 그 수도 많은 경우가 대부분이므로 관심을 가지고 유지보수하지 않는 경우 애플리케이션을 변경하거나 추가하고자 할 때 재사용하기 보다는 새롭게 코드를 추가하는 쪽으로 작업이 이뤄지게 된다. 이는 앞의 4항에서 설명한 것과 같이 품질이 저하되고, 취약점이 제거되지 않은 상태로 가동환경에 적용될 가능성이 높아진다.
6. 입력 항목은 패턴별로 정의되어 항상 사전 정의된 규칙에 의해 확인된다.
가장 단순한 형태의 애플리케이션 공격중의 하나가 입력값을 변경해 가면서 취약점을 찾아내 공격하는 것이다. 따라서 입력 데이터가 실제 비즈니스 로직에 전달돼 처리되기 전에 입력값이 사전 검증이 이뤄져야 한다. 이런 입력값은 공통 컴퍼넌트에 의해 검증하는 것이 바람직하며, 입력값을 패턴별로 분석해 사전에 정의하고 그 규칙에 의하여 검증할 수 있도록 해야 한다.
7. 개발 프로젝트가 지연돼도 테스트 과정에서 필요한 요건들은 건너뛰지 않는다.
프로젝트 진행과정에서 일정이 지연되면 프로젝트 관리자는 일정을 단축하기 위한 다양한 시도를 하게 된다. 이런 유혹들 중에 빠지지 않는 것이 테스트 과정의 단축이다. 테스트 과정을 거치지 않거나 일부 항목을 제외하게 되면 프로그램의 품질이 저하되는 것은 당연하고, OWASP에서 제시하고 있는 취약점 중 입력값 검증 부재, 버퍼오버플로우, 접근통제, 인증 및 세션 관리, 에러 처리 부분을 정상적으로 검증하지 못할 가능성이 높아진다.
8. 최초 개발된 애플리케이션부터 현재 버전까지의 애플리케이션이 형상관리가 되고 있다.
개발 프로젝트 과정에서 개발돼 처음 적용한 버전의 애플리케이션은 형상관리가 잘 이루어져 있는 경우가 대부분이다. 그러나 시간이 지나면서 유지보수 단계의 여러가지 이유로 프로그램은 점점 누더기가 돼 있을 가능성이 있다(이 문제는 앞의 3, 4, 5항목에서 언급한 이유로 인해 발생할 가능성도 있다). 이는 취약점을 프로그램 내에 내포할 가능성이 높으므로 형상관리를 통해 해소해야 한다.
9. 유지보수 과정에서 2개 이상의 업무에 영향을 주는 프로그램인 경우 이를 처리하는 명확한 절차가 있고 이 절차는 반드시 지켜진다.
특정한 프로그램이 2개 이상의 업무에 영향을 주거나 공통적으로 사용하는 경우, 이 프로그램에 대한 유지보수 요구는 주인없이 떠돌기 쉽다. 어떤 문제에 대한 해결 책임이 2개 이상의 조직에 있는 경우 어느 한쪽이 나서서 그 책임을 맡는 경우는 거의 없다고 봐야 한다. 이런 상황이 발생하면 이 문제는 상황이 악화되어 상위 관리자에 의한 강제적인 업무 조정이 이루어질 때까지 문제 해결을 하는데 필요한 소중한 시간을 소모하게 되며, 이는 품질을 떨어뜨린다.
10. 아웃소싱한 개발자의 프로그램은 언제, 누가 개발했는지 관리가 되며, 프로젝트 종료후 일정 기간까지는 개발자와 유지보수 담당자가 함께 유지보수를 진행한다.
문서화가 아주 잘된 프로그램도 개발자가 아닌 다른 사람이 유지보수하려면 프로그램을 이해하는데 상당한 시간이 필요하게 된다. 이런 시간을 단축하고 유지보수의 효율을 높이기 위하여 인수인계 과정을 엄격하게 관리해야 하며, 일정기간 개발자와 유지보수자가 함께 유지보수 기간을 갖도록 하는 것이 바람직하다.
애플리케이션 개발 표준안 점검
우리의 현실을 이해했다면 보다 구체적으로 개발표준안에는 보안 위협에 대응하기 위해 어떤 부분이 포함돼야 하는지를 살펴보자. 여기에서도 강조하고 싶은 부분은 보안 위협에 대응하기 위한 방안을 만들면 개발자, 운영자 모두 피곤해한다는 점이다. 이런 귀차니즘을 극복하지 못하면 아무리 좋은 개발 표준안이라 하더라도 무용지물이 된다.
개발표준안에 구체적으로 담을 내용들 중 일부는 다음 번에 이야기할 웹 애플리케이션 보안 위협 대응방안에서 다시 중복되어 언급될 수도 있다. 애플리케이션 개발자는 자신이 만든 애플리케이션이 완벽할 수 없다는 점을 생각하여야 하며, 개발 표준안에는 이를 고려하여 테스트 과정에서 이런 부분들이 간과되지 않도록 해야 한다. 애플리케이션 개발자를 위한 개발표준안에 담겨야 할 항목들을 부분별로 나누어 보면 다음과 같다.
1. 접근 권한 부분
접근 권한은 그룹별, 사용자별로 할당돼야 하며, 애플리케이션의 업무 단위, 페이지 단위, 시스템의 각종 자원 (데이터베이스, 시스템 명령어, 파일 등) 단위로 세분화 돼 정의해야 한다. 특히 수퍼유저 권한은 어떤 경우에도 애플리케이션에 허용되어서는 안된다.
2. 에러 처리 부분
에러 처리 결과는 시스템에 로그로 남겨져야 하며, 운영자, 관리자 이외에는 접근이 허용돼서는 안된다. 화면상으로 에러 정보가 나가지 않도록 하여야 한다. 이 글 앞부분의 에러처리를 보면 에러 내용이 화면상에 표현되면서 취약점을 노출시키고 있다는 점을 상기해야 한다.
에러 로그는 등급별로 관리되어야 한다. 보통은 치명적(Fatal), 시스템 실패 유발(Error), 경고(Warning), 일반 정보(Information), 디버깅(Debugging)으로 구분할 수 있다. 이 항목별 로그 기록 수준은 환경 변수로 만들어 두는 것이 좋으며, 디버깅용 코드는 애플리케이션 배포 이전에 반드시 정리돼야 한다.
3. 테스트
테스트 과정에서 개발자가 직접 테스트를 수행하는 경우, 이 항목에는 이런 값이 들어올 것이라는 점을 미리 생각하고 테스트를 진행하는 경우가 대부분이다. 예를 들면 주민등록번호라는 입력 필드를 만들고 프로그래머가 테스트 하는 경우, 이 필드에 문자열은 절대 들어오지 않을 것이라는 것을 가정하고 숫자만 테스트 하는 경우가 발생한다. 이런 상황을 예방하기 위해 테스트 과정에서는 반드시 개발자가 아닌 제3자가 테스트에 참여하도록 한다.
테스트 항목은 OWASP의 10대 취약점 항목을 바탕으로 반드시 점검할 항목을 선정하고 이는 반드시 지켜지도록 해야 한다.
다음호에는 OWASP의 10대 취약점을 기준으로 웹 애플리케이션 보안 대응 방법에 대해 정리해보도록 하자. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
