74. 모의 해킹 (Penetration Test) 수행 내역 기반 취약점 재점검

⚠️ 이 문서는 자동화된 스캐너 툴(Nessus 등)만으로는 절대 찾아낼 수 없는 비즈니스 로직의 논리적 결함(권한 우회, 금액 변조 등)을 화이트 해커(전문가)가 수동으로 뚫어본 '모의 해킹(Penetration Test)' 결과 보고서를 바탕으로, 발견된 치명적 취약점들이 실제 오픈 전에 소스 코드 레벨에서 완벽하게 패치(Remediation)되었는지 감리인이 깐깐하게 재점검하고 추궁하는 보안 감리 지침을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 자동화 스캐너는 "자물쇠가 녹슬었네"는 찾지만, "비밀번호 찾기 버튼을 3번 누르면 관리자 창이 열리네" 같은 창의적인 비즈니스 해킹은 오직 인간 해커(모의 해킹)만이 뚫어낼 수 있다. 감리인은 이 해커의 뚫기 성적표를 검증하는 재판관이다.
  2. 가치: 개발팀이 "버그 고쳤습니다"라고 대충 땜질 처방(Frontend 차단 등)만 하고 넘어가는 관행을 박살 내고, 백엔드(서버) 로직 자체를 뜯어고쳐 근본적인 취약점을 100% 제거하도록 강제하여 대형 정보 유출 사고를 오픈 전에 차단한다.
  3. 기술 체계: 감리인은 모의 해킹 보고서의 공격 페이로드(Payload, 예: Burp Suite 프록시 변조 값)를 보고, 개발자가 제출한 조치 결과서의 소스코드(예: Prepared Statement 적용, 세션 토큰 검증 추가)가 올바른 처방전인지 크로스 체크(Cross-check)한다.

Ⅰ. 자동화 스캐너의 한계와 인간 해커(모의 해킹)의 필요성

로봇은 정해진 매뉴얼만 검사할 뿐, 사기 치는 법을 모른다.

  1. 로직 취약점 (Logical Vulnerability)의 무서움:
    • 쇼핑몰에서 10,000원짜리 신발을 살 때, 중간에 오가는 패킷을 가로채어 price=10으로 조작해서 서버로 보냈더니 10원에 결제가 되어버렸다 (파라미터 변조).
    • 일반 회원으로 로그인한 뒤 URL 창에 ?role=admin이라고 쳤더니 갑자기 전 직원의 연봉 열람 페이지가 열렸다 (수직적 권한 상승 우회).
    • 이런 기상천외한 우회 공격은 아무리 비싼 자동화 진단 툴을 돌려도 '문법적인 버그'가 아니기 때문에 절대 찾아낼 수 없다.
  2. 모의 해킹 (Pen-test) 수행의 의무화:
    • 금융권이나 공공 대형 사업에서는 오픈 전 반드시 외부 전문 보안 업체(화이트 해커)를 고용해 모의 해킹을 수행하고 그 결과표(취약점 보고서)를 산출물로 제출해야 한다.
  3. 감리인의 참전 (조치 검증):
    • 감리인은 화이트 해커가 아니다. 감리인은 화이트 해커가 쥐여준 "우리가 뚫어보니 이 10군데가 뻥 뚫려있네요"라는 보고서를 들고, 개발팀이 이 구멍을 정말 튼튼한 시멘트(근본적 코드 수정)로 막았는지, 아니면 종이판자(눈가림 코드)로 대충 가려놨는지 검사하는 수사관 역할을 한다.

📢 섹션 요약 비유: 자동화 스캐너가 아파트의 '창문이 열렸는지 닫혔는지'만 기계적으로 검사하는 드론이라면, 모의 해킹은 직접 1층 배관을 타고 올라가 환풍구를 뜯고 거실로 침투해 보는 도둑(화이트 해커)의 실전 테스트입니다. 감리인은 도둑이 침투한 경로가 찍힌 블랙박스 테이프를 보고, 집주인(개발자)이 그 환풍구를 진짜 철창으로 용접해서 완벽하게 막았는지 흔들어보고 확인하는 현장 감시관입니다.

