웹 모의해킹 (HTTP 응답 메세지)

oolongeya

·

2021. 8. 28. 15:04

HTTP 응답 메시지
1
2
3
4
5
6
7
8
9
# HTTP 요청 메세지
===============================
<버전> <응답코드> <응답코드텍스트>
<헤더>
 
 
<바디>
 
 
cs

 

요청 메시지와는 첫 줄이 다르고 헤더와 바디는 동일하다.

 

버전

응답 메세지의 HTTP 버전을 알려준다.

 

응답 코드 / 응답 코드 텍스트

예: 200 OK 와 같이 숫자와 텍스트로 표시된다. 이 숫자는 status code 또는 응답 코드라고 한다.

요청이 성공했는지, 실패했는지 알려주는 용도이다. 텍스트는 사용자가 응답 코드를 쉽게 알아보기 위함이다.

 

응답 코드는 세 자리 수로 표현한다. (100번대 ~ 500번대)

앞자리의 숫자에 따라 응답 코드가 의미하는 바가 달라진다.

 

100번대 : 정보 전달 목적

200번대 : 요청이 잘 처리되었음을 알림

300번대 : 다른 웹 페이지로 리다이렉트할 필요가 있음

400번대 : 인증이나 잘못된 리소스 요청 등 클라이언트가 원인이 되어 발생한 에러

500번대 : 서버 쪽에서 에러가 발생

 

< 자주 사용되는 HTTP 응답 코드 >

응답 코드 종류 자주 쓰이는 응답 코드 및 텍스트 설명
1xx 101 Switching Protocols 프로토콜이 변경됨. 주로 웹 소켓 사용 시 발생함
2xx 200 OK 요청이 정상적으로 완료됨
201 Created 리소스 생성이 완료됨
3xx 301 Moved Permanently Location 헤더에 정의된 URL로 리소스가 이동되어 리다이렉트됨
304 Not Modified 캐시된 사본과 동일함. 즉, 리소스의 변경 내용이 없음
4xx 401 Unauthorized 인증에 실패함. 주로 아이디나 패스워드가 잘못되었을 때 발생함
403 Forbidden 리소스에 대한 권한이 없음
404 Not Found 해당 리소스 존재하지 않음
5xx 500 Internal Server Error 요청 처리 중 예상치 못한 서버 쭉 에러가 발생함

 

응답 헤더

요청 메세지와 같이, 응답 메시지도 여러 헤더를 포함할 수 있다. 형식은 동일하다.

 

Server

Server 헤더는 웹 서버와 웹 프레임워크의 버전 등의 정보를 알려준다.

보안상의 이유로, 버전 정보를 삭제하여 전송하는 경우도 있다.

비슷하게 X-Powered-By와 같은 헤더를 통해 웹 프레임워크와 관련된 정보가 노출되기도 한다.

 

Set-Cookie

Set-Cookie 헤더는 서버에서 클라이언트로 쿠키를 전달할 때 사용된다.

이렇게 전달된 쿠키는 웹 브라우저에 저장되고, 정해진 유효기간 동안 이후 요청 메시지의 Cookie 헤더를 통해 다시 전송된다. Set-Cookie 헤더의 형식은 다음과 같다.

 

Set-Cookie: <쿠키이름>=<쿠키값>; Expires=<날짜>; Path=<경로>; Secure; HttpOnly

 

쿠키 이름과 값을 설정하는 것은 필수이며, 그 이후의 옵션들은 생략될 수 있다.

 

옵션들은 다음과 같이 -기호로 표시하겠다.

 

- Expires

쿠키의 유효기간을 설정, Expires가 지정되지 않으면, 세션이 종료될 때까지의 유효기간을 가짐

일반적으로 웹 브라우저가 종료되면 세션이 종료되지만, 특별한 경우 서버의 구현 방법에 따라 세션이 유지되기도 한다.

 

- Path 

쿠키를 전송할 리소스의 경로를 지정한다. 지정된 리소스를 요청할 때 쿠키를 전송하게 되는데 서브 디렉터리까지 같이 매칭된다. 즉 /dir이라고 지정하면 /dir/sub1, /dir/sub2와 같은 서브 디렉터리에 있는 리소스를 요청할 때도 쿠키가 전송된다.

 

