포트폴리오 ↗
루키즈 5기 · 일지›아르고스 개발Day 33 / 46

아르고스 Staging 통합과 비동기 퍼징 구조 정리

·읽는 시간 약 10분
#argus#security#staging
목차 6개 단원
  1. ·서론
  2. 01개요 및 공통 인프라 비동기·인증 풀 계층 명세
  3. 02입력값 검증 및 삽입 위협 통제 계층 전체 병합
  4. 03취약한 파일 처리 영역 확장 및 런타임 오류 전체 교정
  5. 0414개 진단 모듈 대시보드 패널 연결
  6. 05마무리와 다음 작업: 모듈 보완과 멘토링 준비

서론

"이전 스프린트에서 정리한 플랫폼 공통 구조 위에 팀원들의 feature 브랜치 엔진을 Staging 메인라인에 합쳤습니다. 이번 세션에서는 여러 브랜치의 큰 변경을 Staging에 합치며 1-6 입력값 검증 엔진을 넣고, 2-1 악성 파일 업로드 모듈을 새로 만들었으며, 6-1 에러 노출 모듈에 비동기 실행과 취소 기능을 넣었습니다. 전체 영역을 스캔하는 요약 대시보드 패널까지 연결한 내용을 정리합니다."

여러 브랜치를 Staging에 합치며 1-6·2-1·6-1을 올렸고, 6-1 기준으로 run(202) → progress 폴링 → cancel 비동기 제어와 인증 세션 풀, 14개 모듈 대시보드 패널까지 연결했습니다.

1. 개요 및 공통 인프라 비동기·인증 풀 계층 명세

여러 브랜치에 나뉘어 있던 진단 엔진을 SK쉴더스 웹/API 취약점 진단 가이드라인의 공통 구조에 넣기 위해 백엔드 공통 기능을 크게 정리했습니다. 이 글은 Staging 통합 구간에서 올라온 변경을 기준으로 합니다.

① 6-1 중심의 실시간 비동기(Async) 실행 및 취소(Cancel) 제어 프레임워크 정리

대용량 퍼징 주입 시 발생하는 게이트웨이 타임아웃(Gateway Timeout)을 막고 런타임 제어권을 확보하기 위해 비동기 파이프라인을 도입했습니다.

  • 백엔드 비동기 통제 라우팅: POST /api/diagnosis/modules/6-1/run 요청 인입 시 백엔드 라우터는 즉각 202 Accepted JSON 응답을 배출하고 백그라운드 스레드 워커를 구동합니다.
  • 대시보드 실시간 폴링 구조: 프론트엔드는 GET /api/diagnosis/progress 엔드포인트를 주기적으로 호출해 진행 상태 바를 갱신합니다.
  • 실행 중인 스캔 취소: 사용자가 실행 중인 버튼을 다시 누르면 POST /api/diagnosis/cancel이 호출되어 내부에서 DiagnosisCancelled 예외를 냅니다. 무거운 프로브 묶음을 안전하게 멈추고, 그때까지 모은 일부 증적 데이터만 latest.yaml 리포트에 저장하도록 했습니다.

② 다중 권한 교차 주입용 자동 인증 패스 및 세션 풀 라이프사이클 관리

  • 인증 요구 조건 매핑 자동화: 엔드포인트별 인가 권한 요구 조건에 맞춰 가상 테스트 계정의 세션 토큰 조합을 자동으로 추출하고 매핑해 주는 endpoint_auth_passes.py 인프라 클래스를 새로 만들었습니다.
  • JWT 만료 차단 자동 리프레시 엔진: auth_session_pool.py가 백그라운드에서 상시 연동되어 세션 캐시 및 토큰의 만료 스탬프(exp)를 추적하며, 토큰이 소멸하기 직전 단계에서 자동으로 리프레시 절차를 자동으로 진행합니다.
  • 연동 모듈 대역: 2-2, 3-2, 3-5, 3-6, 4-1, 4-2, 5-2, 6-1, 6-2, 7-1~7-4 등 아르고스 코어 스캐너 파이프라인 전반에 연결되어 멀티 패스 권한 조회를 보장합니다.

