웹 애플리케이션 기술

HTTP는 메시지 기반 모델로서 클라이언트가 요청 메시지를 보내고 서버가 그에 대한 응답 메시지를 보내는 방식이다. 요청과 응답에 대한 교환은 독립적으로 취급돼 각기 다른 TCP 연결을 사용한다. 따라서, 비연결지향적 프로토콜이라고 한다.

HTTP 메소드

- GET 메소드 : 웹서버에 있는 자원을 얻을 때 사용하며, 요청된 자원의 URL 쿼리 문자열에 인자 값을 보내는 용도로도 사용할 수 있다. 이를 통해 사용자들은 URL을 동적인 자료로 즐겨찾기에 저장해두고 나중에 같은 자원을 찾을 때 활용할 수 있다.

- POST 메소드 : 특정 행동을 시작할 때 사용한다. POST 방식을 이용해 요청 인자를 URL 쿼리 문자열이 아닌 메시지의 바디에 보낼 수 있다.

- HEAD 메소드 : 요청과 비슷하게 작동하는 메소드지만 메시지 바디를 보내지 않는다는 차이가 있다. GET 요청에 대한 응답으로 보내야 할 헤더와 같은 종류의 헤더를 보내므로 GET 요청을 하기 전 자료가 있는지 확인할 때 사용한다.

- TRACE 메소드 : 클라이언트와 서버 사이에서 어떤 프록시 서버가 요청을 조정하는지 여부를 판단할 때 사용될 수 있다. 가끔 다른 애플리케이션 사용자를 공격하는 악의적인 용도로 사용할 수도 있다.

- OPTIONS 메소드 : 특정 자원에 맞는 HTTP 방식을 알려달라고 서버 측에 요청할 때 사용하며 이에 대한 응답으로 Allow 헤더에 사용할 수 있는 모든 메소드 리스트를 클라이언트에게 보여준다.('메소드 리스트를 보여주니까 Vector 선정에 도움이 되지 않을까?'라는 생각이 든다.)

- PUT 메소드 : 애플리케이션을 공격할 때 유용한 메소드로 임의의 스크립트를 서버에 올려서 실행할 수도 있다.

URL은 웹 자료 고유의 이름으로 자원을 검색할 때 사용한다.

프로토콜://호스트명[:포트 번호]/[경로/]파일명[?param=값]

웹사이트를 공격할 때 사용되는 HTTP 헤더

- 일반적인 헤더

① Connection : HTTP 전송이 완료된 후에 TCP 연결을 차단할지, 다른 메시지를 받기 위해 열어둘지를 결정한다.

② Content-Encoding 메시지 바디 내용에 어떤 종류의 인코딩을 사용할지 정할 때 쓰인다.

③ Content-Length : 메시지 바디 길이를 나타낼 때 사용된다.

④ Content-Type : 메시지 바디에 들어있는 컨텐츠 종류를 나타낸다.

⑤ Transfer-Encoding : 메시지 바디가 HTTP 전송을 쉽게 하게 도와주는 인코딩 방법을 보여준다.

- 요청 헤더

① Accept : 클리이언트가 그림 파일이나 문서 형식 등 어떤 종류의 내용을 수락할 것인지 서버에게 알리는 역할을 한다.

② Accept-Encoding : 클라이언트가 어떤 종류의 인코딩된 문서를 받아들일지 서버에게 알리는 역할을 한다.

③ Authorization : HTTP 인증 형태에서 사용자의 식별 정보를 서버에게 보낼 때 사용한다.

④ Cookie : 서버로부터 받은 쿠키를 다시 서버에게 보내주는 역할을 한다. 실제 이 Cookie를 통해 서버는 사용자를 식별한다.

⑤ Host : 요청된 URL에 나타난 호스트명을 상세하게 나타낼 때 사용한다.

⑥ If-Modified-Since : 브라우저가 마지막으로 요청 자료를 받은 시간을 나타낸다.

⑦ If-None-Match : entity tag를 지정하기 위해서 사용한다. entity tag는 메시지 바디의 내용을 식별해주는 역할을 한다.

⑧ Referer : 현재 요청이 처음 시작된 곳의 URL을 나타낸다.

⑨ User-Agent : 요청을 하는 브라우저에 대한 정보를 나타낸다.

- 응답 헤더

① Cache-Control : 캐시에 대한 지시를 브라우저에게 전달하는 역할을 한다.

② Etag : entity tag를 나타낼 때 사용하며, 현재 브라우저의 캐시에 어떤 버전의 자료를 가지고 있는지 서버에게 알릴 수 있다.

③ Expires : 브라우저는 요청한 자원에 대해 Expires 시간까지 클라이언트의 하드에 저장된 복사본 내용을 사용한다.

④ Location : 재전송하는 응답에서 목적지를 나타내는데 쓰이며 상태 코드 3부터 시작한다.

⑤ Pragma : 브라우저에게 no-cache와 같은 캐싱 지시를 보내기 위해 사용한다.

⑥ Server : 사용하고 있는 웹서버의 소프트웨어에 대한 정보를 제공한다.

⑦ Set-Cookie : 쿠키를 생성하고 브라우저에 보낼 때 사용한다.

⑧ WWW-Authenticate : 401 상태 코드와 함께 응답할 때 사용한다.

쿠키는 웹 애플리케이션이 사용자를 구분할 때 사용하는 HTTP 프로토콜의 중요한 요소다. 공격자가 웹 애플리케이션의 취약점을 찾을 때 쿠키를 많이 사용한다.

상태 코드

- 1xx : 정보를 제공함

- 2xx : 요청이 성공적으로 이뤄짐

