보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

웹 취약점 점검 현명하게 하는 법

2022.11.02

563

01. 보다 성공적인 웹 취약점 점검을 위하여

디지털 전환이 가속화됨에 따라 곳곳에 분산된 IT 자산의 보안 취약점을 노리는 사이버 공격이 증가하면서 능동적인 취약점 관리의 중요성은 날로 높아지고 있다. 그중에서도 웹 취약점 공격은 대체로 잘 알려져 있는 전통적인 공격이지만, 꾸준히 피해를 일으키며 좀처럼 개선이 이뤄지지 않고 있는 상황이다.

더 나아가 해킹된 홈페이지에서 유출된 개인정보가 다크웹 등에서 유통되며 2차, 3차 피해를 야기할 수 있다는 점을 고려할 때, 웹 취약점에 대한 보안 강화는 정보 보안의 관점에서 결코 간과해서는 안 될 부분 중 하나라 할 수 있다. 웹 취약점 점검자들이 주기적으로 운영 중인 홈페이지나 신규·리뉴얼 홈페이지에 대한 취약점 점검을 수행하며 취약점 존재 여부를 파악하고, 더 나아가 조치 권고 및 조치 지원을 통해 취약점 제거의 과정을 반복하면서 보다 안전한 홈페이지 서비스가 지속될 수 있도록 최선의 노력을 기울이고 있는 이유이기도 하다.

웹 취약점 점검을 성공적으로 수행하기 위해 고려해야 할 요소로는 점검자의 진단 능력과 세밀성, 그리고 기능의 복잡성, 접근성, 환경성을 들 수 있다. 가장 먼저 진단 능력은 점검자의 취약점 발견 스킬을 말하며 세밀성은 홈페이지를 구성하는 기능을 꼼꼼하게 목록화하고 점검하여 아주 작은 부분도 놓치지 않는 섬세함을 말한다. 복잡성은 개발 및 운영 중인 홈페이지에 배치된 기능이 얼마나 복잡한지에 대한 정도, 접근성은 회원가입이 없어 별도의 계정 발급 및 계정 없이 점검해야 하는 상황의 척도, 마지막으로 환경성은 홈페이지를 구성하는 서버의 가용성이 낮아 취약점 점검 강도를 낮게 설정해 점검해야 하는지에 대한 여부를 가리킨다.

이 중에서도 웹 취약점 점검 시 가장 중요한, 그리고 웹 취약점 점검자에게 제일 요구되는 부분은 세밀성이라 할 수 있다. 아무리 점검자의 점검 스킬이 뛰어나고 점검 대상이 되는 홈페이지가 덜 복잡하다고 하더라도, 홈페이지에 배치된 기능을 꼼꼼하게 살피지 않으면 결국 발견하지 못하는 취약점이 발생할 수 밖에 없기 때문이다. 다시 말해 웹 취약점 점검자가 홈페이지에 배치된 기능을 빠짐없이 파악한 후 보다 꼼꼼하게 취약점의 존재 여부를 알아챌 수 있는 세밀성은, 웹 취약점 점검에 있어 가장 기본적이면서도 핵심적인 조건이라 할 수 있다.

이러한 배경에서, 웹 취약점 점검 시 점검자의 ‘세밀성’을 높여 줄 수 있는 몇 가지 팁을 예시와 함께 공유하고자 한다.

02. 웹 취약점 점검 시 고려해야 할 사항

1) 크로스 사이트 스크립트 점검 시 우회를 염두에 두고 점검하라

크로스 사이트 스크립트(Cross Site Script) 취약점은 웹 취약점 점검 시 자주 발견되는 취약점 중 하나로, ▲게시물과 같은 저장 영역에 스크립트 구문을 입력하여 실행 여부를 파악하는 스토어드 크로스 사이트 스크립트(Stored Cross Site Script), ▲통합 검색 및 게시물 검색 영역에 스크립트 구문을 입력하고 실행 여부를 파악하는 리플렉티드 크로스 사이트 스크립트(Reflected Cross Site Script), 그리고 ▲URL 입력란에 스크립트 구문을 입력하여 실행 여부를 파악하는 DOM 크로스 사이트 스크립트(DOM Cross Site Script)로 분류된다. 각 취약점 유형별 점검 방법을 정리해 보면 다음과 같다.

[표 1] 크로스 사이트 스크립트 유형별 점검 방법

이렇듯 여러 영역에서 크로스 사이트 스크립트 취약점이 존재할 경우, 홈페이지 유지보수 담당자 및 개발자는 보통 아래 2가지 방법으로 조치하게 된다.

A. 홈페이지 사용자로부터 입력받은 모든 값을 서버에서 검증하여 스크립트 구문이 입력될 경우 필터링하여 실행되지 않도록 조치.
B. XSS 필터(Cross Site Scripting Filter)를 적용하여 크로스 사이트 스크립트 구문이 필터링 되어 실행되지 않도록 조치.

