일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Reconnaissance
- SQLi
- php
- php To Do List
- privilege escalation
- Server Side Request Forgery
- FTZ
- php login page
- War Game
- sql injection
- 파일 업로드 취약점
- Cryptography
- OS Command Injection
- tryhackme
- overthewire
- php 파일 업로드하기
- Authentication
- php file upload
- ssrf
- access control
- Cookie
- Recon
- BANDiT
- Leviathan
- over the wire
- active recon
- php 로그인 페이지 만들기
- THM
- file upload
- active reconnaissance
- Today
- Total
R's Hacking Daily Log
Cookie & Session & Token 본문
Cookie
cookie에 대해 살펴보기 전에 cookie가 왜 필요한지에 대해 먼저 알아보도록 하자.
web을 사용하다고 하면 Application layer에서는 HTTP(s) 프로토콜을 사용한다.
HTTP의 특징 중 하나는 "Stateless protocol"이라는 것!
*Stateless = client가 보낸 요청에 대해 server가 그 어떤 내용도 유지하고 있지 않은 것을 의미한다.
server가 어디까지 처리했었는지, 어느 상태까지 진행되었는지 기억하지 않는 걸 말한다.
Stateless를 왜 언급했느냐!
를 설명하기 위해 어떤 쇼핑 사이트에 방문해서 로그인을 하고 A & B라는 상품을 각각 장바구니에 담는 상황을 상상해 보자.
1) 사용자는 우선 사이트에 방문할 것이고
2) 로그인을 한 다음에
3) A라는 상품 페이지에 들어가 장바구니에 담고
4) 다시 상품이 진열된 페이지로 돌아가
5) B라는 상품을 찾은 후 장바구니에 담을 것이다.
6) 마지막엔 상품이 잘 담겼는지 확인하기 위해 장바구니 페이지로 이동한다고 하면
사용자 입장에서는 두 개의 상품을 장바구니에 담은 간단한 과정이지만 사실 1~6번까지의 페이지 이동은 각각 다른 url을 갖는 request이고
web server는 이 6개의 request를 모두 독립적인 요청으로 받아들이고 처리한다.
따라서 HTTP만 본다면 1~6번까지의 요청이 처리될 때마다 로그인 상태가 유지된다?? 이건 말이 안 된다는 것이다.
흠 그렇다면 이런 부분을 어떻게 해결할 것인가..
이때 Cookie가 등장한다.
사용자가 처음 쇼핑 페이지에 접속해서 로그인을 하면 서버가 응답할 때 Cookie를 만들어서 같이 보낸다.
client는 자신의 쿠키 바구니(Cookie Jar)에 쿠키를 넣고 이후로 요청을 보낼 때마다 이 쿠키를 같이 넣어 보낸다.
서버는 쿠키 내용을 확인하고 나서 응답을 처리하며 결과적으로 사용자의 정보가 포함된 상태로(로그인된 상태로)
요청에 대한 페이지를 받을 수 있게 된다.
그렇다면 Session은 무엇일까??
어떤 요청을 보낼 때 browser가 쿠키를 넣어줬다고 해서 쿠키가 모두 유효하다고 할 순 없다.
그렇기 때문에 쿠키의 내용을 검사해 볼 필요가 있다.
server가 쿠키를 만들어 browser에게 보낼 때 server는 session이라는 것을 만들어 저장한다.
쿠키에는 sessionID라는 값이 포함되고 이 쿠키를 포함한 요청이 왔을 때 server는 자신이 가지고 있는 session 정보에서 sessionID와 일치하는 정보가 있는지 확인함으로써 쿠키를 검사한다.
cookie & session의 가장 큰 차이점은 cookie는 browser-side, session은 server-side에 저장된다는 것.
Token
마지막으로 토큰에 대해 알아보자.
놀이공원이나 콘서트장에 갔다고 상상했을 때 매표소에서 티켓을 구매한 다음 입구에서 티켓을 보여주면
손에 도장을 찍거나 종이로 된 팔찌를 채워주는 경험을 한 번쯤은 해봤을 것이다.
화장실을 가기 위해 입구에서 나갔다 들어갔다 하거나 놀이기구를 탑승하기 위해 팔찌를 보는 것도 한 번쯤 경험해 봤을 것이다.
이런 상황에서 콘서트는 몇 시간 후에 끝날 것이고 놀이공원도 문을 닫는 시간이 온다.
즉 구매한 티켓은 유효 시간이 있다는 것이다.
이 유효 시간 동안 "나는 티켓을 사고 입장한 사람이야!"라고 증명해 주는 도구로써 종이 팔찌를 사용했고
티켓을 구매해야 팔찌를 얻을 수 있다.
여기서의 티켓을 credential이라고 한다면 종이 팔찌가 Token인 셈이다.
로그인 하기 위해 개인 정보를 입력하고 "난 인증된 사람이야!"라는 것을 보이기 위해 Token을 사용한다.
browser를 통해 로그인을 시도하면 server는 입력된 개인정보를 보고 이 사람의 계정이 있는지 없는지 확인한다.
신원이 확인되면 응답 페이지와 함께 Token을 만들어서 browser에게 보낸다.
마치 검표원이 티켓을 확인하고 유효한 티켓이면 종이 팔찌를 채워주는 것처럼 말이다.
끝으로 덧붙이자면 Token은 cookie로 만들어진다.
Token 역할을 하는 cookie를 만들어서 사용하는 것으로 Token은 16진수의 랜덤한 값으로 만들어진다.
또한 위에서 말했듯이 유효 시간이 있기 때문에 일정 시간 후에는 소멸된다.
'Daily-Note > web' 카테고리의 다른 글
DVWA로 보는 간단한 CSRF 실습 (0) | 2023.04.08 |
---|---|
CSRF Defense (0) | 2023.04.08 |
XSS (0) | 2023.04.05 |
CSRF Attack (0) | 2023.04.04 |
HSTS (0) | 2023.03.15 |