- 3xx : 요청한 해당 자원이 다른 곳에 있음

- 4xx : 요청(클라이언트)에 문제가 있음

- 5xx : 서버에 에러가 있음

• 100 Continue : 클라이언트가 서버에게 메시지 바디를 포함한 요청을 보냈을 때 받는 응답 코드다. 서버의 응답에는 클라이언트가 요청한 헤더를 전송 받았고, 클라이언트는 계속해서 서버에게 바디를 보낼 수 있다고 나타낸다.
• 200 OK : 클라이언트의 요청이 성공했다는 것을 나타낸다.
• 201 Created : 클라이언트의 PUT 요청이 성공적이라는 것을 나타낸다.
• 301 Moved Permanently : 브라우저의 요청을 다른 URL로 항시 전달한다는 것을 의미한다. 다른 URL에 대한 정보는 Location 헤더에 나타난다.
• 302 Found : 브라우저의 요청을 임시 URL로 바꾸고 Location 헤더에 임시로 변경한 URL에 대한 정보를 적는다.
• 304 Not Modified : 브라우저가 서버에게 요청한 자료에 대해 서버는 클라이언트 내에 복사된 캐시를 사용하게 한다. 서버는 If-Modified-Since와 If-None-Match 요청 헤더를 사용해 클라이언트가 가장 최근의 자료를 가지고 있는지 여부를 확인한다.
• 400 Bad Request : 클라이언트가 서버에게 잘못된 HTTP 요청을 했다는 것을 나타낸다.
• 401 Unauthorized : 서버가 클라이언트의 요청에 대해 HTTP 인증 확인을 요구하는 것을 의미한다. www-authecticate 헤더는 인증과 관련된 내용을 지원하는 다양한 타입에 대한 정보를 담고 있다.
• 403 Forbidden : 클라이언트의 요청에 대해 접근을 차단한다는 것을 나타낸다.
• 404 Not Found : 클라이언트가 서버에게 요청한 자료가 존재하지 않는다는 것을 나타낸다.
• 405 Method Not Allowed: 클라이언트가 요청에 이용한 메소드가 해당 URL에 지원이 불가능하다는 것을 나타낸다.
• 413 Request Entity Too Large : 클라이언트가 요청한 바디를 서버에서 처리하기에는 너무 크다는 것을 나타낸다. 버퍼 오버플로우의 취약점이 발생할 때 이 상태 코드를 보게 된다.
• 414 Request URI Too Long : 요청에 사용된 URL이 서버가 감당할 수 없을 만큼 너무 크다는 것을 나타낸다.
• 500 Internal Server Error : 서버가 클라이언트의 요청을 실행할 수 없을 때 발생한다.

HTTP 프로토콜은 데이터가 네트워크 장비를 통과할 때 암호화되지 않은 단순한 TCP를 사용하기 때문에 네트워크에 잠입해 있는 공격자가 중간에 정보를 가로챌 수 있다. HTTPS는 HTTP와 같이 애플리케이션 계층 프로토콜로 SSL(Secure Sockets Layer)을 이용해 클라이언트와 서버 사이에 주고받는 정보를 보호하는 데 사용한다.

HTTP 프록시 서버는 클라이언트 브라우저와 목적지 웹서버 간에 중개 역할을 한다. 대부분의 프록시는 캐싱, 인증, 접근 통제와 같은 서비스를 제공한다. HTTPS를 사용하면 브라우저는 프록시 서버와 SSL 핸드셰이크를 할 수 없게 된다. 공격자들이 보안 터널을 뚫고 중간에서 정보를 가로채는 것을 막기 위해 HTTPS를 이용한다. 따라서, 브라우저는 TCP 레벨의 릴레이로 프록시 서버를 사용해야 한다. TCP 레벨에서 사용하는 프록시는 HTTPS를 이용하는 브라우저에서도 목적지 웹서버와의 모든 통신을 가로챌 수 있다.

HTTP에서 애플리케이션에게 인자를 보낼 때 사용하는 세 가지 방법

- URL 쿼리 문자열을 이용하는 방법

- HTTP 쿠키를 이용하는 방법

- 요청 바디에 POST 방식을 이용하는 방법

인코딩 스키마

- URL 인코딩 : 확장된 아스키 문자 내에서 문제가 있는 문자들을 인코딩할 때 사용된다.

%3d =

%25 %

%20 space

%0a new line

%00 null byte

- 유니코드 인코딩 : 유니코드는 문자 인코딩의 표준으로, 전 세계에 쓰이는 모든 문서 작성 시스템을 제공한다. 

%u2215 /

%u00e9 e

가끔 입력 승인 메커니즘을 공격할 때 사용 된다.

- HTML 인코딩 : 문제가 있을만한 문자들을 인코딩하여 안전하게 HTML 문서와 함께 사용하게 한다.

"    "

'    '

&    &

&lt;        <

&gt;       >

크로스사이트 스크립팅 취약점을 찾을 때 HTML 인코딩을 눈여겨봐야 한다.

- Base64 인코딩 : 모든 바이너리 데이터들을 출력 가능한 ASCII 문자들을 통해서만 안전하게 나타낼 수 있게 한다. 입력 데이터를 세 바이트 블록으로 나눈 뒤 각 블록을 다시 6비트씩 네 부분으로 나눈다. 6비트의 데이터는 2^6으로 64개의 문자로 쉽게 나타낼 수 있다. Base64 인코딩 스트링을 그 만의 특정한 문자 집합과 스트링의 마지막에 나타난 = 문자들 때문에 쉽게 구별할 수 있다.

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

<Base64에 사용되는 문자 세트>

- Hex 인코딩