크로스 사이트 스크립트의 근본적인 조치 방법은 스크립트 구문이 입력될 경우 필터링하여 해당 문구를 삭제하거나 변환하여 실행되지 않도록 하는 것이다. 다만 필터링해야 하는 문구가 현실적으로 너무 많거나 홈페이지에 개발된 기능이 많을수록 적용 영역이 넓어지기 때문에 XSS 필터를 사용해 조치하는 것이 좋다.

web.xml 파일에 XSS 필터를 적용하였으나 멀티파트 폼(multipart/form-data)으로 전송되는 데이터에 대해서는 필터를 적용하지 않을 경우 크로스 사이트 스크립트 취약점이 조치되지 않고 그대로 존재하게 된다. 해당 취약점을 진단하는 방법은 아래와 같다.

① 게시판 검색을 통해 스크립트 구문 입력 시 구문이 필터링 되어 실행되지 않음.

[그림 1] 스크립트 구문 입력 시 필터링 적용 화면

② 웹 프록시 툴에서 ‘Change Body encoding’을 클릭하고, Content-Type을 ‘multipart/form-data’로 변경한 후 스크립트 구문 입력 시 필터링을 우회하여 실행 가능함.

[그림 2] 필터링을 우회하여 실행 확인

웹 취약점 점검 시 일반적으로 입력하는 스크립트 구문에 대해서는 조치하여 실행되지 않도록 처리한 홈페이지는 많으나, ‘multipart/form-data’로 우회하여 입력하는 경우엔 스크립트 구문이 실행되는 사례가 종종 발생하므로 점검자는 필히 필터링을 우회해 점검할 필요가 있다. ‘multipart/form-data’에 대한 크로스 사이트 스크립트 취약점을 조치하려면, web.xml에 ‘multipart/form-data’로 전송된 데이터에 대해서도 필터를 적용해 주면 된다. 다만 멀티파트 필터 등록 시 XSS 필터 위에 추가해야 하며, 기존에 사용 중인 XSS 필터를 제거해서는 안 된다.

[그림 3] ‘멀티파트 폼(multipart/form-data)’ 필터링 조치 방법 <출처: 행정안전부>

2) 로그인 후 세션 만료 시간은 최대 10분

홈페이지에 로그인하여 사용하던 중 일정 시간 움직임이 없으면 자동으로 로그아웃되어 세선 정보가 만료되도록 설정해야 한다. 만약 세선이 만료되지 않거나 만료 시간을 너무 길게 설정하면, 악의적인 사용자가 만료되지 않은 그 틈을 타 불법적인 접근을 하는 것과 더불어 개인정보 탈취와 같은 악의적인 행위가 가능해진다. 또한 로그인 시 아이디에 동일한 세션 아이디가 발급되는 경우, 해당 값으로 해커가 아이디를 탈취해 로그인하는 것이 가능해지기 때문에 더욱 치명적일 수 있다.

로그인 후 세션 만료에 대한 부분은 한국인터넷진흥원(KISA)의 ‘주요 정보통신 기반 시설 기술적 취약점 분석 평가 방법 상세 가이드‘에서 ’불충분한 세션 만료‘로 분류돼 점검 대상에 속한다. 해당 가이드에 따르면 안전한 보안 설정 방법으로 세션 타임아웃 시간은 10분으로 권장되고 있다. 시간을 10분으로 설정한 것에 대해 KISA에 문의한 결과는 다음과 같았다.

“주요 정보통신 기반 시설 기술적 취약점 분석평가 상세 가이드 생성 당시, 설정 근거는 보안성과 편의성을 고려하여 관계자들이 상호 동의하 정해진 기준입니다. 때문에 해당 가이드는 법적 근거 하에 작성되었으며 세세한 판단 기준 근거에 대해서는 국내외 가이드 및 보안 전문가, 보안업계 교수 등의 자문을 참고하였음을 알려드립니다.” 실제 실험 결과나 논문을 참고한 것은 아니지만, 전문가들의 경험적 판단을 준용해 결정된 10분임을 알 수 있었다.

그렇지만 실제로 확인해 보면 많은 사용자들이 이용하는 인터넷 뱅킹이나 주요 기업 및 기관의 자동 로그아웃 시간이 짧게는 10분에서 길게는 8시간까지, 운영 주체의 임의대로 설정돼 운영되고 있음을 알 수 있었다. 다시 말해 홈페이지 별 세션 만료 시간은 제각각인 상황이며, KISA가 ‘주요 정보통신 기반 시설 기술적 취약점 분석 평가 방법 상세 가이드‘를 통해 기준을 10분으로 설정하기 전에는 웹 취약점 점검 시에도 점검자들이 기준을 잡기가 애매하여 섣불리 판단하기 어려운 부분이 존재했었다. 그러나 지금은 권고되는 기준이 분명한 바, 홈페이지 운영에 특이점이 존재하지 않는다면 이에 따라 판단하여 점검하면 되지 않을까 생각된다.

