Improvement Mechanism for Automatic Web Vulnerability Diagnosis

웹취약점 자동진단 개선방안

Abstract

Due to the development of smartphone technology, as of 2020, 91.9% of people use the Internet[1] to frequently acquire information through websites and mobile apps. As the number of homepages in charge of providing information is increasing every year, the number of applications for web vulnerability diagnosis, which diagnoses the safety of homepages, is also increasing. In the existing web vulnerability check, the number of diagnostic personnel should increase in proportion to the number of homepages that need diagnosis because the diagnosticians manually test the homepages for vulnerabilities. In reality, however, there is a limit to securing a web vulnerability diagnosis manpower, and if the number of diagnosis manpower is increased, a lot of costs are incurred. To solve these problems, an automatic diagnosis tool is used to replace a part of the manual diagnosis. This paper explores a new method to expand the current automatic diagnosis range. In other words, automatic diagnosis possible items were derived by analyzing the impact of web vulnerability diagnosis items. Furthermore, automatic diagnosis identified possible items through comparative analysis of diagnosis results by performing manual and automatic diagnosis on the website in operation. In addition, it is possible to replace manual diagnosis for possible items, but not all vulnerability items, through the improvement of automatic diagnosis tools. This paper will explore some suggestions that can help improve plans to support and implement automatic diagnosis. Through this, it will be possible to contribute to the creation of a safe website operating environment by focusing on the parts that require precise diagnosis.

스마트폰 기술의 발전으로 인하여 2020년 기준 전 국민의 91.9%가 인터넷 이용[1]하여 수시로 홈페이지와 모바일 앱을 통해 정보를 습득하고 있다. 정보제공을 담당하는 홈페이지의 수가 점점 늘어남에 따라 홈페이지의 안전성을 진단하는 웹취약점 진단 신청수도 매년마다 증가하고 있는 상황이다. 기존 웹취약점 점검은 진단원이 수작업으로 홈페이지를 모의 해킹하여 취약점을 진단했기 때문에 진단대상 홈페이지 수에 비례하여 진단인력이 늘어나야한다. 하지만 현실적으로 웹취약점 진단인력 확보에 한계가 있고, 진단인력을 늘렸을 경우 많은 비용이 발생한다. 이러한 문제점 해결을 위해 자동진단 도구를 사용하여 수동진단의 일부를 대체하고 있다. 본 논문에서는 현재의 자동진단 범위를 확대하기 위한 방안을 새롭게 제안하였다. 즉, 웹취약점 진단항목의 영향도를 분석하여 자동진단 가능 항목을 도출하고, 실제 운영 중인 홈페이지에 수동 및 자동진단을 수행하여 진단결과에 대한 비교 분석을 통해 자동진단 가능항목을 파악하였다. 또한 자동진단 개선방안을 제시하여 자동진단 도구 개선을 통해 모든 취약점 항목은 아니지만 가능한 항목에 대해서 수동진단을 대체할 수 있다. 이를 통해서 진단 및 정밀진단이 필요한 부분에 집중하여 안전한 홈페이지 운영환경 조성에 기여할 수 있을 것이다.

I. 서론

최근 스마트폰 기술의 발전으로 인하여 우리는 수시로 홈페이지와 모바일 앱을 통해 정보를 습득하고 있다. 정보제공을 담당하는 홈페이지의 수와 침해사고 신고접수[2]가 지속적으로 증가함에 따라 홈페이지의 안전성을 진단하는 웹취약점 진단 신청수도 매년마다 증가하고 있는 상황이다.

