Day 31 — 아르고스(Argus) 진단 모듈 9개 추가와 Progress UI·Docker 라우팅 정비

서론

"수동 진단·이행 점검에 이어, 아르고스(Argus)에 진단 모듈 9개를 더 붙였습니다. 오픈 리다이렉트(1-5)부터 에러 정보 노출(6-1)까지 SK쉴더스 웹/API 취약점 진단 가이드라인에 맞춘 탐지 로직을 넣고, 전 모듈 Progress UI와 Docker 쪽 통신 예외도 고쳤습니다. 프론트 대시보드와 백엔드 모듈 연동을 정리합니다."

이전에 만든 모듈 6개에 이어 1-5·3-2·3-4~3-6·4-1·4-2·5-2·6-1 등 9개를 추가하고, Progress UI와 Docker probe URL 라우팅을 맞춰 두었습니다.

1. 개요와 공통 연동 내용

기존 명세(DIAGNOSIS_MODULES.md)의 모듈 6개(2-2, 6-2, 7-1~7-4) 말고, 이번에 구현·정리한 자동화 진단 모듈 9개는 아래와 같습니다. 판정·분류는 SK쉴더스 웹/API 취약점 진단 가이드라인을 기준으로 합니다.

ID	제목	장	엔진	핵심 질문
1-5	검증되지 않은 리다이렉트와 포워드	1	`httpx+zap`	외부 URL로 열리는 redirect·CORS·crossdomain 오설정이 존재하는가?
3-2	인증 실패 횟수 제한	3	`httpx`	연속 로그인 실패 시 임계치 잠금 및 Rate Limit 방어 기제가 실행되는가?
3-4	관리자 페이지 분리 여부	3	`httpx`*	admin·user 자산이 호스트, 서브도메인, 로그인 경로에서 모두 격리되어 있는가?
3-5	검색엔진 정보 노출 가능성	3	`httpx`	robots.txt 정책 및 noindex/nofollow 메타 태그가 안전하게 설정되었는가?
3-6	백업·테스트 파일 존재 여부	3	`httpx`	시스템 백업(`.bak`) 및 환경 설정(`.env`) 파일이 외부 GET 요청으로 열리는가?
4-1	쿠키·웹 스토리지 조작 가능성	4	`httpx`	보안 속성 위배, 타 계정 세션 쿠키 재사용 및 토큰 변조가 허용되는가?
4-2	인증(세션·토큰) 값 안전성	4	`httpx`	JWT 토큰 강도 검증, 동시 중복 로그인 및 로그아웃 무효화가 정상 동작하는가?
5-2	요청/응답 주요정보 포함 여부	5	`httpx`	이메일, 연락처, 실명(PII) 데이터가 마스킹 없이 응답에 노출되는가?
6-1	오류페이지 정보 노출	6	`httpx+zap`	퍼징(Fuzz) 공격 시 스택 트레이스 및 SQL 구조, 내부 경로가 반사 유출되는가?

* 주의: 3-4 모듈은 매니페스트 상 engine: httpx로 정의되어 있으나, 실서버 대상의 물리적 HTTP 웹 프로브를 송신하지 않고 api-tree 및 verify-report.json 설정을 파싱하는 정적 휴리스틱 구조 분석 방식으로 연동됩니다.

① 모든 모듈에 실시간 진행률 UI (Progress) 추가

진단을 돌리는 동안 현재 단계, 진행률, 보낸 요청 수를 대시보드에서 실시간으로 볼 수 있게 연결했습니다.

백엔드 Progress 처리: backend/app/services/diagnosis_progress.py가 인메모리 상태를 관리하고(GET /api/diagnosis/progress), progress_reporter.py가 모듈 실행 과정을 prepare, phase, endpoint_progress, step_progress, zap_phase 단계로 나눠 기록합니다.
프론트엔드 연결: frontend/src/components/DiagnosisPage.tsx가 실행 상태를 주기적으로 받아 화면에 표시합니다. 1-5, 3-2, 3-4, 3-5, 3-6, 4-1, 4-2는 공통 헬퍼로 같은 방식의 진행률을 표시하고, 본문 처리와 퍼징 요청이 많은 5-2, 6-1은 성능을 위해 내부 단계(httpx_pii / httpx_fuzz)에서 직접 상태를 관리하게 했습니다.