3) 에디터를 생성하여 점검하라

보통 홈페이지에 회원가입 및 로그인 기능을 제외하고 개발하는 경우가 많다 보니 게시물 작성 시 배치되는 에디터를 활용하여 공격하는 취약점에 대한 점검이 어려운 경우가 있다. 홈페이지 담당자를 통해 점검 전 임시 계정을 받은 후 점검하면 좋겠지만, 현실적으로는 불가능한 경우가 대부분이다.

에디터를 악용하는 취약점으로는 ▲에디터의 업로드 기능을 통해 웹쉘(web shell) 파일을 업로드하는 파일 업로드 취약점과 ▲업로드된 경로를 통해 시스템 파일을 다운로드하는 파일 다운로드 취약점이 가장 대표적이다. 더 나아가 에디터의 버전 정보가 노출되는 정보 누출 취약점도 발생할 수 있다. 이들에 대한 점검 방법은 아래 목록처럼 에디터마다 호출하는 파일의 존재 여부를 확인하는 것으로 시작한다.

[표 2] 에디터 별 호출 파일 목록

만약 홈페이지에 ‘/naverEditor/js/HuskyEZCreator.js’ 파일이 존재하는 것을 파악했다면, 아래 이미지처럼 영역에 smarteditor 생성 스크립트를 추가하여 에디터를 생성한다.

[그림 4] 그림4. smarteditor 생성 스크립트

그리고 생성한 에디터에 배치된 사진 버튼을 클릭해 파일 업로드 영역에 대한 취약점 점검이 가능하다.

[그림 5] smarteditor 이미지 업로드 페이지

4) 자동화 공격 취약점의 점검 영역을 확대하여 생각하라

KISA가 발간한 ‘주요 정보통신 기반 시설 기술적 취약점 분석·평가 방법 상세 가이드’ 중 ‘자동화 공격’의 취약점에 대해 이야기해 보려고 한다. 상세 가이드 상에는 ‘로그인 시도’, ‘게시물 등록’, ‘SMS 발송’ 등에 대한 정상적인 요청 정보를 1차적으로 식별하고, 해당 요청이 반복적으로 발생할 때 통제가 제대로 이루어지는지를 확인해야 한다고 기재돼있다.

일반적으로는 무작위 대입을 통한 로그인 시도로 취약한 계정의 존재 여부를 파악하고, 게시물 자동 등록을 통하여 홈페이지 서비스에 방해를 일으키는 요소가 존재하지는 않는지 점검하게 된다. 다만 위의 세 가지 영역에 제한을 두지 말고 홈페이지를 구성하는 모든 요소에 자동화 공격을 시도해 볼 것을 권장하는 바이다.

예를 들어 자동화 공격을 통한 회원 자동 가입이 가능하다면 홈페이지에 설정된 MaxUser 값을 초과하게 돼 회원가입을 더 이상 받을 수 없게 된다. 또 게시물에 대한 접근통제가 비밀번호로 설정된 민원 게시판의 경우, 비밀번호 자동 대입을 통해 타인의 게시물을 변조하거나 비밀 게시물 열람을 통한 개인정보 탈취가 이뤄질 수 있다. 이와 같이 동일한 패킷 또는 패킷의 일부분을 변조한 후 전송하여 취약점을 판단하는 자동화 공격의 영역을 보다 넓혀 활용한다면, 더욱 안전한 홈페이지 서비스 제공이 가능해질 것이다.

03. 웹 취약점 점검자에게 웹 취약점 점검자가…

지금까지 웹 취약점 점검을 수행하면서 점검자가 알아두면 좋은 팁, 보다 현명하게 점검하는 방법에 대해 살펴보는 시간을 가져보았다. 이게 정답도, 전부도 아니다. 위에서 언급한 내용뿐만 아니라, 공개되어 있는 무수히 많은 웹 취약점 가이드에 숨겨진, 잘 알려지지 않은 점검법들이 분명 무궁무진할 것이다. 그러나 이들 또한 고정되어 불변의 진리마냥 존재하는 것이 아니다. 언제든지 바뀔 수 있고, 변화하는 환경에 따라 새롭게 익혀야 하는 부분도 틀림없이 발생한다.

이에 점검자의 점검 스킬이라고 할 수 있는 이러한 점검법들을 서로서로 공유하는 분위기를 조성함으로써 웹 취약점 분야의 전반적인 점검 수준을 높여 나가는 게 중요하다고 생각한다. 지금도 이 순간에도 정신없이 홈페이지에 존재하는 취약점을 찾아내고자 노력하는 점검자들을 응원하며, ‘백짓장도 맞들면 낫다’라는 말을 명심하고 진화하는 웹 위협에 맞서 함께 힘을 모아 나갔으면 하는 바람이다.