다만 진단원의 수가 한정적이기 때문에 모든 홈페이지를 진단원이 모의해킹으로 안전성 진단을 수행하기에는 한계점이 존재한다. 따라서 웹취약점 자동진단을 통해 수동진단에 소요되는 시간을 감소시킬 필요성이 있다. 하지만 자동진단이 만능은 아니다. 자동진단의 경우 진단 시 프로그램에 설정된 점검항목을 홈페이지에 전송하여 취약여부를 파악하므로 홈페이지 구성항목 및 게시물이 많은 경우 홈페이지 서비스에 지장을 초래하여 서버를 다운시키는 경우도 발생한다. 이 문제 때문에 실제 운영 중인 홈페이지에 웹취약점 진단을 수행하는 경우 수동진단을 선호한다. 수동진단의 경우 전문적인 지식을 가진 진단원이 홈페이지의 구성을 먼저 파악한 후 점검항목별 취약점이 존재하는지 진단하기 때문이다. 다만 진단원이 수동으로 모든 항목을 점검해야 하기 때문에 자동진단에 비해 취약점 발견 정확도는 향상되나 시간이 많이 필요하다. 자동진단 방식을 개선하여 수동진단 만큼 정확도를 향상시키고 홈페이지 서비스에 영향을 완화한다면 보다 많은 홈페이지에 대한 웹 취약점 진단이 가능할 것이다. 웹취약점 진단항목 중 영향도를 분석하고 실제 홈페이지에 수동 및 자동진단을 수행한 후 결과를 분석하여 수동진단 대체가 가능한 자동진단 항목을 파악하고 진단에 활용하는데 목적이 있다.

Ⅱ. 웹취약점 진단방법 연구

1. 웹취약점 자동진단 방식

웹취약점 자동진단 방식은 오픈소스 프로그램을 이용하거나 상용 솔루션을 이용하는 방식이 있다. 다만 웹 취약점 진단 정확도나 홈페이지 서비스에 영향을 미치지 않도록 진단항목별 옵션을 적용하려면 상용소프트웨어를 이용하여 진단하는 것이 좋다.

또한 웹취약점 진단을 의뢰하여 수행하는 기관은 대다수 공공기관으로 해당기관에 웹취약점 자동진단을 하기 위해서는 CC(Common Criteri) 및 GS(Good Software) 인증을 받은 소프트웨어를 사용해야한다.

2. 웹취약점 수동진단 방식

웹취약점 수동진단은 우선 홈페이지에를 구성하는 기능(회원가입, 로그인, 게시판 등) 및 디렉토리 구조를 파악한 후 오픈소스 자동진단 도구(Nikto, Skipfish 등)를 통해 숨겨진 경로 및 정보를 분석한다. 외부에 노출되는 정보를 수집하여 디렉토리 구조, 관리자 페이지 존재 여부, 웹서버 정보 노출여부, 게시물 내용 및 첨부파일에 중요정보 노출여부를 파악한다.

수집된 정보를 바탕으로 진단영역의 우선순위를 부여[3]한 후 웹취약점 진단항목을 기준으로 주요 정보통신기반시설 기술적 취약점 분석 평가 상세 가이드[4]의 진단 방법을 참고하여 웹프록시 도구를 이용 수동진단을 수행 취약점 존재여부를 파악한다.

3. 웹취약점 진단항목

웹취약점 진단 기준은 OWASP(The Open Web Application Security Project)에서 발표하는 OWASP TOP 10[5], CWE/SANS TOP 25[6], 국정원 8대 취약점, 행정안전부의 웹취약점 점검 항목 21개가 있다. 여러 개의 진단기준 중 행정안전부의 웹 취약점 점검항목 21개[표 1]를 기준으로 웹취약점 진단방법을 KISA에서 발행하는 소프트웨어 개발 보안 가이드[7]를 참조 및 분석하여 진단 시 홈페이지 서비스에 미치는 영향도를 파악할 것이다. [표 1]은 행정안전부 웹 취약점 점검항목 21개 항목 목록이다.

표 1. 행정안전부 웹취약점 점검항목(21개)[8]

4. 영향도에 따른 자동진단 가능성 웹취약점 항목

웹취약점 진단방법을 분석하여 홈페이지 서비스에 영향을 최소화하여 취약점 자동진단이 가능한 항목을 분류하여 가능항목 12개[표 2]와 불가능 항목 9개[표 3]로 정리하였다.

표 2. 영향도에 따른 자동진단 가능항목

표 3. 영향도에 따른 자동진단 불가능 항목

