소개
상점은 준비된 카탈로그에서 상품 이미지를 가져옵니다. 브라우저가 애플리케이션에 이미지 가져오기를 요청하면, 애플리케이션은 고객에게 없는 네트워크 접근 권한을 사용합니다. 실제 요청을 추적하고 무해한 내부 상태 기록을 살펴보며 서버 측 요청 위조(SSRF)를 이해합니다.
제공된 훈련 URL만 사용하세요. 조직과 내부 데이터는 합성입니다. 기본 터미널 사용 경험이면 충분하며 HTTP, URL 필드, 네트워크 역할과 리디렉션은 여기서 설명합니다. 컨테이너는 별도 네트워크 네임스페이스를 가지며 인스턴스 커널을 공유합니다.
일반 상품 이미지 가져오기
이 단계에서는 실제 이미지를 가져오고 이를 가져온 서버를 식별합니다. Image Importer 탭으로 전환합니다. 양식은 이미지 기능을 실행하는 서버인 App에 URL을 보냅니다. URL은 주소입니다. http는 프로토콜(scheme), catalog.test는 호스트 이름, 8000은 수신 포트, /leaf.png는 리소스 경로입니다.
이 단계를 시작하려면 실습 인터페이스에서 Image Importer 탭을 선택합니다.
Image URL은 http://catalog.test:8000/leaf.png, Import slot은 normal로 유지합니다. Import image를 클릭합니다. Import result 페이지에는 실제 HTTP 상태와 이름 있는 필드로 구성된 응답인 JSON 객체가 표시됩니다. content_type: image/png와 가져온 바이트의 지문인 해시를 찾습니다. body 필드에는 인코딩된 이미지 바이트가 있으며 이를 편집하거나 디코딩할 필요는 없습니다.
같은 탭에서 Back to Image Importer를 선택하거나 브라우저 뒤로 가기 버튼을 사용한 후 페이지를 새로 고칩니다. Imported responses 아래에 녹색 이미지가 나타나야 합니다. 나타나지 않으면 URL과 슬롯의 철자를 확인하고 다시 제출합니다.
Workstation 탭으로 전환합니다. 이 터미널은 클라이언트 컨테이너입니다. 준비된 imagectl.py는 App에 요청을 보내며 python3는 이 프로그램을 실행합니다. show normal은 다시 가져오지 않고 기존 가져오기 결과를 읽습니다.
다음 명령을 실행하기 전에 Workstation 탭으로 전환합니다.
python3 imagectl.py show normal
HTTP 200, session: learner-c08, PNG image content를 찾으세요. HTTP는 요청/응답 프로토콜이며 200은 성공을 뜻합니다. 이제 Catalog의 실제 요청 기록을 읽으세요.
python3 imagectl.py requests
각 레코드에는 client 주소와 요청한 path가 있습니다. Catalog가 본 것은 Workstation이나 브라우저가 아닌 App의 catalog 네트워크 주소입니다. App이 외부 요청을 보냈습니다. 달라질 수 있는 주소는 서비스의 증거이며 암기할 고정 주소가 아닙니다. Topology 탭으로 전환하여 설정된 네트워크 연결과 내부 소비자의 실시간 상태 점검을 비교합니다.
클라이언트와 서버의 접근 가능성 비교
이 단계에서는 App을 통해 준비된 내부 재고 상태만 가져옵니다. 내부 서비스는 애플리케이션 구성 요소 전용 네트워크에 있습니다. Workstation은 프런트 네트워크에 속하며 App은 내부 네트워크에도 속합니다. localhost는 항상 명령이 실행되는 환경을 의미합니다. Workstation의 루프백은 App의 루프백이 아닙니다.
이 단계를 시작하려면 실습 인터페이스에서 Workstation 탭을 선택합니다.
Workstation에서 직접 요청하세요. 도우미는 예상된 실패를 표시하고 셸을 중지하지 않습니다.
다음 명령을 실행하기 전에 Workstation 탭으로 전환합니다.
python3 imagectl.py direct http://internal.test:8000/status
UNREACHABLE from Workstation이 표시되어야 합니다. 이 컨테이너에서는 해당 호스트 이름을 사용할 수 없습니다. 네트워크는 실제 주소도 격리하므로 이름만 빠진 것이 아닙니다. 이제 App에 같은 리소스를 가져오도록 요청하세요. fetch는 가져오기를 수행하며 마지막 인수는 응답 저장 슬롯입니다.
python3 imagectl.py fetch http://internal.test:8000/status internal
HTTP 200과 service: inventory, status: synthetic-ready, 변하는 training_id가 포함된 JSON 본문이 나와야 합니다. 가져온 응답을 다시 읽으세요.
python3 imagectl.py show internal
기록은 learner-c08에 속합니다. 이것이 SSRF입니다. 클라이언트가 제어한 입력으로 서버가 자신의 네트워크 접근 권한을 사용하게 됩니다. Workstation에 새 네트워크 연결이 생긴 것은 아닙니다. no import가 나오면 internal 슬롯으로 다시 가져오세요. 현재 VM의 합성 기록만 해당됩니다.
카탈로그 리디렉션 따라가기
이 단계에서는 첫 대상만 확인하면 부족할 수 있는 이유를 알아봅니다. 리디렉션은 다른 URL을 요청하라고 클라이언트에 알리는 HTTP 응답입니다. Catalog의 /redirect는 같은 합성 재고 서비스로 향하는 Location과 302 상태를 반환합니다. 취약한 App은 이를 자동으로 따릅니다.
이 단계를 시작하려면 실습 인터페이스에서 Workstation 탭을 선택합니다.
Workstation 탭에서 준비된 경로를 별도 슬롯으로 가져옵니다.
다음 명령을 실행하기 전에 Workstation 탭으로 전환합니다.
python3 imagectl.py fetch http://catalog.test:8000/redirect redirect
응답의 url은 Catalog를, final_url은 Internal을 가리킵니다. 본문은 이미지가 아닌 현재 합성 재고 상태입니다. 저장된 응답과 Catalog 로그를 살펴보세요.
python3 imagectl.py show redirect
python3 imagectl.py requests
Catalog가 /redirect를 기록한 뒤 App이 다른 네트워크를 사용해 Internal을 가져왔습니다. 시작 호스트가 신뢰된다고 다음 대상까지 신뢰되는 것은 아닙니다. 다음 실습은 독립적으로 시작하며 허용 대상과 리디렉션 추적이라는 두 결정을 수정합니다. 이 통제된 연습은 악의적인 DNS 변경, 임의의 인터넷 이미지 소스나 다른 주소 인코딩을 시험하지 않습니다.
요약
실제 이미지를 가져오고 클라이언트와 서버의 접근 가능성을 비교했으며 실제 리디렉션 응답을 살펴보았습니다. 내부 데이터는 합성이었고 네트워크 요청은 실제였습니다.
