사용자가 브라우저를 통해 요청을 보내면 서버로 전송된다. 이때 서버의 종류는 온프레미스/IDC센터/클라우드 등 다양
서버의 구성요소

클라이언트로부터 가장 먼저 요청을 받는 웹 서버가 있다. NGINX의 역할은 들어온 요청을 적절한 위치로 라우팅 하는 것.
예를 들어 css, 이미지 파일같은 정적 콘텐츠를 요청하면 NGINX는 이를 찾아 바로 반환함.
하지만 동적 컨텐츠를 요구할 때는 요청을 서버로 전달하는데 이때 Tomcat, django, Node.js 같은 프레임워크들이 사용
들어온 요청을 처리하기 위해 필요한 데이터를 DB에서 찾거나 저장하는 등 접근을 한다. 처리가 완료되면 처리결과를 NGINX에 전달하고 NGINX는 클라이언트에게 결과 반환함.
GET 요청
클라이언트가 리소스를 요청할때 사용되는 http 메소드로, 요청하는 정보를 url에 포함하는 것이 특징이다(쿼리 파라미터).
웹 브라우저는 GET요청 결과를 자동으로 캐시에 저장해 동일한 요청이 보면 캐시에 저장된 결과를 반환함으로써 트래픽 절약+응답시간 절약하는 장점. GET 요청은 서버의 데이터 변조기능이 없어 서버입장에서 안전한 메소드에 속한다. 브라우저 히스토리에 기록되기 때문에 뒤로 가기 등을 할 때 이전에 방문한 사이트를 쉽게 찾아갈 수 있다
Response

가장 첫번째 부분에는 응답결과를 알려주는 HTTP 상태코드가 있다 종류가 매우 많으니 아래의 링크 참조
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
HTTP 상태 코드 - HTTP | MDN
HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고
developer.mozilla.org
상태코드 다음에는 헤더가 위치해 있고 응답의 길이와 서버, 콘텐츠의 종류 등을 알려준다. 다음에는 리소스 내용 Body가 들어있음
POST 메소드
클라이언트 측에서 서버로 데이터를 전송하는 데 사용되고 서버에 데이터를 생성하거나 업데이트하는 기능이 있다. 클라이언트가 서버 상태를 변경하는 명확한 의도가 있는 메소드라고 할 수 있음.
요청하는 데이터를 본문에 포함(json, xml 등의 형)하므로 GET 요청과는 다르게 전송하는 데이터 크기에 제한 X
그리고 웹 브라우저의 히스토리에 기억/캐싱되지 X → 같은 POST 요청을 여러 번 보내면 서버 상태도 바뀌는데 예를 들어서 글 작성 요청을 4번 하면 4개의 글이 생성됨.
메소드들의 버그헌팅 활용
버그헌팅에서는 사용자 입력값에 따른 서버의 반응을 관찰해야 한다
POST 메소드는 새로운 데이터를 서버에 등록하는 기능이 있어 본문에 전달하는 데이터를 변조, 조작했을때 서버의 반응을 확인할 수 있음. 입력 검증이 있지 않으면 기존 데이터 오염 가능함
PUT 메소드는 업데이트에 사용되는데 이 역시 검증을 거치지 않으면 다른 사용자의 정보를 변경할 수 있다.
OPTION 메소드는 서버가 지원하는 HTTP 메소드의 정보를 반환하는데 서버가 어떤 요청을 하는지, 특정 서버가 허용하면 안되는 메소드를 찾을 수 있음
TRACE 메소드는 서버 경로를 따라 메시지를 루프백 테스트를 수행하는데 요청이 서버에 도달하는 과정과 변경을 확인할 수 있다. 버그헌팅을 하는 입장에서는 서버에 대한 정보를 얻을 수 있다
서버로부터 예상치 못한 결과를 만드는 게 버그헌팅의 포인트!
Cookie&Session

사용자가 로그인을 위해 아이디와 패스워드를 입력하고 로그인 요청을 하면 서버에서는 이를 검증함. 검증에 성공하면 Set-Cookie라는 HTTP 헤더를 응답에 포함하는데 이 쿠키에는 세션 정보나 토큰같이 사용자를 식별할 수 있는 정보가 있다. 브라우저에는 이 Set-Cookie에 따라 쿠키를 저장한다. 사용자가 해당 사이트에 요청을 보낼 때마다 이 쿠키가 포함되어 서버가 사용자를 식별할 수 있게 한다.
여기서 알아야 할 HTTP Only 옵션이 있다!
HTTP Only
쿠키가 자바스크립트를 통해 로드되는 것을 방지하고 쿠키 도용을 제한하므로 XSS을 방지할 수 있다. 이 옵션을 설정한 쿠키는 HTTP, HTTPS 요청을 통해서만 서버로 전송되므로 스크립트를 통한 쿠키 정보 노출을 방지한다. 버그헌팅에서는 HTTP Only 옵션의 설정여부와 우회할 방법을 확인해봐야 함
User-Agent
HTTP 요청헤더 중 하나이며 클라이언트 종류, 버전 정보, OS 등의 정보를 서버에 전달해 서버가 사용자의 환경에 맞는 최적화된 응답을 제공할 수 있다. (모바일 or 데스크톱).
버그헌팅에서는 서버가 특정 브라우저나 환경에 따른 요청이 다른지 확인해 보는 방법이 있음. 그리고 서버의 예외 상황 처리, 특정 user-agent에 대한 부적절한 응답, 특정 user-agent에서 접근 가능한 서비스도 확인해 볼 수 있음
'웹해킹' 카테고리의 다른 글
[웹해킹] Authentication, Authorization, Input Validation 보안 매커니즘 (0) | 2025.03.08 |
---|---|
[웹해킹] HTTP 응답코드 종류, 프록시의 기능, Burpsuite의 주요 기능 소개 (0) | 2025.03.08 |
[웹해킹] 웹 어플리케이션 작동원리 Web Application (1) | 2025.03.06 |
취약점 리스크 정량화 산정방법, 버그헌팅을 위한 마인드 관리 (0) | 2025.03.06 |
버그헌팅 기초/종류/구성요소/프로세스 윤리적 해킹에 대하여 (0) | 2025.03.06 |