Ⅲ. 웹취약점 수동 및 자동진단 결과비교(1차)

1. 진단결과 비교를 위한 시나리오 및 체크리스트

웹 취약점 자동진단 수행결과를 수동진단과 비교하여 취약점 발견유무에 대한 비교를 위해 운영 중인 홈페이지 3개를 선정하여 진단을 진행하였다. 자동진단의 경우 홈페이지 취약점 자동진단 상용제품 3개를 이용하여 진단을 수행하고, 수동진단의 경우 웹 프록시 툴을 이용하여 모의해킹을 진행하였다.

수동 및 자동진단 결과비교를 위한 수행절차를 [그림 1]과 같이 정리하였다.

그림 1. 수동 및 자동진단 결과비교 수행절차

또한 수동진단과 자동진단을 비교하기 위한 진단 시나리오를 구상하였으며 [표 4]와 같이 정리하였다.

표 4. 수동 및 자동진단 결과 비교 시나리오

수동진단에 발견된 취약점을 자동진단 시 동일하게 진단이 가능하거나 더 많은 취약점을 찾을 수 있는지 비교하고, 상용 자동도구를 사용하여 수동진단을 대체할 수 있는지 판단하기 위해 기능성, 사용성, 확장성, 정확성, 효율성과 같이 5개 분야 34개 체크리스트 항목 [표 5]을 작성하여 상용 자동도구에 대해 평가하였다.

다만 상용 자동화도구 명칭에 대해서는 A, B, C로 명칭 하여 자세한 제품명은 생략하였다.

표 5. 웹 취약점 자동진단 수행 체크리스트

2. 취약점 발견 결과 비교

홈페이지 3개 대상에 대한 수동 및 자동진단을 수행한 결과 수동진단에 발견된 취약점 중 자동진단을 통해 2개 제품에서는 크로스사이트 스크립트가 발견되었으며, 한 개 제품에서는 취약점을 발견하지 못하였다. 수동 및 자동진단 결과를 [표 6]과 같이 정리하였다.

표 6. 수동 및 자동진단 결과 비교표 1차

수동진단에서 발견한 웹취약점을 자동진단 수행 시발견하지 못한 사유를 상용 자동진단 제품의 진단패턴을 분석하여 [표 7]과 같이 정리할 수 있었다.

표 7. 수동진단 발견취약점 자동진단 시 미발견 사유

자동진단 특이사항으로 3번 홈페이지에 대해서는 3 개 제품모두 수집 및 진단단계가 마무리 되지 않아 결과 산출이 되지 않았으며, A제품의 경우 1번 홈페이지진단 시 일부 접속 장애가 발생하였다.

진단 시 스레드 값이 서버 환경에 맞지 않아 서버 부하가 발생하여 지연 및 장애가 발생하는 것으로, 진단 도중 스레드 값을 변경하고 싶었지만 기능이 존재하지 않아 변경할 수 없었다. 자동진단 사용도구에서 지연 및 장애 발생 시 대처하는 부분에 대해 [표 8]과 같이 정리해보았다.

표 8. 응답지연 및 장애발생 대처

3. 웹취약점 자동진단 도구 종합 평가

웹취약점 자동도구 검증 체크리스트를 바탕으로 자동진단 결과에 대해 기능성, 정확성, 사용성, 확장성, 효율성 5개 기준으로 상용제품에 대해 [표 9]와 같이 평가하였다.

표 9. 상용 자동진단도구 종합 평가표

A제품의 평가점수가 높은 이유는 자동진단 도구에 점검패턴에 대한 추가기능이 존재하여 해당 기능을 이용하여 웹취약점에 대한 발견 정확도를 향상시킬 수 있었기 때문이다. 상용 자동진단 제품별 우수한점과 미흡한 점을 평가하여 [표 10]과 같이 정리해 보았다.

표 10. 자동진단 도구 제품별 종합평가 의견

Ⅳ. 웹취약점 수동 및 자동진단 결과비교(2차)

