Kali·Burp로 웹 요청 관찰하기

01개념과 구성 요소

• Kali보안 진단·포렌식 도구를 제공하는 Linux 배포판이며 도구 설치 자체가 진단 정확성을 증명하지 않는다.
• Burp Proxy브라우저와 서버 사이의 요청·응답을 관찰하고 허가된 실습에서 바꿔 비교하는 중간 지점이다.
• 도구 역할Intercept는 대기·수정, History는 기록, Repeater는 선택한 요청의 반복 비교를 맡는다.

02프록시에서 HTTPS 요청을 관찰하는 순서

1. 수신 경로 연결브라우저 프록시 주소와 Burp listener를 맞추고 다른 서비스와 주소·포트가 충돌하지 않게 한다.
2. 실습 CA 신뢰허가된 실습 브라우저에서 프록시가 발급하는 인증서를 검증할 신뢰를 구성한다.
3. 첫 TLS 연결브라우저가 프록시가 제시한 대상 이름의 인증서를 검증하며 프록시와 TLS를 맺는다.
4. 두 번째 TLS 연결프록시가 실제 서버와 별도로 TLS를 맺는다. 두 연결의 키와 인증 검증 문맥은 다르다.
5. 요청 비교Intercept에서 forward/drop을 선택하고 History·Repeater에서 메서드·본문·쿠키·응답을 비교한다.

03실습 환경은 요청 경로를 통제하는 장치

• KaliKali Linux는 보안 진단과 포렌식 도구를 묶은 Debian 기반 배포판이다. 도구를 설치했다는 사실과 진단 결과가 정확하다는 사실은 별개다.
• 실습 구성분석용 클라이언트·중간 프록시·의도적으로 취약한 실습 애플리케이션을 분리하면 요청의 생성과 처리 위치를 관찰하기 쉽다.
• 망 격리Host-only·내부 네트워크·전용 VLAN은 실습 대상과 관찰 위치를 고정한다. 패키지 갱신을 위한 NAT 경로가 있다고 해서 대상 서버까지 외부에 공개해야 하는 것은 아니다.
• Snapshot 범위VM 스냅샷은 파일·설정 복구의 기준이고, 프록시 기록과 애플리케이션 로그는 요청 재현의 기준이다. 이 둘을 함께 두어야 이전 실험 상태가 다음 실험 결과를 바꾸는 혼동을 줄인다.

04Forward·Reverse·Intercepting Proxy

• 프록시 종류Forward proxy는 클라이언트가 선택한 중계 서버이고 reverse proxy는 서비스의 앞에서 백엔드로 요청을 전달한다. Burp의 학습용 interception은 브라우저와 대상 사이에 HTTP 처리 지점을 만들어 요청을 잠시 멈추고 내용을 관찰하는 방식이다.
• 패킷 캡처와 차이네트워크의 모든 패킷을 자동으로 잡는 수동 센서와는 다르다.
• Listener·포트브라우저의 프록시 설정이 실제 listener를 가리키고 listener가 그 인터페이스에서 실행되어야 요청이 Burp에 도달한다. WebGoat와 프록시가 같은 주소·포트에서 동시에 수신하려 하면 충돌하므로 한쪽 listener를 다른 포트로 옮겨야 한다.
• 바인딩 범위프록시를 모든 인터페이스에 공개하는 것과 브라우저가 접근할 주소 하나에 바인딩하는 것은 노출 범위가 다르다.

05HTTPS interception은 두 개의 TLS 연결

• 두 TLS 구간HTTPS를 관찰할 때 브라우저↔Burp와 Burp↔대상 사이에 별도의 TLS 연결이 생긴다. 브라우저는 대상 이름을 담은 Burp 발급 인증서를 검증하고, Burp는 실제 서버와 TLS를 협상한다.
• 각 구간의 검증따라서 브라우저가 실습 CA를 신뢰하지 않으면 경고가 발생하며, 정상적인 TLS 패킷 캡처만으로 평문을 읽는 방식과 구별된다.
• Intercept와 평문클라이언트의 인증서 고정이나 mTLS, 지원하지 않는 프로토콜 조건은 interception을 막을 수 있다. 이 실패는 웹 애플리케이션 자체가 중단되었다는 증거가 아니다.
• CA 신뢰내장 브라우저 또는 전용 프로필을 쓰면 실습 신뢰 저장소의 범위를 분명히 할 수 있다. 프록시가 TLS를 종료하는 순간 프로젝트 기록에는 평문 쿠키·본문이 남을 수 있으므로 캡처 화면에는 가상 값만 사용한다.