③ 로컬 vs Docker 환경 Probe URL 라우팅 규칙 통일 개편

  • 결함 현상 및 원인 분석: 백엔드 도커 컨테이너 내부망 환경에서 triggers 기동 시 타깃 주소로 localhost:8080이 그대로 유입되면, 외부 호스트 서버가 아닌 컨테이너 자기 자신으로 루프백 라우팅되어 Connection Refused 에러와 함께 status가 100% 실패 처리되는 미탐 결함을 적발했습니다.
  • 통일 구조 패치 조치: 6-1/triggers.py 소스코드 단 내부에 공통 치환 유틸 매퍼인 probe_url() 및 frontend_gateway_path() 라인을 수직 결합하여, build_probe_request(..., probe_base_fn=probe_url) 형태로 호출이 변환되도록 수정 완료했습니다. 이를 통해 웹 대시보드 및 리포트 화면상에는 localhost 형상을 유지하되, 하부의 실질적인 HTTP 퍼징 트래픽만 Docker 호스트 대역으로 안전하게 전달되도록 매퍼를 정상화했습니다.

2. 입력값 검증 및 삽입 위협 통제 계층 전체 병합 (1-1, 1-2, 1-4, 1-6)

SK쉴더스 취약점 진단 가이드라인 최상단에 위치한 핵심 탐지 모듈 브랜치들을 하나로 병합 마쳤습니다.

── 1-1. XSS / CSRF 공격 가능성 모듈

  • 보완 조치 및 설계 명세: feat/xss&csrf-search-engine 브랜치의 개선 성과를 반영하여 modules/1-1/ 하부의 리팩토링 및 2차 연동을 마쳤습니다.
  • 동적 검증 및 동작 흐름: openapi_utils.py를 거쳐 추출된 정제 seed 주소를 기반으로, 익명 자산 및 admin / seller / user 다중 역할별 컨텍스트 세션 JWT를 ZAP 스캔 엔진에 동적으로 바인딩 보냅니다. 크게 확장된 zap_runner.py(+696라인)가 기동되어 크로스 사이트 스크립팅 및 요청 변조 위협을 스파이더 및 액티브 스캔 오케스트레이션으로 전개한 뒤, zap_adapter.py가 중복 findings collapse 압축 및 심각도 정규화 처리를 진행합니다.

── 1-2. 삽입 (Injection) 공격 가능성 모듈

  • 보완 조치 및 설계 명세: 단순히 결과 유무만 YAML로 배출하여 가독성이 저하되던 기존 단독 구조를 없애고, 1-2/module.py 내부에 _save_json_report() 서브 로직을 새로 넣었습니다.
  • 동적 검증 및 동작 흐름: 진단 실행 시 실서버에 심각한 영향을 주는 타임 기반/에러 기반 인젝션 지표는 '정탐(Confirmed/Verified)' 트랙으로 분리하고, 단순 구문 변조 에러나 논리식 참/거짓 분기 노이즈는 '약한 정탐(Suspected)' 레이어로 쪼개어 타임스탬프 기반 JSON 이력 파일(report_{timestamp}.json)로 병행 분리 저장하도록 판정 가드를 다듬었습니다. 아울러 1-2/docker-compose.yml 사양을 따로 추가하여 외부 인프라 간섭 없이 ZAP + Target 단독 실행 디버깅이 가능하도록 구조를 정돈했습니다.

── 1-4. SSRF / File Inclusion 공격 가능성 모듈

  • 보완 조치 및 설계 명세: payload_injector.py 핵심 컴포넌트를 큰 규모의 리팩토링(+231라인 net)하여 외부 URL 필수 참조(SSRF) 및 원격/로컬 파일 인클루전(RFI/LFI) 탐지 정확도를 높였습니다. search_engine, input_parser, inventory_bridge, zap_engine 전반의 파이프라인이 정비되었습니다.
  • 동적 검증 및 동작 흐름: discover_service.py와 verify_service.py 간의 안정적인 상호 영속성 인터페이스 트랙을 연결하여, 검증 단계에서 추출된 영속 데이터 샘플 지표가 유실 없이 1-4 검색 엔진 코어에 도달하도록 다리를 놓았습니다. OpenAPI 구조 해석 시 중첩 구조 객체 파라미터(nested object param) 해석 옵션 사양을 정교화 빌드했으며, 머지 과정에서 발생한 빈 verify skip 가드 조건과 reference sample 복원 로직의 충돌을 수동 조율하여 데이터 정확성을 확보했습니다.