② 로컬 vs Docker 환경 Probe URL 라우팅 규칙 통일

문제 원인: 백엔드 Docker 컨테이너 안에서 localhost:8080으로 요청하면 외부 호스트가 아니라 컨테이너 자신(Loopback)에 연결됩니다. 그래서 스캔 요청이 대상에 가지 않고 본문 수집도 0건이 됐습니다.
통일한 규칙: 호스트 OS에서 직접 실행할 때는 localhost를 그대로 쓰고, Docker Compose에서는 ARGUS_PROBE_HOST=host.docker.internal 환경 변수를 확인해 실제 요청 주소만 바꾸도록 했습니다. zap_util.py의 probe_url, verify_service.py, 각 모듈의 targets.py의 probe_base_url에 적용했습니다. 대시보드와 결과 리포트에는 읽기 쉽게 localhost를 계속 보여 줍니다.

③ 프론트엔드 옵션 패널 및 API POST Body 매핑 규격

각 모듈을 개별 제어하기 위해 프론트엔드가 요청 본문에 실어 보낼 REST API JSON 바디 루트 키와 config.yaml 글로벌 영속 오버라이드 설정 키 명세를 1:1 매퍼 매핑했습니다.

1-5 모듈: POST body 키: g15 / config 키: diagnosis_1_5 / 패널 속성: g15DiagnosisOptions.ts, isG15Stats
3-2 모듈: POST body 키: g32 / config 키: diagnosis_3_2 / 패널 속성: g32DiagnosisOptions.ts, isG32Stats
3-4 모듈: POST body 키: 없음 (원클릭 기동) / 패널 속성: isG34Stats 명세 바인딩
3-5 모듈: POST body 키: g35 / config 키: diagnosis_3_5 / 패널 속성: g35DiagnosisOptions.ts, isG35Stats
3-6 모듈: POST body 키: g36 / config 키: diagnosis_3_6 / 패널 속성: g36DiagnosisOptions.ts, isG36Stats
4-1 모듈: POST body 키: g41 / config 키: diagnosis_4_1 / 패널 속성: g41DiagnosisOptions.ts, isG41Stats
4-2 모듈: POST body 키: 없음 (config 파일 기반 제어) / config 키: diagnosis_4_2 / 패널 속성: isG42Stats
5-2 모듈: POST body 키: g52 / config 키: diagnosis_5_2 / 패널 속성: g52DiagnosisOptions.ts, isG52Stats
6-1 모듈: POST body 키: g61 / config 키: diagnosis_6_1 / 패널 속성: g61DiagnosisOptions.ts, isG61Stats

데이터 심층 스캔이 필요한 5-2·6-1 모듈에는 스캔 범위를 고를 수 있는 smoke / exhaustive / custom 프리셋 탭 3개를 대시보드에 넣었습니다.

2. 입/출력 값 검증 부재 영역 (1-5)

── 1-5. 검증되지 않은 리다이렉트와 포워드 모듈

무엇을 확인하는지: 외부 URL로 열리는 오픈 리다이렉트(Open Redirect), CORS 설정 오류로 인한 SOP 우회, crossdomain.xml 정보 노출을 찾습니다. targets.py와 redirect_rules.py로 판정을 자동화하고, probes.py가 httpx를 실행하며 zap_scan.py가 보조합니다.
검사 흐름: Base URL과 인벤토리 트리를 분석한 뒤, 오픈 리다이렉트가 의심되는 쿼리 파라미터에 미리 정한 외부 주소(redirect_sink_base)를 넣어 봅니다. 이어서 Origin 헤더를 임의의 사이트로 바꾼 CORS 요청과 크로스 도메인 자원 조회를 함께 수행하고, 필요하면 ZAP 동적 스캔 규칙(40031 / 10028)으로 차단 여부를 다시 확인합니다. 대시보드 모달에서 수집 범위(probe_mode), check_request_url, check_request_body 등을 바꿀 수 있습니다.

3. 취약한 접근 통제 관리 영역 (3-2, 3-4, 3-5, 3-6)

── 3-2. 인증 실패 횟수 제한 모듈