1. 수동 및 자동진단 비교 2차 필요성 및 준비사항

수동 및 자동진단 결과비교 1차의 경우 자동진단 도구를 통해 수동진단으로 찾은 웹취약점의 발견이 가능한지 파악하고 대체 가능여부를 확인하려 하였으나, 표본이 적고 진단이 미완료된 상황이 발생하였다.

영향도에 따른 진단가능 웹취약점 항목 12개에 대한 대체 가능성을 추가적으로 비교하기 위해 사전에 자동진단 도구에 해당항목에 대한 진단패턴을 검토한 후 자동진단을 수행하였다.

홈페이지별 자동진단 시 소요되는 시간과 서버 부하 정도를 파악하여 진단수행에 문제점이 없는지 확인하고 수동진단 대비 취약점 발견 정확도를 비교하였다. 1차의 경우 3개 홈페이지 대상을 통해 비교하였으나, 2차에서는 진단 가능성 및 발견 정확도의 정확한 비교를 위해 8개 대상에 대해 진단을 수행하였다.

2. 수동 및 자동진단 2차 결과

1차와 같은 방법으로 취약점 자동 및 수동진단을 수행하였으며, 결과는 아래와 같이 정보대상, 제품, 소요 시간, 발견취약점, 수동결과, 비고로 [표 11]과 같이 정리하였다.

서버부하는 모든 대상에서 발생하지 않아 제외하였다.

표 11. 수동 및 자동진단 2차 결과

home7에 대한 자동진단 시 A제품에서 자체적으로 정체 현상이 발생하였다. 정체현상 발생 사유는 전자정부 표준프레임워크로 홈페이지를 개발한 경우 파라미터 인자값에 취약점 패턴을 입력하면 에러페이지로 리 다이렉션 되는데 있다. 이 현상을 A제품이 통신오류로 감지하여 취약점 진단패턴마다 일정시간 정지하였다가 전송하는데 문제점이 있다.

홈페이지를 구성하는 메뉴 및 배치된 컨텐츠의 양이 많거나, 상용 자동진단 제품의 진단패턴의 많고 적음에 따라 전체 진단소요시간의 차이가 발생하였다.

또한 에러페이지나 SSL 관련 문제점으로 자동진단수행 시 지연되거나 미완료되는 경우도 발생하였다.

해당 결과를 통해 크로스사이트 스크립트나 데이터평문전송 취약점에 대해서는 대체적으로 자동진단이 가능한 것으로 판단되며, 관리자페이지 노출, 위치공개 취약점은 발견하지 못하였다.

운영체제 명령어 실행과 웹 서비스 메소드 설정 공격취약점의 경우 취약점이 발견되지 않아 자동진단 여부에 대한 검증이 이루어지지 못했다.

Ⅴ. 효율적인 자동진단을 위한 개선방안

1. 자동진단 가능 항목에 대한 문제점 및 개선사항

영향도를 분석하여 웹취약점 진단항목 21개중 자동진단 가능항목 12개를 제안하였으며, 수동 및 자동진단비교 1, 2차를 통해 자동진단의 수동진단 대체 가능 여부를 분석해 보았다.

웹취약점 자동진단 결과와 상용 자동진단 도구의 진단패턴 등을 분석하여 취약점 항목별 자동진단 시 문제점 및 가능성, 개선필요사항에 대해 [표 12]와 같이 정리해 보았다.

표 12. 점검항목별 자동진단 가능성 및 개선 필요 사항

위에서 분석하여 제시한 개선사항을 반영할 경우 자동진단 가능항목을 개선사항과 함께 [표 13]과 같이 요약하여 정리하였다.

표 13. 자동진단 가능항목과 개선필요사항

2. 자동진단 소요시간 관련 개선

웹취약점 자동진단 결과 홈페이지 메뉴 및 컨텐츠 양에 따라 적게는 2분에서 많게는 20시간 이상 소요되었으며, 상황에 따라 미완료된 홈페이지도 존재하였다.

