[최종 프로젝트]3차 멘토링 - 수행계획서 실무 가이드, 진단 결과 리뷰 및 시나리오 설계
개요
3차 멘토링은 크게 4개 파트로 진행되었다. 수행계획서/결과보고서 실무 템플릿 리뷰, 취약점 진단 기준 및 개념 정리(약점/취약점/위협/리스크), 웹·모바일 취약점 진단 결과 보고서 초안 검토, 그리고 모의해킹 시나리오 설계다.
1. 수행계획서 및 결과보고서 실무 가이드
수행계획서 작성 시점과 역할
실무에서 수행계획서는 투입 직후 일주일 이내에 작성한다. 일주일 동안 노트북 세팅, 출입 카드 발급, 시스템 권한 발급 등 환경 세팅을 하면서 동시에 수행계획서를 작성하는 흐름이다.
- PM: 프로젝트 전반적인 가이드라인 작성
- PL: 수행계획서 작성 (큰 프로젝트 기준)
- 소규모 사업(2~3명): 보통 막내가 작성 (템플릿에 이름/이메일/전화번호만 바꾸는 수준)
수행계획서 핵심 구성요소
| 항목 | 내용 |
|---|---|
| 진단 개요 | 멘트는 복붙 가능. 애플리케이션 점검이므로 거의 동일 |
| 진단 대상 | IP 또는 도메인 |
| 일정 | 표 형식 또는 캘린더 형식 |
| 진단 도구 | Burp Suite, Wireshark, Nmap, APK Tool, Frida 등 약 10개 |
| 진단 인원 | PM/PL/담당 구분, 웹/모바일/인프라 분류 |
| 진단 항목 (핵심) | “주통기 기반 + 어떤 항목을 추가/제거하여 N개 항목으로 점검합니다” 형태로 명확히 기입 |
진단 항목 기준의 중요성
회사마다 진단 항목이 다르다. SK Shielders는 자체 점검 항목을 보유하고 있고(취약점 진단팀 약 20여 개, EQST 약 50개), 고객사 담당자에게 “어떤 기준으로, 몇 개 항목으로 점검합니다”를 명확히 전달하고 승인받아야 한다.
결과보고서
수행계획서 템플릿 밑에 진단 결과를 붙이면 결과보고서가 된다. PM은 프로젝트 종료 약 일주일 전에 최종 결과 리뷰를 진행하여, 위험도 높은 항목/개인정보 노출 항목 등을 정리해 PPT로 만들어 CISO 등에게 발표한다.
2. 취약점 관련 핵심 개념 정리
약점(Weakness) vs 취약점(Vulnerability)
멘토가 강조한 매우 중요한 구분이다.
약점은 소프트웨어의 결함이다. Integer를 써야 할 곳에 String을 쓴 것, 버퍼를 필요 이상으로 크게 잡은 것 등 코드 레벨의 문제점을 말한다.
취약점은 약점 중에서 실제 공격에 악용 가능한 것만을 의미한다. PreparedStatement를 잘못 써서 SQL Injection이 가능하면 그것이 취약점이다.
취약점 vs 위험도(파급력)
“취약점은 데브 사이트든 프로덕션이든 상관없이 존재한다. 데이터가 없어도, 서버가 꺼져 있어도 코드에 인젝션이 가능하면 취약점이다. 위험도와 취약점을 반드시 분리해서 생각해야 한다.”
- 취약점 여부: 공격 가능한 형태로 되어 있으면 취약점 (데이터 유무, 서비스 운영 여부와 무관)
- 위험도/파급력: 같은 SQL Injection이라도 민감정보가 많은 회사는 파급력이 높고, 고객 DB가 없는 회사는 파급력이 낮다
- 실무 보고서에는 취약점의 상/중/하와 별도로 영향도의 상/중/하가 따로 존재한다
위협 / 자산 / 리스크
| 개념 | 정의 | 은행 비유 |
|---|---|---|
| 위협 (Threat) | 피해를 입힐 가능성이 있는 행위자 또는 요소 | 복면 쓰고 칼 든 사람이 은행에 앉아 있음 |
| 취약점 (Vulnerability) | 약점과 결함. 있어야 할 것이 없는 상태 | CCTV 고장, 비상벨 없음 |
| 자산 (Asset) | 보호해야 할 데이터/자원 | 은행의 돈 |
| 리스크 (Risk) | 위협 + 취약점 + 자산이 결합했을 때의 실제 위험 | 세 가지가 다 있어야 도난 위험 발생 |
우리 프로젝트에서는 영향도/파급력은 고려하지 않고, 취약점 여부(양호/취약)만 판단하면 된다.
3. 점검 기준 및 항목 관련 피드백
점검 기준 원칙
“우리가 만든 기준은 우리가 정한 것이다. 기준을 정할 때만 고민하고, 점검할 때는 기준에 따라 일관되게 수행해야 한다.”
여러 기준(주통기, 전자금융, OWASP 등)을 섞어서 참고하다 보면 혼란이 생긴다. 기준을 따라가면 책임 회피가 가능하다. “주통기 기준으로 했습니다”라고 하면 된다.
AI 생성 내용 주의사항
진단 항목 설명을 AI로 생성한 부분에서 다수의 환각(hallucination)이 발견되었다.
- 주통기에 없는 “크리덴셜 스터핑”이 자동화 공격 항목에 포함됨
- 통신 구간 암호화에 “MITM”이 포함됨 (스니핑과 MITM은 다른 개념)
- 인프라 점검 항목이 웹 항목에 섞여 들어감
“AI의 기준 재가공은 위험하다. 기준은 원문 그대로 복붙하는 것이 가장 안전하다.”
인프라 항목 분리
블랙박스 웹 점검에서 확인 불가능한 인프라 항목(스크립트 매핑 노출, 웹 서버 프로세스 권한 등)은 제거해야 한다. 웹 점검 기준은 주통기 웹 항목으로 심플하게 통일한다.
4. 웹 취약점 진단 결과 리뷰
SQL Injection (양호)
JPA로 구현되어 인젝션 포인트가 없다. 다만 멘토 의견으로는 인젝션은 우선순위가 높은 항목이고 모든 기수가 포함했으므로, 심사위원이 “왜 안 만들었냐”고 질문할 가능성이 높다. 시나리오에 필요하면 별도 페이지를 만들어서 구현한다.
SSTI (취약)
이메일 인증 시 이름 입력란에 템플릿 인젝션 구문을 삽입하면 SSTI가 발생한다. 현재 RCE까지 연결이 안 되는 상태(Thymeleaf 버전에서 RCE 가능 함수들이 필터링됨)이므로, 반드시 RCE까지 성공시켜야 시나리오 진행이 가능하다.
SSRF (취약)
챗봇의 뉴스 요약 기능에서 URL을 서버가 직접 요청하므로, URL 변조 시 SSRF가 발생한다. AWS 메타데이터 v2이므로 직접적인 IMDS 접근은 차단된다.
보고서 작성 시 발생 위치가 반드시 필요하다. 챗봇 이미지도 포함해야 담당자가 어디인지 파악할 수 있다.
XSS - Stored (취약)
게시판에서 저장형 XSS가 발생한다. 단순 스크립트 실행(alert)에 그치지 않고, 토큰(JWT) 탈취 시나리오까지 연결하여 실제 피해 가능성을 입증하는 것이 고품질 보고서의 핵심이다.
보고서 용어 통일도 중요하다. “저장형 XSS”와 “Stored XSS”를 혼용하지 않는다.
CSRF
CSRF 토큰이 없어서 취약으로 판단했으나, 멘토 의견은 다소 과하게 잡았다는 것이다. CSRF는 중요 기능(어드민 기능, 권한 변경 등)에 한해서 점검한다. 좋아요/조회수 같은 일반 기능까지 다 잡으면 모든 대기업이 취약해진다.
불충분한 인증 (삭제 권고)
마이페이지 비밀번호 재인증 로직이 로그인 API를 그대로 재사용하여, 응답 코드를 200으로 변조하면 인증 우회가 가능하다. 멘토는 이 코드를 깔끔하게 삭제하고 양호로 가거나, 별도 confirm/reset 엔드포인트를 만들라고 권고했다.
프로세스 검증 누락 vs 불충분한 인가
| 구분 | 프로세스 검증 누락 | 불충분한 인가 |
|---|---|---|
| 조작 위치 | 클라이언트 (JavaScript, 로컬 스토리지 등) | 서버 (프록시에서 파라미터 변조) |
| 예시 | 로컬 스토리지의 role을 admin으로 변경 | API 요청의 파라미터를 변조하여 타인 정보 접근 |
클라이언트에서 값을 조작하여 인가를 우회하면 프로세스 검증 누락, 프록시에서 파라미터를 변조하여 권한을 상승하면 불충분한 인가다.
기타 항목
- 비밀번호 복잡성 정책: 1234 같은 짧은 숫자로 설정 가능하므로 취약
- 자동화 공격: 로그인 횟수 제한, 실패 누적, 잠금 정책 미비
- 통신 구간 암호화: SSL 적용으로 주통기 기준 양호
- 불필요한 메소드: OPTIONS는 CORS preflight로 정상 동작이므로 양호
- 오류 메시지 노출: Nginx 엔진명 노출, DTO 필드명 노출
양호 항목 작성 가이드
실무에서는 양호 항목 보고서를 쓰지 않지만, 학습용으로 작성해두면 나중에 실무에서 복붙하여 재활용할 수 있다. 양호를 기술할 때 “취약점 없음”이 아닌 “발생 가능한 기능이 존재하지 않음”으로 구체적으로 기술해야 정확하다.
5. 모바일 취약점 진단 결과 리뷰
루팅 탐지 (취약)
Frida에서 함수 하나만 후킹하면 루팅 탐지를 우회할 수 있으므로 취약이다. “쉽게”의 기준은 시간 개념이다. 우회하는 데 걸리는 시간이 짧으면 취약, 오래 걸리면 양호. 과거 금융권 가이드에서는 Java 단 탐지 = 쉽게 우회 = 취약, Native(C/.so) = 어렵게 = 양호로 판단했다.
소스 코드 난독화 (취약)
R8/ProGuard 기본 난독화 수준보다 낮게 설정하여 취약이다. 금융권 기준으로는 무료 난독화 = 취약, 상용 솔루션 = 양호로 판단한다.
Frida 탐지 (취약)
Native 단에서 탐지하고 있으나 후킹으로 우회 가능하여 취약이다. 실무에서는 “탐지 로직이 있느냐/없느냐”로만 판단하는 협상이 가능한 경우도 있다.
메모리 내 중요 정보 노출 (검토 필요)
Objection으로 메모리 덤프 시 평문 비밀번호가 발견되어 취약이다. 다만 JWT 토큰은 출입카드와 같아서 메모리에 존재하는 것이 정상이므로, 평문 비밀번호 노출만으로 취약 판단하는 것을 권고받았다.
화면 캡처 방지 / 백그라운드 보호 (취약)
금융권에서는 필수지만 의료 서비스에서는 필수가 아니다. “금융은 필수, 비금융은 선택이지만 우리 프로젝트에서는 취약으로 잡기로 했다”고 설명할 수 있어야 한다.
앱 백업 설정 (재확인 필요)
allowBackup이 true로 보고되었으나, 실제 매니페스트에서는 false다. 디버그 모드 APK로 테스트한 것으로 추정되므로 릴리즈 + 사이닝된 APK로 재검증이 필요하다.
인텐트 강제 실행 (양호)
메인 액티비티만 exported=true, 나머지는 false다. 주의할 점은 ADB shell에서 am start로 테스트할 때 루트 권한이면 exported와 무관하게 모든 액티비티를 실행할 수 있다는 것이다. 반드시 일반 권한에서 테스트해야 하며, 이 실수는 경력자도 많이 했다고 한다.
기타 모바일 항목
- 무결성 검증: APK 디컴파일 → 값 변조 → 리패키징 → 재설치 성공으로 취약
- 에뮬레이터 탐지: 탐지 코드 자체가 없으므로 취약
- 중요 정보 저장: SharedPreferences에 비밀번호가 Base64 인코딩(암호화 아님)으로 저장되어 취약
- 딥링크: 커스텀 스키마 + exported=true, 웹뷰에서 임의 URL 로딩 가능
- SSL Pinning: 피닝이 구현되어 있으므로 양호 (우회 가능 여부와 무관)
- 과도한 권한: 사용하지 않는 권한(카메라, 외부 저장소 등)이 매니페스트에 선언되어 취약
6. 모의해킹 시나리오 설계
시나리오 1: SSTI → 클라우드 해킹 → 내부망 침투
| 단계 | 내용 |
|---|---|
| 1 | 회원가입 이메일 인증에서 SSTI → RCE 획득 |
| 2 | EC2 메타데이터에서 IAM Role 임시 자격 증명 탈취 (IMDS v2) |
| 3 | S3 민감 정보 탈취, Bedrock 무단 호출 |
| 4 | SSM으로 Bastion 서버 침투, VPN 파일 탈취 |
| 5 | VPN으로 내부망 접근 |
| 6 | 게이트웨이 서버 bash history에서 Samba 크리덴셜 획득 |
| 7 | Samba 서버 접근 (일반 권한) → 루트 권한 상승 |
| 8 | 루트로 KeePass DB 탈취 → 크랙 |
| 9 | 전체 크리덴셜로 내부망 DB 서버 접근 → 직원/진료 기록 탈취 |
시나리오 2: SQL Injection → 관리자 탈취 → 클라이언트 공격
| 단계 | 내용 |
|---|---|
| 1 | SQL Injection으로 DB 크리덴셜 탈취 |
| 2 | 관리자 해시 패스워드를 레인보우 테이블로 크랙 |
| 3 | 관리자 로그인 → 고객 정보(이메일, 핸드폰) 획득 |
| 4 | 고객에게 딥링크 전송 |
| 5 | 딥링크 → 악성 웹뷰 → JS Bridge로 네이티브 접근 |
| 6 | 카메라/연락처/SD카드 등 모바일 정보 탈취 |
시나리오 설계 원칙
- 시나리오 간 취약점이 겹치지 않도록 구성
- 파급력이 높은 취약점 순으로 배치 (인젝션, XSS, RCE, SSRF 등)
- 결과물도 임팩트 있게 구성 (데이터 10만 건 탈취 vs 10건은 임팩트가 다르다)
7. 보고서 작성 품질 가이드
필수 요소
- 발생 위치: 어떤 메뉴, 어떤 URL에서 발생하는지 반드시 기재
- 공격 구문: 정확한 입력값을 텍스트로 기재 (이미지만으로는 유니코드, 공백 등 구분 불가)
- 증적 이미지: 해당 기능의 화면 캡처 + 공격 결과 캡처
두괄식 작성
진단 결과란에 한 줄로 핵심을 먼저 쓰고 상세는 아래에 기재한다.
“비밀번호 변경 시 1234와 같은 짧은 비밀번호 변경이 가능함”
담당자는 이 한 줄만 읽으면 된다.
보고서에 거짓 정보 주의
“URL 입력값으로 받는 지점이 존재하지 않음”처럼 실제로 존재하는 것을 없다고 쓰면 안 된다. AI가 생성한 내용은 반드시 검증 후 사용하고, 근거가 불확실하면 주통기 원문을 그대로 복붙하는 것이 안전하다.
8. 화이트박스 / 블랙박스 점검
실무에서는 거의 100% 블랙박스 점검이다. 소스 코드를 제공받더라도 참조만 하고 블랙박스로 점검하는 경우가 대부분이다. 화이트박스 전수조사는 정적 분석 도구가 수행하며, 사람이 하는 것보다 성능이 좋다.
9. Action Items
| 기간 | 항목 |
|---|---|
| ~3/17 | 시나리오 설계 최종 픽스 → 멘토에게 카톡으로 공유 및 컨펌 |
| 3/18~3/21 | 시나리오 구현, 환경 구성, 공격 수행, 데모 영상 촬영 |
| 3/22~3/27 | 모의해킹 결과 보고서 초안 작성 |
| 4차 멘토링 (3/28) | 취약점 진단 보고서 최종본 + 시나리오 초안 보고서 검토 |
| 5차 멘토링 (최종) | 최종 보고서 및 PPT 컨펌, Q&A, 면접 팁 |
핵심: 취약점 진단 보고서는 AI 환각 수정 + 인프라 항목 제거 + 템플릿 적용만 최소한으로 수정하고 시간을 많이 쓰지 않는다. SSTI → RCE 연결은 시나리오 1의 핵심이므로 반드시 해결한다.
댓글 남기기