웹 취약점 점검을 처음 맡으면 도구부터 찾게 되지만, 도구보다 먼저 정해야 할 것은 순서와 기록 방법입니다. OWASP Top 10 은 '무엇을 볼 것인가'의 목록으로 쓰기 좋고, 여기에 '어떤 순서로 보고 어떻게 적는가'를 더하면 혼자서도 꽤 체계적인 점검이 됩니다. 이 글은 허가받은 자기 서비스(또는 계약된 범위)를 점검한다는 전제입니다. 허가 없는 점검은 하지 않습니다.
0. 시작 전 — 범위와 계정을 서면으로
어떤 도메인·기능이 범위인지, 어떤 등급의 계정을 몇 개 쓸지(일반 2개 이상·관리자 1개가 좋습니다), 점검 시간대, 운영 데이터 보호 방법(테스트 데이터만 생성·삭제)을 적어 합의합니다. 점검 중 문제가 생겼을 때 연락할 사람도 정합니다.
1. 정찰 — 기능 목록 만들기
로그인·가입·비밀번호 찾기·검색·파일 업로드·결제·관리자 화면처럼 기능을 모두 적고, 각 기능이 어떤 요청(URL·메서드·파라미터)을 보내는지 프록시 도구로 잡아 목록을 만듭니다. 이 목록이 점검의 지도이자 보고서의 '점검 범위' 가 됩니다.
2. 순서 — 인증·세션 → 접근 통제 → 입력값
인증과 세션은 다른 모든 점검의 전제라 먼저 봅니다(계정 잠금, 세션 만료, 로그아웃 뒤 토큰 재사용). 다음은 접근 통제 — 최근 사고에서 가장 자주 나오는 유형입니다. 두 계정으로 로그인해 A 의 주문 번호를 B 의 세션으로 요청해 보는 것(IDOR), 관리자 URL 을 일반 계정으로 직접 여는 것이 기본입니다. 그 다음이 입력값(인젝션·XSS)입니다.
3. 도구는 보조, 판단은 사람
자동 스캐너는 설정 오류·오래된 버전·단순 인젝션을 빠르게 찾지만, 접근 통제와 업무 로직 결함은 거의 못 찾습니다. 프록시 도구(Burp Suite·ZAP)로 요청을 직접 바꿔 보는 수동 점검이 핵심이고, 스캐너 결과는 '확인해 볼 후보' 로 다룹니다.
4. 기록 — 발견 즉시, 재현 가능하게
나중에 몰아서 쓰면 재현이 안 되는 항목이 꼭 생깁니다. 발견 즉시 요청·응답 캡처와 순서를 적습니다. 등급은 '얼마나 쉽게, 무엇까지 할 수 있는가' 로 매기고 근거를 한 줄 적습니다(예: 인증 없이 전체 고객 목록 열람 → 높음).
5. 보고서와 재점검
보고서는 개발자가 바로 고칠 수 있게 씁니다 — 어느 요청, 어떻게 재현, 어떻게 고치면 되는지. 조치가 끝나면 같은 절차로 재점검하고 '조치 확인' 을 남깁니다. 점검은 보고서가 아니라 재점검에서 사라진 항목으로 완성됩니다.
처음 점검이라면 접근 통제 하나만 끝까지 해 보세요. 가장 많이 나오고, 가장 설명하기 쉽고, 고치면 효과가 가장 큰 항목입니다.
댓글