06Intercept·History·Repeater의 역할

• InterceptIntercept On에서 요청을 보류하면 대상 서버는 아직 해당 요청을 받지 않는다. Forward는 현재 요청을 다음 단계로 전달하고 Drop은 폐기한다.
• HistoryOff는 자동 전달 상태이며 HTTP history 기록까지 반드시 꺼진다는 뜻은 아니다. 화면이 멈춘 것처럼 보일 때 보류 중인 요청이 원인일 수 있다.
• RepeaterRepeater는 선택한 요청의 한 필드를 바꾸어 반복하고 응답을 비교하는 도구다. Cookie를 제거한 요청, 객체 ID만 바꾼 요청, CSRF 토큰을 제거한 요청은 서로 다른 가설을 시험한다.
• 요청 상태여러 필드를 동시에 바꾸면 어느 변화가 결과를 만들었는지 설명하기 어렵다. HTTP 응답 코드와 함께 본문·redirect·길이·서버 상태 변화를 읽는다.

07POST와 GET의 입력 위치 비교

• 메서드·입력 위치form body의 changeMe 필드를 query로 옮기고 메서드를 바꾸면 입력 위치가 달라진 요청을 비교할 수 있다. 이것은 메서드 이름만 바꾸는 일이 아니다.
• 서버 처리 차이서버가 파라미터를 query와 body 중 어디에서 읽는지, Content-Type에 따라 어떤 파서를 쓰는지, 라우트가 어떤 메서드를 허용하는지에 따라 결과가 달라진다.
• 가상 요청아래는 무해한 학습 값을 사용한 비교다. body를 제거하면 Content-Length도 현재 바이트 길이에 맞게 갱신하거나 제거해야 한다.
• HTTP 경계헤더와 본문 사이 빈 줄은 HTTP/1.1 메시지 구조를 나누므로 유지된다. 도구가 길이를 자동 계산하는지에 따라 편집 화면과 실제 전송 바이트가 달라질 수 있다.

POST /training/echo HTTP/1.1
Host: app.example.test
Content-Type: application/x-www-form-urlencoded
Content-Length: 14

message=lesson

비교 요청:
GET /training/echo?message=lesson HTTP/1.1
Host: app.example.test

[본문 없음]

원리를 설명하는 가상 학습 예시입니다.

11Intruder의 입력 조합이 요청 수를 바꾼다

• PitchforkPitchfork와 Cluster bomb는 여러 입력 위치를 조합하는 방식이 다르다. Pitchfork는 여러 목록에서 같은 순번을 하나씩 꺼내 각 위치에 넣는다.
• Cluster bomb두 목록이 [A,B]와 [1,2]라면 A/1, B/2가 된다. Cluster bomb는 조합을 모두 시험하므로 A/1, A/2, B/1, B/2의 네 가지가 된다.
• 조합 수순회 순서보다 입력 공간이 곱으로 커진다는 사실이 핵심이다.
• Sniper·Battering ramSniper는 한 위치씩 같은 입력 집합을 바꾸며 다른 위치를 기준 상태로 유지하고, Battering ram은 같은 입력을 지정한 모든 위치에 동시에 넣는다. 정상 형식 검증 실습에서도 위치 선택과 조합 방식이 잘못되면 의미 없는 실패가 대량 발생한다.
• 관찰 변수각 요청이 상태를 바꾸거나 세션 토큰을 소모한다면 단순 조합 반복의 결과를 독립 표본처럼 볼 수 없다.

12프록시 관찰의 한계와 재현 자료

• 상태 코드 한계프록시에서 200을 보았다는 사실은 권한 검사가 성공했는지, DB 상태가 바뀌었는지까지 말해주지 않는다. 응답에 오류 메시지가 포함된 200, 로그인 페이지로 이동하는 302, 비동기 작업의 202는 각각 다른 의미다.
• 요청·로그 연결요청 ID·시각·변경 필드를 서버 로그와 연결하면 요청 전달과 업무 결과를 구분할 수 있다.
• 재현 자료실습을 다시 할 때 필요한 자료는 도구 버전, 대상 애플리케이션 버전, 기준 요청, 수정된 필드, 응답 차이, 서버 상태, 초기화 방법이다. 실제 세션 값을 재사용 가능한 학습 자료에 남기는 대신 토큰 위치와 역할을 가상 값으로 표시한다.
• 환경과 결과환경을 복구한 뒤 기준 요청이 다시 동일한 결과를 내야 실험의 전제도 복원된 것이다.