우리는 왜 GET/POST 로그를 분석하는가?

By PLURA

우리는 왜 GET/POST 로그를 분석하는가?

웹 보안에서 많은 공격은
방화벽이나 시그니처 하나로 끝나지 않습니다.

실제 공격은 보통 이렇게 진행됩니다.

  • 요청 안에 악성 입력이 숨어 들어오고
  • 서버가 그 입력을 처리하며
  • 응답으로 민감한 정보가 나가거나
  • 후속 행위가 이어집니다

이 과정에서 GET/POST 로그, 특히 POST Body를 포함한 요청 로그를 보지 못하면
공격의 핵심을 놓치기 쉽습니다.

즉, GET/POST 로그 분석은 단순한 웹 로그 수집이 아니라,
웹 공격의 실제 내용과 의도를 파악하기 위한 가장 기본적인 출발점입니다.

why_analyze_get_post_logs

HTTP란?

HTTP(Hypertext Transfer Protocol)는
클라이언트와 서버 간 통신을 가능하게 하는 프로토콜입니다.

웹은 기본적으로 요청–응답(Request–Response) 구조로 작동합니다.

  • 클라이언트가 요청을 보내고
  • 서버가 이를 처리한 뒤
  • 결과를 응답으로 돌려줍니다

HTTP 요청 방식에는 GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, CONNECT 등이 있지만,
일반적인 웹 서비스에서는 주로 GET과 POST가 가장 자주 사용됩니다.

보안 관점에서도 이 두 방식은 매우 중요합니다.
왜냐하면 실제 웹 공격의 상당수가 결국 GET 파라미터 또는 POST Body를 통해 들어오기 때문입니다.

GET 방식

/test/test_form.php?name1=value1&name2=value2

GET 방식은 URL(URI)에 데이터를 포함해 요청합니다.

즉, 요청 데이터가 주소창과 로그에 비교적 쉽게 드러납니다.

특징

  • 정보 노출 가능성
    요청 데이터가 URL에 포함되므로 브라우저, 프록시, 웹 서버 로그 등에 남기 쉽습니다.
  • 데이터 길이 제한
    URL 길이 제한 때문에 전송 가능한 데이터가 제한됩니다.
  • 주요 사용 사례
    검색어 전달, 페이지 번호 이동, 단순 조회 요청 등

보안 관점

GET 요청은 로그에 비교적 잘 남기 때문에
공격 분석이 더 쉬운 편입니다.

예를 들어:

  • 이상한 파라미터 조합
  • SQL 인젝션 시도 문자열
  • XSS 페이로드 일부
  • 관리자 페이지 탐색 시도

같은 것이 URL에 그대로 드러날 수 있습니다.

하지만 공격자가 정말 중요한 값을 숨기고 싶어 할 때는
보통 GET보다 POST를 더 선호합니다.

POST 방식

POST /test/test_form.php HTTP/1.1
Host: plura.io

name1=value1&name2=value2

POST 방식은 데이터를 HTTP Body에 담아 서버로 전송합니다.

즉, URL에는 드러나지 않고
본문(Body) 안에 실제 입력값이 담깁니다.

특징

  • URL 비노출
    데이터가 주소창에 직접 노출되지 않습니다.
  • 대량 데이터 전송 가능
    서버와 애플리케이션이 허용하는 범위 내에서 더 많은 데이터를 전송할 수 있습니다.
  • 주요 사용 사례
    로그인, 회원가입, 개인정보 전송, 파일 업로드, 결제 요청, API 호출 등

보안 관점

바로 이 점 때문에 POST가 중요합니다.

많은 실제 공격은 URL이 아니라 POST Body 안에 숨어 있습니다.

예를 들어:

  • 로그인 ID / 비밀번호 시도
  • SQL 인젝션 페이로드
  • XSS 스크립트
  • 파일 업로드 정보
  • API 입력값 조작
  • 관리자 기능 호출 파라미터
  • 크리덴셜 스터핑 계정 조합

즉, POST Body를 보지 못하면
중요한 공격의 상당수를 겉으로는 정상 요청처럼 보게 됩니다.

GET vs POST vs 보안 관점 비교

구분 GET POST
데이터 위치 URL / Query String HTTP Body
기본 노출성 상대적으로 높음 상대적으로 낮음
서버 기본 로그 반영 비교적 잘 남음 기본 설정만으로는 빠지기 쉬움
대표 사용 조회, 검색, 페이지 이동 로그인, 등록, 수정, 업로드, API
보안 분석 난이도 상대적으로 쉬움 상대적으로 어려움
공격에 자주 쓰이는 방식 단순 파라미터 변조, 탐색 시도 로그인 공격, SQLi, XSS, 웹쉘 업로드, API 오남용