── 1-6. 입력 값 크기 및 정확성 검증오류 모듈

  • 보완 조치 및 설계 명세: 팀원이 만든 W-1-6 고속 퍼징 검색 엔진 프레임워크 전체 자산을 backend/diagnosis/modules/1-6/ 하위 소켓에 포팅 임베드 완료했습니다.
  • 동적 검증 및 동작 흐름: 내부 구조에 fuzzer.py(파라미터 fuzzing 코어), collector.py(응답/증적 수집), screenshot.py(UI 자동 캡처), zap_engine.py 결합 제어선 및 Swagger 사양 해석용 모듈을 내장 탑재했습니다. 프론트엔드 단에 DiagnosisG16RunOptions 인터페이스 규격과 전용 시작 모달 다이얼로그 연동을 연계 마감하여 대시보드 상에서 통제 가능하며, 실서버 검증을 위한 docs/ONDE_INPUT_SEARCH_ENGINE_RUNBOOK.md 운영 가이드를 통합 탑재했습니다.

3. 취약한 파일 처리 영역 확장 및 런타임 오류 전체 교정 (2-1, 2-2)

── 2-1. 악성코드파일 업로드 모듈 (신규 모듈 전체 구현)

  • 보완 조치 및 설계 명세: 기존 플레이스홀더 상태로 대기 중이던 2-1 슬롯을 없애고, 실제 웹쉘 및 악성 바이너리 우회 차단 여부를 검증하는 실성 탐지 엔진 빌드를 모두 마감했습니다. 팀원이 만든 업로드 검증 모듈을 기반으로 포팅했습니다.
  • 동적 검증 및 동작 흐름: 대시보드 화면에 새로 만든 G21DiagnosisStartDialog 컴포넌트를 통해 파트너 판매자의 이메일, 비밀번호, 그리고 자산 인가 권한을 증명할 seller_id 파라미터 입력 규칙을 필수로 수용합니다. 백엔드 upload_context.py와 upload_board.py가 작동하여 여행기 본문, 숙박 세부 정보(upload_seller.py), 렌탈 차량 자산 등록 멀티 엔드포인트 경로를 대상으로 비인가 확장자 파일 업로드를 우회 넣은 뒤, upload_judge.py 검증기가 200/201 성공 또는 403 Forbidden 거부 배출 여부를 연산하여 SK쉴더스 가이드라인 기준의 통제 정확성을 최종 판정합니다.

── 2-2. 중요 정보 파일 다운로드 가능성 모듈 (런타임 크래시 패치)

  • 결함 현상 및 버그 교정: 대시보드 연동 구동 시 2-2/probes.py 소스코드 단 내부에서 로컬 매핑 인자인 current_auth를 바인딩 변수로 참조하려다 스펙 불일치로 인해 NameError와 함께 시스템 500 내부 에러 예외를 발생시키며 전체 스캔이 중단되던 심각한 버그를 찾았습니다.
  • 조치 및 흐름 매핑: 금일 자 리팩토링 트랙을 통해 변수 참조 관계를 공통 세션 토큰 체계인 auth 명세 라인으로 전향 전치 수정 완료하여 500 구동 오류를 정상 복구하고 IDOR 프로브 연동을 정상 넣었습니다.

4. 14개 진단 모듈 대시보드 패널 연결

읽기 쉽고 결과를 확인하기 쉽게 보이도록, 그대로 출력하던 상세 로그 화면을 '요약 표 + 접어서 보는(Collapsible) 상세 패널' 구조로 바꿨습니다. finding이 수백 건을 넘어도 브라우저가 느려지지 않게 CollapsibleReportSection.tsx에서 나중에 렌더링하도록 했습니다.