보완 조치 및 설계 명세: 무차별 대입 공격(Brute Force) 차단을 위해 연속 패스워드 실패 시 발동되는 임계치 잠금 정책 및 계정 보호(Rate Limit) 가드의 유무를 자동 판정합니다 (응답 메시지의 구조적 동일성만 대조하는 6-2 오류 처리 모듈과는 모두 분리되어 작동합니다). lockout_rules.py 검증기가 핵심 판정을 담당합니다.
동적 검증 및 동작 흐름: login_discovery_service 엔진이 추출해 낸 로그인 엔드포인트를 기반으로 가상 테스트 어카운트를 매칭한 뒤, 틀린 패스워드 조합 인자(wrong_password)를 기본 12회 연속 전송(max_attempts)합니다. 이후 검증기가 HTTP 429 Too Many Requests, 423 Locked 또는 403 Forbidden 상태 코드 전환 여부를 체크하고 Retry-After 헤더 배출 및 오류 텍스트 바디 컨텍스트의 실시간 변화 추이를 연산하여 잠금 정책의 적합성을 판정합니다. 프론트엔드 옵션 패널에서 시도 임계치를 3~25회 사이로 오버라이드 조율할 수 있습니다.

── 3-4. 관리자 페이지 분리 여부 모듈

보완 조치 및 설계 명세: 최고 관리자 및 백오피스 관리 채널이 일반 사용자 대외 서비스 대역과 호스트, 서브도메인, 로그인 URL, 추측 가능 경로 수준에서 안전하게 격리되어 보호받고 있는지 구조적 분석을 진행합니다. targets.py가 인벤토리 및 관리자 호스트 목록을 로드합니다.
동적 검증 및 동작 흐름: 인프라 네트워크 트래픽 부담을 덜기 위해 실제 HTTP 네트워크 패킷을 단 1건도 전송하지 않는 무증적 정적 분석 파이프라인을 개척했습니다. api-tree 인벤토리 데이터 구조, 배포 프로필별 도메인 맵 변수 규칙, 그리고 verify-report.json 로그 명세와 대시보드 Base URLs 상태를 상호 결합 로드하여 separation_rules.py 규칙 엔진이 분석을 대행합니다. 사용자 도메인과 어드민 도메인이 동일한 호스트 세션 주소 체계를 공유하거나 예측하기 쉬운 레거시 주소 구문(/admin 등)이 인덱싱되어 발견되면 즉각 경고 및 정보 유출 위험 지표를 발출합니다. 프론트엔드에서는 별도 옵션창 없이 원클릭으로 구동되며 finding은 inventory / info 섹션에 기본 펼침 제공됩니다.

── 3-5. 검색엔진 정보 노출 가능성 모듈

보완 조치 및 설계 명세: Google Dorking 및 외부 웹 크롤러 로봇에 의해 비공개 포탈 주소가 무단 색인 누출되는 현상을 제어하는 검색엔진 차단 관리 인벤토리를 수집합니다. targets.py가 프론트엔드 및 API 베이스 주소의 중복을 제거하고 처리합니다.
동적 검증 및 동작 흐름: 권한이 없는 익명 패스(anonymous pass) 상태에서 프론트엔드 기본 자산 도메인 뒤에 /robots.txt 경로를 호출하여 Allow/Disallow 구문 명세를 파싱합니다. 이어서 테스트 가상 계정 세션별 토큰을 의무 인젝션 바인딩한 인증 패스(authenticated pass) 상태로 동일 페이지의 자바스크립트 렌더링 HTML 소스코드를 추적 리드하여 head 대역 내에 <meta name="robots" content="noindex, nofollow"> 메타 수집 거부 가드가 유효하게 삽입 작동하고 있는지 robots_rules.py를 통해 동적 추출 및 파싱합니다.

── 3-6. 백업 파일 및 테스트 파일 존재 여부 모듈

보완 조치 및 설계 명세: 형상 관리 및 빌드 배포 과정에서 누락 유실되어 남겨진 은닉 압축 백업본 및 기밀 환경 설정 자산이 대외 유출되는 결함을 제어하기 위해 file_rules.py 규칙 엔진을 구성했습니다.
동적 검증 및 동작 흐름: 공통 저장된 backup-test-files.txt 사전에 기재된 확장자 및 파일 명세 코드 배열을 Base URLs 및 api-tree 상위 경로 세그먼트와 조합한 뒤, 익명 및 인증 세션별 크로스 대입 스캔을 진행합니다. 수신 응답을 대상으로 단순히 404/400 차단 텍스트를 리턴한 것인지, 혹은 실제 내부 파일 구조 데이터 가독 환경이 열려 .bak, .old, .env, web.config 기밀 정보가 스트리밍 유출되는 상태인지를 본문 바이너리 휴리스틱 필터로 분류 판정합니다.