메뉴 및 컨텐츠 양이 적어 1시간 이내로 진단이 가능한 홈페이지는 바로 자동진단이 가능하겠지만 20시간 이상 소요되는 상황인 경우 모니터링을 통한 진단의 이상 유무(장애) 파악에 한계가 있다.

따라서 자동진단에 대한 스케쥴링 기능을 추가하여 일정 시간 진단을 수행하였으나, 완료되지 않은 경우 진단을 일시정지하고 차후에 이어서 진단을 이어서 수행할 수 있도록 중간에 정지하는 기능이 존재해야한다.

일부 상용제품의 경우 진단을 시도하면 중간에 정지가 불가능하고, 현재 진단상황을 저장하는 기능이 존재하지 않아 진단시간이 오래 걸리는 홈페이지의 경우 시도조차 불가능한 부분이 있다. 그러므로 진단을 일시 중지하고 진단 수행 내용을 저장하는 기능이 제공되어야 한다.

또한 진단패턴을 세분화하여 진단원이 진단패턴을 선택함으로써 필요한 부분만 진단한다면 진단 소요 시간을 단축시킬 수 있다.

3. 기타 개선사항

홈페이지 취약점 자동진단 시 장애 및 지연상황에 대비하기 위해서는 로그 기록 및 분석이 중요하다고 생각된다.

자동진단 시 현재 수행중인 진단내용을 로그을 통해 기록해야 하며, 만약 진단패턴을 전송했을 때 지연 현상이 발생한다면 알림을 통해 바로 안내하여 현재 홈페이지에 장애가 발생하였는지 판단해야한다.

물론 자동진단 도구에 홈페이지를 접속하여 지연 현상 및 장애의 발생유무를 자동으로 판단해 준다면 더할 나위가 없다고 생각된다.

자동진단 상용도구 제품들은 로그는 저장하지만 분석 도구를 제공하지 않고 저장된 로그를 메모장 및 문서 편집 프로그램을 통해 열람한 후 일일이 분석해야 하므로 불편함이 존재한다. 로그를 저장하는 기능과 더 불어 분석 도구가 같이 탑재된다면 문제점 사후 분석에 도움이 될 것이다.

Ⅵ. 결론

본 논문에서는 점점 증가하는 홈페이지로 인하여 웹 취약점 진단대상이 증가하는 상황에서 수동진단만으로 모든 홈페이지를 진단하려면 진단인력이 계속 적으로 증원되어야 한다. 웹취약점 진단항목 중 자동진단 가능 항목 12개를 우선 제시하고, 1, 2차에 걸친 수동 및 자동진단 결과비교를 통해 수동진단을 자동진단으로 대체 가능한 웹취약점 항목을 파악하였다.

본 논문에서 제안하는 방법을 활용하여 웹취약점 자동진단 도구가 개선된다면 현재 수동진단 중인 취약점 중 11개 항목을 자동진단으로 대체할 수 있으며, 기존에 웹취약점 자동진단을 위해 판매되는 상용솔루션의 성능을 향상시킬 수 있다.

이에 따라 상용 솔루션의 웹취약점 자동진단 결과에 대한 신뢰를 증가시켜 상용솔루션을 구매하여 자동진단을 수행하는 기관 및 업체가 증가할 것이다.

자동도구를 사용한 모든 취약점 항목에 대한 취약점 진단은 현재 불가능하나 영역을 분리하여 수동진단과 자동진단을 병행한다면 조금 더 많은 대상에 대한 진단수행이 가능해지며, 수동진단을 통해 정밀진단이 필요한 영역에 더 많은 시간을 할애하여 안전한 홈페이지 운영환경 조성에 기여할 수 있을 것이다.

다만 운영중인 홈페이지를 대상으로 연구가 이루어진 상황으로, 서비스에 대한 영향도를 고려하여 12개 항목에 대한 수동 및 자동 진단결과를 비교한 것으로 9 개 항목에 대한 부분은 제외되었다. 차후 전체 21개 항목에 대한 수동진단을 대체할 수 있도록 개선방안을 도출하기 위한 추가 연구가 필요하다.