── 대시보드 리포트 패널 라우팅 맵 확장 명세 (DiagnosisReportPanel.tsx)

  • 1-5 (오픈 리다이렉트): 불필요한 카드 섹션을 소멸시키고 CORS 위협 지표를 직관적인 한국어 요약 텍스트 명세로 파싱 출력하도록 개편했습니다.
  • 5-2 (민감정보 PII): 응답 트래픽 내에서 수집된 HTTP/body/2xx/401 통계 카운터 카운트 수치와 유출 속성을 일대일 대응 매핑한 G52FindingsPanel을 정했습니다.
  • 2-2, 3-2, 3-4, 3-5, 3-6, 4-2 계열: G22~G42 전용 정형화 리포트 뷰 객체를 만들어, 디렉터리 변조 및 락아웃 임계치 통계를 계층형 구조로 정렬 처리합니다. 특히 3-5 모듈은 review finding 검출 상태에 따라 대시보드 상에 warn 상태 지표를 동적으로 배출합니다.
  • 6-2 & 7-x 계열: G62FindingsPanel 및 G71~G74 헤더 노출 정보(affected_urls) 및 보안 플래그 누락 통계를 요약 테이블 구조로 매핑 완료했습니다.

5. 마무리와 다음 작업: 모듈 보완과 멘토링 준비

이번 스프린트에서는 SK쉴더스 취약점 진단 가이드라인을 기준으로, 나뉘어 있던 핵심 검색 엔진(1-1, 1-2, 1-4, 1-6), 새 2-1 모듈, 비동기 스캔 큐 구조를 대시보드 mainline Staging에 합쳤습니다. pytest 회귀 테스트도 20개가 넘는 파일로 늘렸습니다.

최종 배포와 평가를 위해 다음 작업을 진행합니다.

  • 다음 작업:
    1. 네번째 멘토링 준비: 다음 주 초 멘토링 전에 Staging에 합쳐 둔 가이드라인 모듈 14개의 정·오탐 기준을 다시 확인합니다. 실서버 스캔에서 데이터셋이 믿을 만한지, 인벤토리 자동 수집이 안정적인지 보여 줄 수 있도록 프리셋과 실행 방식을 미리 다듬습니다.
    2. Playwright 기반 실시간 증적 스크린샷 캡처 기능 확장: 기본 폴더 구조를 만들어 둔 backend/screenshot/modules/{id}를 바탕으로 동적 화면 캡처 기능을 연결합니다. 1-6 모듈의 스크린샷 유틸을 28개 모듈에 연결해, 스캐너가 취약점을 찾거나 시큐어 가드에 막히는 순간의 브라우저 화면을 증적으로 실시간 캡처해 S3 버킷에 저장하는 자동화 모듈을 만들 예정입니다.
    3. Staging 정리와 로컬 임시 파일 정리: 로컬에 아직 커밋하지 않은 구조 설명 문서(ARGUS_FLOW.md, PROGRESS_*.md)를 메인라인에 올리고, 1-2 하위 디렉터리 등에 남은 빌드 캐시(.pyc)를 지워 정리하겠습니다. 멘토링 준비도 이어서 진행합니다.
아르고스 개발단계 4 · Day 29–40 · 5 / 12일지 전체 →
  1. Day 29세번째 멘토링
  2. Day 30아르고스(Argus) 진단 모듈 6개 개발
  3. Day 31아르고스(Argus) 진단 모듈 9개 추가와 Progress UI·Docker 라우팅 정비
  4. Day 32아르고스 코어 리팩토링과 1-1·1-2·1-4·1-6 Staging 통합
  5. Day 33아르고스 Staging 통합과 비동기 퍼징 구조 정리
  6. Day 34네번째 멘토링
  7. Day 35멘토링 피드백 반영 진단 엔진(1-2, 4-5, 7-4) 개선과 1-6 Docker 크래시 수정
  8. Day 36IT 채용 시장 변화와 취업·비즈니스 소프트 스킬 정리
  9. Day 37Playwright 증적 스크린샷 (자동: 1-2 · 7-4 · 2-2 / 정리·작업중: 1-6 · 6-1)
  10. Day 38아르고스 Findings·증적 UI 연동, 캡처 확장, ONDE 하드코딩 제거
  11. Day 39아르고스 PDF 결과서 생성과 다운로드
  12. Day 40아르고스 AWS 프라이빗 서브넷 배포 아키텍처와 코드 설정