4. 취약한 인증 및 세션 관리 영역 (4-1, 4-2)

── 4-1. 쿠키·웹 스토리지 조작 가능성 모듈

보완 조치 및 설계 명세: 로그인 및 민감 행위 처리 시 배출되는 인증 컨텍스트 속성 위배 상태와 수평적 권한 우회 가능성을 마스터 체크합니다. cookie_attr_rules.py 및 핵심 변조 프로필 모듈이 결합되어 구동됩니다.
동적 검증 및 동작 흐름: 샌드박스 파이프라인 3가지로 교차 확인합니다.
- Phase A (cookie_attr): 로그인 및 토큰 갱신 API 성공 응답 시 서버가 배출하는 Set-Cookie 헤더 속성 내 HttpOnly, Secure, SameSite=Lax/Strict 설정 정확성을 정적 추적 분석합니다.
- Phase B (cross_cookie): 세션 컨텍스트 가로채기 위협 강도를 실증하기 위해, 테스트 계정 A 세션의 유효 쿠키 인자를 가로채 직접 타인 자산인 테스트 계정 B의 API 엔드포인트 파라미터 영역에 오염 주입 후 전송하여 타인의 정보가 도용 무단 유출(cross leak)되는지 확인합니다.
- Phase C (tamper): Authorization 베어러 토큰 및 일반 쿠키 문자열 값의 식별 고유 부위를 임의 변조하여 전송 시, 백엔드 필터가 위변조 상태를 명확히 인지하고 거부하는지 변조 정확성을 판정합니다.

── 4-2. 인증(세션·토큰) 값 안전성 모듈

보완 조치 및 설계 명세: JWT 및 인메모리 Opaque 토큰 자산의 정적 암호 강도 판정과 실제 구동 애플리케이션 라이프사이클의 실시간 세션 만료 제어 적합성을 검증하기 위해 token_analyzer.py와 lifecycle_probes.py 컴포넌트를 넣었습니다.
** 중대 내부 크래시 패치 완료:** 실시간 진행률 연산식인 lifecycle_steps 코드가 가상 인증 계정을 로드하는 헬퍼인 pick_probe_account() 실행 라인보다 먼저 코드 단 위쪽에서 참조되어 참조 오류(UnboundLocalError)와 함께 500 내부 에러 크래시를 유발하던 심각한 소스코드 오염 상태를 발견하여, 금일 자 긴급 수정 조치 트랙을 전개해 계정 컨텍스트 해석 구문을 진행률 팩터 계산식보다 물리적으로 앞단 상단 레이어로 이동 전치 배치하여 크래시 버그 현상을 해소했습니다.
동적 검증 및 동작 흐름: 암호 알고리즘 규칙 검증(JWT alg none/weak check), 만료 스탬프(exp) 바인딩 유무를 연산한 뒤, 동일 세션 재로그인 시 기존 토큰이 바로 무효화되는지, 동일 토큰을 이기종 브라우저 및 크로스 IP 환경에서 다중 중복 동시 접속 시 세션 킬링(Session Killing) 가드가 작동하는지, 서버 로그아웃 수신 즉시 Redis 블랙리스트 무효화가 진행되는지 가상 세션 제어 시뮬레이션을 진행합니다.

5. 중요 정보 저장/전송 처리 미흡 & 부적절한 오류 처리 영역 (5-2, 6-1)

── 5-2. 요청/응답 주요정보 포함 여부 모듈