핵심은 이것입니다.

GET은 공격 흔적이 드러나기 쉬운 반면,
POST는 공격의 핵심 내용이 숨어 있기 쉽습니다.

그래서 보안 관점에서는
GET 로그 분석도 중요하지만,
POST Body 분석이 훨씬 더 결정적입니다.

왜 POST 로그 분석이 더 중요한가?

많은 조직은 웹 서버 액세스 로그만 보고
“웹 로그는 이미 수집되고 있다”고 생각합니다.

하지만 이 경우 대개 남는 것은:

  • IP
  • URL
  • 상태 코드
  • User-Agent
  • 응답 크기

정도입니다.

문제는 실제 공격의 핵심이 여기에 없는 경우가 많다는 점입니다.

1) SQL 인젝션

공격자는 종종 POST Body 안에
SQL 구문이나 변형 페이로드를 넣습니다.

예를 들어:

  • 로그인 폼
  • 검색 폼
  • API 파라미터
  • 관리자 기능 입력값

URL만 보면 평범한 /login 요청이지만,
Body를 보면 공격 구문이 들어 있을 수 있습니다.

2) 크리덴셜 스터핑

로그인 공격은 대부분 POST 방식입니다.

단순 실패 로그만 보면
사용자 실수인지 공격인지 구분하기 어렵습니다.

하지만 POST Body를 함께 보면:

  • 어떤 계정을 시도했는지
  • 한 IP가 몇 개 계정을 돌렸는지
  • 어떤 조합이 반복되는지

를 더 정확히 파악할 수 있습니다.

3) 웹쉘 업로드

파일 업로드는 대개 POST입니다.

URL만 보면 정상 업로드처럼 보일 수 있지만,
Body나 업로드 관련 메타정보를 보면
악성 스크립트나 비정상 확장자 삽입 시도를 볼 수 있습니다.

4) API 오남용

현대 웹 서비스는 브라우저만이 아니라
모바일 앱, 파트너 시스템, 자동화 클라이언트가 모두 API를 사용합니다.

이때 실제 입력값은 거의 항상 POST Body 또는 JSON Payload 안에 들어 있습니다.

즉, POST Body를 보지 못하면
API 공격은 표면만 보고 지나갈 가능성이 큽니다.

실제 공격은 어떻게 POST Body에 숨어 들어올까?

다음은 단순화한 예시입니다.

정상 로그인 요청 예시

POST /login HTTP/1.1
Host: example.com

user_id=alice&password=********

크리덴셜 스터핑 의심 요청 예시

POST /login HTTP/1.1
Host: example.com

user_id=alice&password=123456

POST /login HTTP/1.1
Host: example.com

user_id=bob&password=123456

POST /login HTTP/1.1
Host: example.com

user_id=charlie&password=123456

개별 요청만 보면 단순 로그인 실패입니다.
하지만 전체 POST 로그를 보면

  • 동일 IP
  • 짧은 시간
  • 여러 계정
  • 동일 또는 유사 비밀번호

라는 패턴이 드러납니다.

즉, 공격은 한 건이 아니라 흐름으로 보입니다.

POST 로그가 없으면 무엇을 놓치게 될까?

POST 로그를 제대로 남기지 않으면
대개 다음을 놓치게 됩니다.

  • 로그인 공격의 실제 계정 조합
  • SQL 인젝션 실제 입력값
  • 파일 업로드 시도 내용
  • 관리자 기능 호출 파라미터
  • API Abuse의 실제 입력 패턴
  • XSS나 우회형 스크립트 페이로드
  • 비정상 자동화 도구의 요청 본문

즉,

POST 로그가 없으면 웹 공격을 “겉보기 현상”으로만 보게 됩니다.

예를 들면:

  • 로그인 실패가 많네
  • 업로드가 있었네
  • 에러가 떴네
  • 요청량이 많네

정도만 보입니다.

하지만 왜 그런 일이 발생했는지,
무엇이 실제로 들어왔는지는 보이지 않습니다.

PLURA는 GET/POST 로그를 어떻게 다르게 보나?

PLURA는 단순히 GET과 POST를 구분해 저장하는 데서 멈추지 않습니다.

