[Web] Session과 Cookie

HTTP (HyperText Transfer Protocol)는 Connectionless & Stateless Protocol이다.

• Connectionless : Server는 Client에 응답 후 접속을 끊음
  (HTTP 1.1에서 Connection Header에서 keep-alive를 설정하면 Connection 유지가 가능함)
• Stateless : Server는 Client의 상태 정보를 알 수가 없다. 서로 연관된 request를 추적하는 방법 자체가 HTTP에서는 정의되지 않았다. 각각의 request는 독립적인 것으로 간주된다.

그러나, 로그인과 같은 상태를 파악할 수 있어야, request에 적절한 response를 전송할 수 있다.
(This requires identifying a user cross multiple requests)

그래서 HTTP에 Session과 Cookie를 활용한다.

 

 

1.  Session

user가 어떤 action을 할 때마다, 자동으로 제출되는 web page내에 form field가 있음

(The token is contained as a value of an input field.) server에서 session의 유효성을 판단한다.

세션은 server에서 관리함.

 

 

ex) 로그인 상황

1) client가 server에 로그인 요청

2) server는 client의 로그인 정보 확인 후, unique한 id를 sessionid라는 이름으로 저장

3) server는 응답 때마다 set-cookie : sessionid:xxx 를 추가하여 응답함.

4) client는 이후 server에 요청시 전달 받은 sessionid:xxx 쿠키를 요청 헤더에 추가하여 요청

5) server는 요청 헤더의 sessionid를 세션 저장소에서 찾아 유효한지 확인 후 응답

 

 

2. Cookie

Cookies는 Browser에 저장되는 name - value 쌍의 작은 data 파일이다. 이후 서버의 requests들에 자동으로 제출된다.

서버는 requests를 생성해서 client에게 전송하며, 'set-cookie' HTTP header를 이용하여 전송한다. 이후 Cookie는 "cookie" header를 통해 submitted 되며, header에 cookie 값을 추가하는 작업은 browser에서 처리한다. Cookie는 client에서 수정할 수 있기 때문에 항상 위변조의 위험이 존재한다.

 

ex) 로그인 상황

1) client가 server에 로그인 요청 진행 (post를 통해 정보 전송)

2) server는 client가 보낸 요청의 유효성 판단 후, cookie에 user 정보를 담아서 응답함 (set-cookie: user=b2narae)

3) 이후 client가 server에 요청시 전달 받은 쿠키를 자동으로 header에 추가하여 요청함

 

서버가 client에 보내는 set-cookie header에는 쿠키 생성을 위한 directives와 parameter가 있다.

이 set-cookie header를 통해 브라우저는 어떻게 언제 cookie를 submit할지를 결정하게 된다.

 

<대표적인 parameter, directives>

- parameter

• domain
• path
• expires

- directives

• secure : Cookie를 HTTPS를 통해서만 전송하라는 의미
• httponly : website의 JavaScript가 Cookie에 접근할 수 없도록 하라는 의미.

이 두 가지를 통해 XSS (Cross Site Scripting)을 방지할 수 있다.

 

 

---

 

<Application 개발시 user session에 대해 명심할 점>

 

1. HTTP를 통해서 어떤 token도 보내지 말 것, 대신 HTTPS 를 사용할 것 (unencrypted channel)

2. 유저가 로그아웃을 하면, user browser에 저장된 쿠키를 지우는 것만으로는 불충분하다.

3. 인증이 필요한 예민한 actions들에는 CSRF protection을 구현하기

4. GET request에 anti CSRF Token을 제출하지 않을 것

 

(CSRF : Cross Site Requst Forgery, 사이트 간 요청 위조

예를 들어, img 태그는 get 메소드를 사용하는 것인데, 페이지에 <img src="https://example-site/logout"> 과 같은 코드를 넣어주는 경우, 해당 문서를 보면 로그아웃이 됨)

 

5. sensitive한 token을 생성할 때는 항상 nonce나 padding을 사용하며, Base64와 같이 reversible한 encoding scheme은 사용하지 않을 것

6. sever 쪽에서도 plaintext 형태로, password를 저장하지 않을 것.

 

<참고>

https://www.geeksforgeeks.org/session-management-in-http/

https://chrisjune-13837.medium.com/web-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98%EC%9D%B4%EB%9E%80-aa6bcb327582