보완 조치 및 설계 명세: 데이터 직렬화 및 통신 트래픽 패킷 전송 구간 상에서 개인식별정보(PII) 데이터가 마스킹 필터 없이 원문 평문 노출되는 결함을 전수 식별하기 위해 pii_rules.py 규칙 엔진을 구성했습니다.
한국어 실명(이름) 오탐 방지 가이드라인 규칙 마무리: 차량 매물 정보나 브랜드 카탈로그 상품명(예: '스타리아') 등이 이름 속성으로 오염되어 보안 결함으로 오탐되는 런타임 유해 패턴을 제어하고자 제약을 완료했습니다. 반드시 name, nickname, insuredName 등 인간 식별 목적의 성격이 명확한 필드명 및 JSON 명세 경로여야만 작동하며, modelName, cars[].name 등의 상품 설명 필드는 필드명 화이트리스트 검사 계층에서 안전하게 스킵 배제합니다. 수신 값이 정확히 한글 3글자(^[가-힣]{3}$)를 만족하고 첫 글자가 약 150여 개 자산의 성씨 배열(_KOREAN_SURNAMES)에 매칭될 때만 실명 유출로 확정합니다. 이에 따라 브랜드성 가명 계정 및 2글자/4글자 닉네임 등은 정확성을 위해 의도적으로 미탐 격리 처리하도록 설계했습니다.
동적 검증 및 동작 흐름: 대시보드 UI 화면단에 g52DiagnosisOptions.ts 명세와 매핑 카운터를 적용하고, 스캔 범위 조율용 프리셋 탭을 완비했습니다. 인벤토리 api-tree 내 엔드포인트 중 중복을 제거한 뒤, 익명 접근 및 5개 가상 테스트 계정 권한 조합(6 auth pass)을 입혀 트래픽을 송수신하며 반환 JSON 텍스트 트리 구조 전체를 순회 스캔(JSON walk)하여 이메일(email_plain), 연락처(phone_plain), 주민번호(rrn_plain), 여권·카드·계좌 및 경로 정보 노출을 추적합니다. 실명이 배제된 기본 onde-pilot 실행 시 이메일/연락처 지표만 검출되고 이름 항목은 0건으로 배출되는 것이 정상적인 보완된 상태입니다.

── 6-1. 오류페이지를 통한 정보 노출 모듈

보완 조치 및 설계 명세: 입력값 크기 및 자료형 변조 타격을 가해 서버 내부 비즈니스 런타임 크래시를 인위적으로 유도한 뒤, 반사 출력되는 응답 본문 내에서 기밀 자산 지표가 유출되는지 검증하기 위해 payloads.py와 error_rules.py 판정 엔진을 구성했습니다. triggers.py가 엔드포인트별 trigger를 선택 부여합니다.
동적 검증 및 동작 흐름: 프론트엔드 옵션 다이얼로그(g61) 및 프리셋 탭 제어 컴포넌트를 반영 완료했습니다. 수집된 인벤토리 샘플 주소를 대상으로 파라미터, 바디 JSON, 경로 변수 영역에 자료형 오염 파라미터(type confusion), 대용량 바이너리 더미, 비정형 특수문자 페이로드(malformed payload)를 넣습니다. 이후 판정 엔진이 작동하여 응답 본문 내에 Java 스택 트레이스 명세 구문(java.lang.), SQL 구문 오류 흔적 및 루트 디렉터리 노출 경로 규칙 단어가 은닉 포착되어 누출되는지 감시하며, ZAP unified fuzz 스캐닝 엔진 정책과 하이브리드 연동 실행합니다.

6. 마무리와 다음 작업: 팀 모듈 통합과 증적 자동화

이번 스프린트에서는 SK쉴더스 취약점 진단 가이드라인을 기준으로 아르고스(Argus)에 진단 모듈 9개를 추가하고, 연동 테스트와 크래시 수정까지 마쳤습니다.

이로써 자동 탐지 모듈의 백엔드 기본 기능을 한 차례 정리했습니다. 다음에는 전체 시스템을 합치고 발표와 시연에 필요한 부분을 다듬습니다.

다음 작업:
1. 모듈 통합: 오늘 구현·검증을 마친 모듈 9개와, 팀원들이 각자 만들고 있는 나머지 모듈을 내일 한 파이프라인 브랜치로 머지(Merge)할 예정입니다.
2. 취약점 증적 자동화 기능 만들기: 통합 뒤에는 자동 스캐너가 실제 취약점을 찾거나 시큐어 코딩으로 막는 과정을 보여 주기 위해, HTTP 응답 패킷과 브라우저 화면(스크린샷)을 실시간으로 찍어 저장하는 증적 자동화 모듈을 만들 예정입니다. 다음 스프린트에도 이어서 진행합니다.