핵심은 다음 세 가지입니다.

1) GET과 POST를 서로 다른 위험도로 본다

GET은 비교적 표면에 드러난 요청입니다.
반면 POST는 실제 입력값이 숨어 있는 경우가 많습니다.

PLURA는 이 차이를 전제로
요청 위치와 데이터 성격을 나누어 분석합니다.

2) POST Body를 공격 핵심 데이터로 본다

로그인, 업로드, 폼 입력, API 호출, 관리자 기능 호출 등
중요한 공격은 대부분 POST Body 안에 있습니다.

그래서 PLURA는
본문 데이터 자체를 보안 분석의 핵심 영역으로 봅니다.

3) 단일 요청이 아니라 흐름으로 본다

공격은 보통 한 번으로 끝나지 않습니다.

  • 탐색
  • 입력 시도
  • 응답 확인
  • 우회
  • 반복
  • 후속 행위

가 이어집니다.

PLURA는 GET/POST 요청을 개별 이벤트로만 보는 것이 아니라,
요청의 반복성, 응답 결과, 후속 행위까지 함께 보는 방향을 지향합니다.

즉,

GET/POST 분석의 목적은 단순한 분류가 아니라,
공격 흐름을 더 빨리 이해하는 데 있습니다.

PLURA 분석 결과는 어떤 의미를 가져야 할까?

원문에서는 PLURA가 다음을 제공한다고 설명합니다.

  • 공격 유형
  • 예상 피해도
  • 공격 목적 정보
  • 취약 경로
  • 대응 방안

이 메시지는 지금도 유효합니다.
다만 더 중요한 것은
이 결과가 어떤 데이터 위에서 만들어지느냐입니다.

즉, 의미 있는 분석 결과가 나오려면 먼저 필요합니다.

  • GET/POST 구분
  • POST Body 확보
  • 요청 맥락 분석
  • 반복 패턴 분석
  • 응답 결과 확인
  • 후속 행위 연계

이 전제가 없다면 “공격 유형”도, “대응 방안”도 신뢰하기 어렵습니다.

PLURA Agent GET 방식 웹로그 분석 예

GET 방식 분석 예시

PLURA Agent POST 방식 웹로그 분석 예

POST 방식 분석 예시

실무에서 POST 로그 분석을 강화하기 위한 체크리스트 ✅

항목 핵심 질문 체크
POST Body 수집 로그인, 업로드, API 요청의 Body를 필요한 범위에서 수집하고 있는가? □
민감 기능 구분 로그인, 관리자, 파일 업로드, 결제, API를 별도로 구분해 보고 있는가? □
반복 패턴 분석 동일 IP·동일 계정·동일 파라미터의 반복 시도를 추적하는가? □
응답 연계 분석 요청뿐 아니라 응답 결과까지 함께 보고 있는가? □
오탐 제어 정상 사용자 행위와 공격 패턴을 구분할 기준이 있는가? □
후속 행위 연계 웹 요청 이후 서버 내부 행위까지 연결 분석 가능한가? □

✍️ 결론

GET과 POST는 단순한 HTTP 전송 방식 차이가 아닙니다.

보안 관점에서 보면:

  • GET은 비교적 흔적이 잘 남는 요청이고
  • POST는 공격의 핵심 내용이 숨어 있기 쉬운 요청입니다

그래서 POST 방식으로 들어오는 공격은
기록되지 않거나 충분히 분석되지 않으면
훨씬 더 위험해질 수 있습니다.

POST Body를 보지 못하면,
실제 웹 공격의 핵심을 놓칠 가능성이 매우 높습니다.

우리는 왜 GET/POST 로그를 분석해야 할까요?

그 이유는 단순합니다.

  • 공격은 요청 안에 숨어 들어오고
  • 의도는 본문 안에 담기며
  • 위험은 반복 패턴과 흐름에서 드러나기 때문입니다

즉, GET/POST 로그 분석은
단순한 데이터 기록이 아니라
웹 공격을 이해하고 선제적으로 대응하기 위한 가장 기본적인 보안 행위입니다.

그리고 바로 이 지점에서
PLURA의 GET/POST 및 본문 로그 분석은 의미를 가집니다.

  • 요청 데이터를 실제로 보고
  • 숨겨진 POST Body를 분석하고
  • 공격 유형과 흐름을 더 빨리 이해하는 것

이것이 웹 보안 운영의 출발점입니다.

📖 함께 읽기

Tags