Ⅱ. 감리인의 예리한 눈: 땜질 처방(눈가림) 적발 기법

개발팀의 "조치 완료했습니다"라는 말을 절대 그대로 믿으면 안 된다.

  1. 프론트엔드(Client-side) 검증의 꼼수 적발:
    • 모의 해킹 결과: "게시판에 <script>alert(1)</script>를 넣으면 XSS 해킹이 터짐."
    • 개발팀 조치: "웹 브라우저(자바스크립트) 입력창에서 특수문자를 못 치게 막았습니다. 조치 끝!"
    • 감리 지적 사항: "브라우저 검증은 프록시(Burp Suite 등)로 중간에서 우회하면 그만입니다. 반드시 백엔드(Java/Python 서버) 소스코드 필터에 replace() 나 XSS 방어 필터 라이브러리(Naver Lucy 등)가 추가된 것을 코드로 증명하세요."
  2. 세션/토큰 검증 누락 적발:
    • 모의 해킹 결과: "내 글만 지워야 하는데, HTTP 요청에서 article_id=5를 남의 글 번호인 id=9로 바꾸면 남의 글이 막 지워짐 (IDOR 취약점)."
    • 감리 지적 사항: "수정된 백엔드 코드를 보니, 서버에 올라온 id=9 글의 진짜 주인이 현재 접속 중인 세션(Session Token)의 사용자 ID와 100% 일치하는지 백엔드에서 크로스 체크(권한 인가)하는 if 문이 없습니다. 다시 짜오세요."

📢 섹션 요약 비유: 도둑이 담장을 넘는 취약점이 발견되자, 개발팀이 담장을 높이는 대신 마당에 "도둑질 금지"라는 표지판(프론트엔드 방어)만 세워두고 조치했다고 우기는 꼴입니다. 감리인은 표지판 따위는 발로 차버리고, 진짜 철조망(백엔드 로직 방어)을 두르고 세콤(서버단 세션 검증)을 설치한 견적서와 공사 사진(소스코드)을 가져올 때까지 절대 승인 도장을 찍어주지 않습니다.

Ⅲ. 잔존 위험 수용(Risk Acceptance)과 이행 확약

모든 구멍을 다 막으면 좋겠지만, 현실적인 비즈니스 타협이 필요할 때가 있다.

  1. 아키텍처 구조적 한계 (Unfixable Issues):
    • 취약점을 고치려다 보니, 도입해 둔 상용 프레임워크 패키지 자체를 버려야 하거나 수개월 치의 코드를 다 엎어야 하는 끔찍한 상황(예: 암호화 통신 불가한 구형 연동 모듈)이 발생할 수 있다.
  2. 보완 통제 (Compensating Control):
    • 코드를 직접 고칠 수 없다면, 감리인은 차선책으로 "그럼 이 취약점을 찌르는 트래픽은 앞단 웹 방화벽(WAF)에서 해당 패턴을 룰로 박아서 무조건 드랍(Drop) 시켜라"와 같은 인프라적 방어 우회로를 인정해 준다.
  3. 위험 수용 확인서 (Sign-off):
    • 감리인은 개발사가 못 고치고 남겨둔 잔존 위협(Residual Risk) 리스트를 싹 다 모아, 발주 기관의 최고 보안 책임자(CISO)에게 들이민다.
    • "이 위험을 알고도 시스템을 오픈하시겠습니까? 오픈하다 털리면 CISO님 책임입니다"라는 확약서에 결재(Risk Acceptance)를 받아 문서로 남겨야만 감리가 종료된다.

📢 섹션 요약 비유: 집에 불이 날 위험(취약점)이 발견되었는데, 집을 다 부수고 다시 지을 돈이 없어 개발사가 쩔쩔맵니다. 감리인은 "그럼 집을 부수지 않는 대신, 각 방에 무조건 소화기(웹 방화벽) 3대씩 비치해라. 그리고 불이 나면 전적으로 집주인(CISO)이 책임진다는 각서에 도장 찍어라"라고 법적 책임을 명확히 한 뒤에야 입주 허가(시스템 오픈)를 내주는 깐깐한 행정 절차입니다.