- HttpOnly

중요한 쿠키가 노출되지 않도록 보호하기 위한 옵션

공격자는 다른 사용자의 세션ID를 알아낼 때 크로스 사이트 스크립팅(XSS) 공격을 시도하기도 한다.

이때 XSS 공격은 자바스크립트를 이용하여 쿠키에 접근하여 쿠키 값을 가져온다. HttpOnly 키워드를 사용하면 쿠키 값이 자바스크립트에 의해 접근되는 것을 방지할 수 있다. 웹사이트에 XSS 취약점이 존재해도 세션 ID가 노출되는 것을 방지해서 추가 피해를 막을 수 있다.

 

- X-Frame-Options

이 헤더는 <frame>이나 <iframe> 등을 사용하여 웹 페이지가 출력되는 것을 제어하기 위한 헤더이다.

이와 같은 프레임을 이용하여 웹 페이지가 표시될 수 있는 경우, 클릭재킹(Clickjacking) 공격에 노출될 수 있다.

클릭재킹 공격은 공격자가 정상적으로 보이는 웹 페이지의 메뉴나 버튼 위에 마치 투명한 레이어를 추가한 것같이 악성 링크를 보이지 않게 숨겨두는 공격 유형이다. 사용자가 정상적인 기능을 수행하려고 해당 메뉴를 누르게 되면 숨겨진 악성 링크가 클릭된다.

 

이와 같은 공격을 방지하기 위해 X-Frame-Options 헤더를 사용할 수 있다.

이 헤더는 다음과 같은 값을 가진다

 

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

 

DENY 
어떠한 경우에도 프레임 내에서 웹 페이지를 표시하지 않도록 한다

SAMEORIGIN
같은 도메인 안에서 요청된 웹 페이지만 프레임으로 표시할 수 있도록 한다

 

- X-XSS-Protection

리플렉티드 크로스 사이트 스크립팅 공격이 탐지되었을 때, 웹 페이지가 로딩되는 것을 막아준다.

일반적으로 다음과 같이 사용한다.

 

X-XSS-Protection: 1;mode=block

 

 

-X-Content-Type-Options

 

MIME 스니핑을 차단하기 위해 사용하는 헤더.

MIME 스니핑은 컨텐트 스니핑 이라고도 하는데, 웹 브라우저가 특정 파일을 읽을 때 파일의 실제 내용가 Content-Type에 설정된 내용이 서로 다른 경우, 파일의 내용으로부터 파일의 형식을 추측하여 실행하는 것이다. 편리함을 위해 개발된 웹 브라우저의 기능이지만, 공격자에게 악용될 수 있다. 공격자가 HTML 코드를 jpg, png 등 이미지 파일로 만들어 업로드하는 경우를 가정해보자. 이후 그 파일을 읽은 사용자의 웹 브라우저는 비록 이미지 파일을 요청하더라도 MIME 스니핑에 의해 실제 파일의 내용이 HTML 형식인 것을 보고 HTML 코드를 실행할 수 있다.

이 경우 공격자가 HTML 코드 내에 악성 자바스크립트를 삽입해두면, 이 파일을 읽는 사용자는 XSS 공격에 당할 수 있다.

 

X-Content-Type-Options: nosniff

 

이 헤더를 적용하면 웹 브라우저가 MIME 스니핑을 하지 않도록 만들어줄 수 있다.

이 경우 웹 브라우저는 항상 Content-Type 헤더에 설정된 형식으로만 리소스를 처리하게 된다.

Content-Type 헤더가 이미지 파일 형식인 경우 이미지 파일로만 처리하게 되어 위와 같은 공격을 차단할 수 있다.

 

이 게시물은 최봉환 저자님의 화이트 해커를 위한 웹 해킹의 기술 서적을 정리한 글입니다.
글에 대한 정보와 저작권은 '화이트 해커를 위한 웹 해킹의 기술' 서적에 있습니다.
반응형