개념 사전/정보보안 / 취약점 진단·실습 도구
개념 사전 · 프로그램

Burp Suite

버프 스위트 · 버프 수트

는 브라우저와 웹 서버 사이의 요청·응답을 관찰하고 조건을 통제해 비교하는 웹 보안 시험 도구다. HTTPS 가로채기에서는 브라우저와 프록시, 프록시와 서버의 두 연결을 구분한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: PortSwigger 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • Proxy 로 실제 요청의 메서드·헤더·쿠키·본문을 기록한다.
  • 로 가상 실습 요청의 한 조건씩 바꾸어 응답을 비교한다.
  • 인증 상태·리다이렉트·토큰 차이를 함께 보존해 재현한다.

02어떤 순서로 동작하나

  1. 수신 경로 연결

    브라우저 프록시 주소와 Burp listener를 맞추고 다른 서비스와 주소·포트가 충돌하지 않게 한다.

  2. 실습 CA 신뢰

    허가된 실습 브라우저에서 프록시가 발급하는 인증서를 검증할 신뢰를 구성한다.

  3. 첫 연결

    브라우저가 프록시가 제시한 대상 이름의 인증서를 검증하며 프록시와 를 맺는다.

  4. 두 번째 연결

    프록시가 실제 서버와 별도로 를 맺는다. 두 연결의 키와 인증 검증 문맥은 다르다.

  5. 요청 비교

    에서 forward/drop을 선택하고 ·에서 메서드·본문·쿠키·응답을 비교한다.

03먼저 알아둘 용어와 구성요소

요청이나 응답을 일시 정지하여 내용을 확인하는 기능.
프록시를 통과한 HTTP 교환 이력.
선택한 요청을 편집하고 반복 비교하는 기능.
실습 브라우저가 프록시의 동적 인증서를 신뢰하도록 설치하는 인증기관.
시험을 허가받아 관찰·처리할 대상 범위.
양 끝점 사이에서 상대 인증과 전송 자료 보호를 제공하는 프로토콜.
LEARN THROUGH PRACTICE

Burp에서 멈춘 요청과 서버에 도착한 요청 구분하기

프록시가 요청을 잡는 위치를 이해하고 브라우저 대기·전달·응답을 한 흐름으로 설명한다.

실습 구성과 전제

  • 자신이 운영하는 격리 와 전용 브라우저 프로필을 사용한다.
  • 브라우저 프록시가 Burp 리스너를 향하도록 설정하고 운영 계정·실제 비밀번호는 입력하지 않는다.

  1. Intercept가 요청을 보류하는 상태를 본다

    • 브라우저에서 로그인 페이지를 열고 가 켜져 있는지 확인한다. 프록시에서 멈춘 요청은 아직 서버 응답을 받지 않은 상태다.
    • Forward는 보류 요청을 다음 홉으로 보내고 Drop은 버린다. 브라우저가 멈춘 것처럼 보여도 우선 프록시의 대기 요청을 확인한다.
    Burp·Hydra 격리 로그인 실습 · BurpSuite원본 크기로 보기 ↗
    • Proxy→Intercept가 선택돼 있고 Intercept on·Forward·Drop 버튼이 보인다.
    • 목록의 요청은 GET이며 login.php를 향한다. 이 화면만으로 로그인 처리가 완료됐다고 볼 수 없다.
    확인 기준

    Forward 전후 브라우저 상태와 HTTP 에 응답이 생기는지를 비교한다.

  2. 헤더와 폼 본문을 나누어 읽는다

    • Content-Type이 application/x-www-form-urlencoded이면 본문은 이름=값 쌍이다. Cookie는 세션 식별 자료이고 본문의 user_token은 애플리케이션이 별도로 검사할 수 있다.
    • Content-Length는 글자 수가 아니라 전송 바이트 길이와 연결된다. 한글이나 URL 인코딩을 포함하면 보이는 문자열 길이와 다를 수 있다.
    Burp·Hydra 격리 로그인 실습 · BurpSuite원본 크기로 보기 ↗
    • 요청 헤더와 빈 줄 아래 폼 본문이 나뉘며 Content-Type·Cookie·Referer를 볼 수 있다.
    • 본문에는 로그인 입력과 user_token이 함께 있다. 이 값들은 실습 때 새로 받은 값으로 다뤄야 한다.
    확인 기준

    실제 계정·세션 값은 보고서에 붙이지 않고 필드 이름과 처리 결과만 기록한다.

  3. 한 필드씩 바꾼 요청을 비교한다

    • 에는 정상 요청을 기준본으로 보관한다. 무해한 테스트 입력 하나만 바꾸고 메서드·경로·쿠키·토큰·응답 상태를 비교한다.
    • 로그인 화면으로 돌아오면 입력 검증 실패뿐 아니라 세션 만료나 토큰 불일치를 함께 점검한다. 응답 길이 차이만으로 성공을 판정하지 않는다.
    확인 기준

    브라우저의 정상 기능과 같은 세션 조건에서 요청이 처리되는지 확인한다.

실습에서 확인한 동작 원리

  • 프록시 보류는 서버 장애와 다르다.
  • 요청의 메서드·헤더·본문·세션 상태를 함께 보존해야 비교가 재현된다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 문자열 선택: 교육용 입력 이름은 label, 값은 한글 가라고 가정한다. 실제 대상에 전송하지 않는 바이트 계산 예제다.
  • 표현: 가의 은 3바이트이며 label=은 ASCII 6바이트다. 단순 문자열 label=가는 9바이트다.
  • 폼 직렬화: 퍼센트 인코딩된 폼 본문 label=%EA%B0%80은 ASCII 15바이트다. HTTP 본문 길이는 이 전송 표현을 기준으로 계산한다.
  • 서버 해석: 폼 디코딩 후 애플리케이션에는 가라는 값이 전달된다. 서버의 입력 문자 수와 네트워크 본문 길이가 달라도 정상일 수 있다.
  • 비교 기록: Raw 요청·Content-Type·Content-Length·서버의 파싱 결과를 함께 기록하면 인코딩 오류와 애플리케이션 검증 오류를 구분할 수 있다.

05혼동하기 쉬운 점과 확인 기준

  • 인증 상태: 쿠키· 토큰·세션 만료를 비교한다. 오래된 요청을 다시 보내 받은 거부는 입력값 자체의 효과가 아닐 수 있다.
  • 요청 변형: Content-Length 갱신·줄바꿈 정규화·HTTP 버전 변환 설정을 기록한다. 편집기에서 보이는 문자열만으로 실제 바이트를 단정하지 않는다.
  • 응답 계층: 자동 압축 해제가 적용된 본문 길이와 Content-이 있는 원래 응답 길이를 구분한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

Kali·Burp로 웹 요청 관찰하기실습 도구는 요청과 응답의 구조를 드러내는 관찰 수단이다. 격리된 대상과 정상 요청을 기준으로 한 번에 하나의 조건을 확인한다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.