소개
Fieldwork Studio는 일반에 공개된 공예 워크숍을 운영합니다. 일정은 쉽게 살펴보고 다운로드할 수 있어야 하지만, 유지보수 진단에는 권한이 필요해야 합니다. 여러분의 과제는 어떤 응답이 실제로 이 애플리케이션의 내부 진단 데이터를 노출하는지 확인하는 것입니다.
먼저 정상적인 사이트 기능을 사용합니다. 그런 다음 세 가지 실제 응답을 비교하고, 의도적으로 판정 범위를 넓게 잡은 Nuclei 시작용 검사를 실행합니다. 스캐너가 탐지한 모든 항목을 확인된 문제로 간주하지 않고, 직접 살펴본 응답과 연결된 결론을 작성하며 마무리합니다. 모든 설정과 신원 정보는 합성 데이터이며, HTTP 요청과 스캐너 실행은 실제로 이루어집니다.
기본적인 터미널 입력과 경로에 대한 이해만 있으면 됩니다. HTTP, JSON, 스캐너 출력은 등장할 때 설명합니다. Kali 감사 컨테이너와 대상 컨테이너는 격리되어 있으며 하나의 VM 커널을 공유합니다. 제공된 범위만 테스트하고, 읽기 전용 요청을 사용하며, 워크숍 사이트와 일정을 보존하세요. 읽기와 일반적인 실수를 포함해 약 50분을 예상하세요. 이는 작성자의 추정치입니다.
공개 워크숍 일정 사용하기
이 단계에서는 정상적인 공개 접근에서 보존해야 할 기능을 확인합니다. Workshops를 여세요. 이 페이지는 Fieldwork Studio의 공예 수업을 소개합니다. Get the workshop schedule을 눌러 fieldwork-schedule.csv를 다운로드하세요. 여기에는 Printmaking과 Bookbinding의 워크숍 이름, 시간, 장소가 들어 있습니다. 이 정보를 공개하는 것은 의도된 동작입니다.
두 수업 카드와 초록색 일정 링크가 정상적인 공개 서비스입니다. 진단을 평가하는 동안 이 실제 워크숍 정보를 보존하세요.
Kali 터미널인 Auditor로 전환하세요. 시작 디렉터리는 /home/labex/project입니다. 브라우저 진입점과 이 터미널은 같은 워크숍 서비스에 접근하며, 서로 다른 대상 컴퓨터를 나타내는 것이 아닙니다.
cat은 텍스트 파일을 표시합니다. 보안 검사를 보내기 전에 허가된 범위를 읽으세요.
cat scope.txt
targets.txt에 있는 기본 URL에 읽기 전용 HTTP GET 요청을 보내는 것만 허가됩니다. 기본 URL은 사이트를 식별하며, 그 뒤에 진단 경로를 붙입니다. 목록을 표시하세요.
cat targets.txt
http://workshop.test:8080/ 아래에 studio, archive, manual이 표시되어야 합니다. 포트 8080은 이 과정의 서비스를 식별합니다. 모든 사이트, 설정, 워크숍 데이터를 보존하세요. 여러분은 접근 상태를 평가하며, 애플리케이션을 변경하지 않습니다.
상대 파일 경로를 사용할 때 오류가 발생하면 pwd로 현재 디렉터리를 표시한 다음 아래 명령으로 돌아오세요.
cd /home/labex/project
Auditor를 닫거나 다시 연결해도 사이트가 다시 만들어지지 않습니다. 파일은 이 작업 공간에 그대로 남습니다.
판단하기 전에 응답 읽기
이 단계에서는 허가된 각 사이트의 진단 엔드포인트를 비교합니다. Auditor에 머무르세요. HTTP는 이 사이트에서 사용하는 요청·응답 프로토콜입니다. curl은 요청을 보내고 응답 본문을 출력합니다. -i 옵션은 상태와 콘텐츠 유형을 포함한 응답 헤더도 출력합니다.
curl -i http://workshop.test:8080/studio/maintenance/diagnostics
응답은 HTTP/1.0 200 OK로 시작합니다. 이는 서버가 요청한 리소스를 성공적으로 반환했다는 의미이며, 이것만으로 보안 문제가 있다고 판단할 수는 없습니다. Content-Type: application/json; charset=utf-8은 본문이 UTF-8 텍스트로 인코딩된 JSON임을 나타냅니다. JSON은 중괄호 안에 이름이 붙은 값을 표현합니다. 이름과 텍스트 값은 큰따옴표로 둘러싸고, 숫자 값에는 따옴표를 붙이지 않습니다.
이 평면 객체에는 service, visibility, database_file, request_count가 들어 있습니다. 이 애플리케이션에서는 service가 workshop-portal, visibility가 internal이며, 데이터베이스 파일은 절대 경로이고 요청 횟수는 0 이상의 정수입니다. 파일 경로는 실행 중인 사이트의 설정에서 가져옵니다. 공개 워크숍 페이지와 CSV 다운로드는 그 실제 SQLite 데이터베이스를 읽습니다. SQLite는 작은 데이터베이스를 파일에 저장합니다. 요청이 들어오면 횟수가 바뀝니다. 이 조합이 scope.txt에 명시된 진단 응답 계약입니다. 모든 취약점에 적용되는 보편적인 정의는 아닙니다.
인증되지 않은 요청이 이 내부 값들을 받았습니다. X-Audit-Event 헤더에 주목하세요. 서버는 실제 응답마다 서로 다른 식별자를 부여합니다. 최종 평가에 사용할 수 있도록 이 식별자를 비공개 장소에 기록하세요. 요약에 내부 값을 복사하지 않고도 참조할 수 있는 증거입니다.
두 번째 사이트와 비교하세요.
curl -i http://workshop.test:8080/archive/maintenance/diagnostics
401 Unauthorized와 유지보수 자격 증명이 필요하다는 설명이 나와야 합니다. 이 거부는 의도된 동작입니다. 허가 범위에 자격 증명이 없으므로 이를 우회하려고 해서는 안 됩니다. curl -i는 HTTP 401을 표시하면서도 정상적으로 완료될 수 있습니다. 거부 응답을 성공적으로 전달받는 것과 접근 권한을 얻는 것은 서로 다릅니다.
이제 세 번째 사이트를 살펴보세요.
curl -i http://workshop.test:8080/manual/maintenance/diagnostics
HTTP 200과 JSON을 반환하지만, 진단 필드는 example 객체 안에 중첩되어 있습니다. 이는 응답 형식을 문서화한 것이며 이 사이트의 최상위 실제 진단 객체가 아닙니다. 단순히 internal이라는 단어를 찾지 말고 구조와 의미를 비교하세요. 이 응답의 이벤트 식별자도 보관하세요.
404가 보이면 제공된 경로와 URL을 꼼꼼히 비교하고 수정한 요청을 다시 보내세요. Could not resolve host 또는 Failed to connect는 의도한 응답을 얻지 못했다는 뜻입니다. 이를 근거로 안전하거나 노출되었다고 결론 내릴 수 없습니다. 철자와 과정에서 지정한 정확한 호스트 이름 및 포트를 확인하세요. 대상을 공개 웹사이트로 바꾸지 마세요.
판정 범위가 넓은 Nuclei 탐지 조사하기
이 단계에서는 검사가 올바르게 실행되더라도 지나치게 넓은 결론을 낼 수 있음을 살펴봅니다. Auditor에 머무르세요. Nuclei는 템플릿 기반 스캐너입니다. 템플릿은 요청과 탐지 결과를 만드는 응답 조건을 기술합니다. 탐지 결과가 있다는 것은 해당 조건이 일치했다는 의미입니다. 그 결과가 의도한 문제를 입증하는지는 여전히 판단해야 합니다.
준비된 시작용 템플릿을 읽으세요.
cat too-broad.yaml
YAML은 들여쓰기로 설정을 묶습니다. 이 시작용 템플릿은 각 기본 URL의 진단 경로에 GET 요청을 하나 보내고, HTTP 상태 200만 일치시키도록 되어 있습니다. {{BaseURL}} 자리 표시자는 현재 허가된 기본 URL로 대체됩니다. 진단 객체의 의미는 검사하지 않습니다.
제공된 목록에 시작용 검사를 실행하세요. -t는 로컬 템플릿을 선택하고, -l은 대상 목록을 읽으며, -o는 탐지 결과를 저장하고, -elog는 요청 오류를 저장합니다. -jsonl은 한 줄에 JSON 탐지 결과 하나를 기록하고, -ot는 해당 출력에서 인코딩된 템플릿을 제외합니다. 준비 옵션 -duc와 -ni는 업데이트 확인과 외부 Interactsh 콜백을 비활성화합니다. 이 템플릿에는 둘 다 필요 없습니다. 격리된 실습에서는 이 옵션들을 유지하세요.
nuclei -t too-broad.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o broad-findings.jsonl -elog broad-errors.jsonl
-nc는 터미널 색상 코드를 제거합니다. 이 명령은 실제 읽기 전용 요청을 보냅니다. studio와 manual이 모두 200을 반환했으므로 둘 다 탐지되어야 합니다. 보호된 archive 경로는 일치하지 않습니다. 탐지 결과가 출력되지 않았다고 해서 요청이 정상적으로 완료되었고 검사 조건에 맞는 응답이 없었다고 판단할 수는 없습니다.
결과를 판단하기 전에 Nuclei 자체 요청 오류 로그를 읽으세요.
cat broad-errors.jsonl
로그가 비어 있으면 이번 실행에서 기록된 요청 오류가 없다는 뜻입니다. 연결 실패가 있어도 Nuclei 프로세스 종료 상태는 0일 수 있으므로, 종료 상태나 비어 있는 탐지 결과 파일만으로는 충분하지 않습니다. 로그에 오류가 있으면 결론을 내리기 전에 대상이나 연결 문제를 바로잡으세요. 원래 오류 증거를 보관하고, 재시도할 때는 새 출력 파일 이름을 사용하세요.
탐지 결과를 살펴보세요.
cat broad-findings.jsonl
각 줄에는 matched-at URL과 요청·응답 증거가 있습니다. manual 탐지 결과를 앞서 읽은 중첩 문서 예제와 비교하세요. 시작용 템플릿의 상태 매처는 작성된 대로 작동했지만, 의도한 진단 노출 여부라는 질문에 대해서는 오탐입니다. studio 응답은 정의된 노출 조건을 실제로 충족합니다.
이 합성 응답에는 실제 비밀 정보가 없습니다. 실제 평가에서는 원시 탐지 결과에 민감한 내용이 들어갈 수 있으므로 비공개로 다뤄야 합니다. 외부 스캐너에 업로드하거나 공개 보고서에 붙여 넣지 마세요.
증거와 연결된 평가 저장하기
이 단계에서는 스캐너의 넓은 일치 결과와 자신의 결론을 구분합니다. Auditor에 머무르세요. 사이트마다 항목 하나가 들어 있는 assessment.json을 만드세요. 각 항목에는 직접 살펴본 실제 응답 이벤트와 결론을 기록합니다. 앞에서 배운 세 가지 결과에는 exposed, access-denied, documentation-example을 사용하세요.
다음은 완전한 셸 here-document입니다. cat > assessment.json은 파일을 작성하며, >는 내용을 덮어씁니다. <<'JSON'은 JSON만 있는 줄이 나올 때까지 뒤따르는 텍스트를 셸이 그대로 복사하게 합니다. 구분자를 따옴표로 감싸면 텍스트 내부에서 셸 확장이 일어나지 않습니다. 블록을 실행하기 전에 각 REPLACE_... 값을 해당 사이트의 진단 응답에서 얻은 실제 X-Audit-Event로 바꾸세요. JSON의 큰따옴표와 쉼표는 유지하세요.
cat > assessment.json <<'JSON'
{
"studio": {"event_id": "REPLACE_STUDIO_EVENT", "conclusion": "exposed"},
"archive": {"event_id": "REPLACE_ARCHIVE_EVENT", "conclusion": "access-denied"},
"manual": {"event_id": "REPLACE_MANUAL_EVENT", "conclusion": "documentation-example"}
}
JSON
식별자를 보관하지 않았다면 2단계의 해당 사이트 curl -i 요청을 반복하고 새 식별자를 사용하세요. 읽기 요청을 반복하면 실제 응답이 하나 더 생성되고 request_count가 증가할 수 있지만, 사이트 접근 정책을 복구하거나 변경하지는 않습니다.
저장한 파일을 표시하세요.
cat assessment.json
따옴표, 쉼표, 이벤트 값이 잘못되었다면 완전히 수정한 here-document를 다시 실행하세요. 자리 표시자 값을 그대로 복사하지 마세요. 이 작업 공간에 읽을 수 있는 일반 파일로 assessment.json을 제출하세요. 검증은 결론을 기존 응답과 비교하며, 누락된 평가 요청을 생성하지 않습니다. 또한 이 작은 요약에 진단 호스트나 원시 본문을 복사하도록 요구하지 않습니다.
이 결과는 studio의 노출을 확인하고, archive의 실제 거부를 관찰하며, manual의 오해를 부르는 문서 일치를 설명합니다. 다른 모든 경로나 취약점을 테스트했다는 주장은 하지 않습니다. 다음 안내형 실습은 새 환경에서 시작하며, 넓은 매처를 재사용 가능한 Nuclei 네이티브 검사로 교체하는 방법을 배웁니다.
요약
공개 워크숍 일정을 사용하고, HTTP 상태와 JSON 구조를 살펴보며, 내부 진단 정보가 노출되는 한 곳을 확인했습니다. 실제 Nuclei 시작용 검사를 실행하고 문서 응답에서 발생한 오탐을 설명했습니다. 작성한 평가에서는 각 결론을 기존 응답과 연결했으며 정상적인 공개 접근도 유지했습니다.
