일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- active reconnaissance
- php To Do List
- access control
- php
- Leviathan
- OS Command Injection
- Server Side Request Forgery
- tryhackme
- ssrf
- BANDiT
- FTZ
- php 로그인 페이지 만들기
- SQLi
- Authentication
- Cryptography
- php login page
- Cookie
- War Game
- php 파일 업로드하기
- file upload
- overthewire
- privilege escalation
- THM
- 파일 업로드 취약점
- Recon
- active recon
- sql injection
- Reconnaissance
- php file upload
- over the wire
- Today
- Total
R's Hacking Daily Log
Cookie Policy 본문
Cookie Policy
Cookie policy란 Browser 측에서 실행되는 규칙으로
1. Cookie를 서버로부터 받을 때
2. Cookie를 request에 포함해 서버로 보낼 때
아무 Cookie나 저장하고 아무 데나 Cookie를 보낼 수는 없기 때문에 이와 관련하여
Cookie를 저장하고 보내는 과정(store & send)에서 만족돼야 하는 조건
을 정의한다.
Cookie Policy가 무엇인지 알아보기 전에 Cookie가 어떻게 생겼는지에 대해 먼저 살펴보자.
기본적으로 Cookie는 "name-value pair" 형태이다.
name | Theme |
value | Dark |
Domain | toon.sec.org |
path | /cryptography |
secure | True |
httpOlny | false |
expire | 12 Aug 2022 20:00:00 |
위와 같은 cookie가 있다고 할 때 각각의 속성이 나타내는 의미는 다음과 같다.
1) name = theme :: theme이라는 이름의 쿠키가 있는데
2) value = Dark :: theme cookie의 값은 Dark이다.
3) Domain = toon.sec.org & path = /cryptography ::
toon.sec.org/cryptography로 request를 보낼 때, 이 cookie를 같이 보낸다.
4) secure = True :: request를 보내는 protocol이 HTTPS여야만 이 cookie를 보낼 수 있다.
5) httpOnly = False :: javascript로 이 cookie에 접근이 가능하다.
6) expire :: 8/12/22 20시가 지나면 이 cookie는 자동으로 삭제된다.
** 여기서 cookie policy와 관련되는 속성은 domain & path이다.
Cookie가 어떻게 생겼는 지 알아봤으니 이제 Cookie policy에 대해 살펴보자.
cookie는 서버에서 만들어서 브라우저에게 전달되고 브라우저는 cookie jar에 cookie를 넣어 보관하다
관련 요청을 만들어 보낼 때 자동으로 쿠키를 요청에 함께 넣어서 서버로 전달한다고 했다.
2023.04.02 - [Daily-Note/web] - Cookie & Session & Token
이 과정에서 고려해야하는 부분이 크게 2가지 있다면,
첫 번째는 "서버가 보낸 쿠키를 저장할까 말까"이고
두 번째는 "서버에 요청 보낼 건데 이 쿠키 같이 보낼까 말까"이다.
각각의 상황에 대해 cookie policy에서는 다음과 같은 조건을 정의하고 있다.
store )
서버로부터 쿠키가 만들어져 왔을 때, 쿠키를 보낸 서버의 domain과 cookie의 domain 속성을 비교한다.
이때 서버는 cookie의 도메인이 자신의 도메인의 suffix가 되도록 cookie를 만들 수 있다.
** suffix = domain은 계층적인 구조를 가지는 데 suffix라 함은 전체 도메인 값 중 오른쪽 끝 값을 의미한다.
다시 말해 cookie의 도메인이 서버의 도메인 값에 포함되도록 설정할 수 있다는 것인데 예시를 보면,
:) server = mail.google.com인 경우, cookie domain = google.com으로 만들어질 수 있다.
:) server = google.com인 경우, cookie domain = google.com으로 만들어질 수 있다.
:) server = google.com인 경우, cookie domain = .com으로 만들어질 수 없다.
** 다만, cookie domain 값은 TLD일 수 없다.
2023.03.19 - [TryHackMe/Walkthroughs] - DNS in detail
서버의 Domain과 cookie domain을 비교해서 cookie domain이 server domain의 suffix임을 만족하면 브라우저는
이 쿠키를 저장하는 것이다.
Send )
쿠키를 request에 포함해 보낼 때는 store의 경우와 동일하게 domain을 비교하며 동시에,
path 값도 비교하게 된다.
Cookie Domain은 server의 Domain의 suffix여야한다는 조건에 더불어
Cookie path는 server path의 prefix여야 한다는 조건이 추가된다.
** prefix = suffix와 반대로 path 값의 맨 왼쪽 부분을 의미한다.
"https://toon.sec.org/cryptography/oneshots/~~.html"이라는 서버에 앞에서 살펴본 쿠키를 보낸다고 하면,
cookie의 domain이 toon.sec.org이고 path가 /cryptography이기 때문에 이 request에는 쿠키를 포함할 수 있다.
하지만 "https://toon.sec.org/bufferoverflow/..."이라는 서버에 동일한 쿠키를 보낸다고 하면,
cookie의 domain과 서버의 domain은 일치하지만 path가 /bufferoverflow & /cryptography로 다르기 때문에
이 request에는 쿠키가 포함되지 않는다.
'Daily-Note > web' 카테고리의 다른 글
SOP (Same Origin Policy) (2) | 2023.05.14 |
---|---|
DVWA로 보는 간단한 CSRF 실습 (0) | 2023.04.08 |
CSRF Defense (0) | 2023.04.08 |
XSS (0) | 2023.04.05 |
CSRF Attack (0) | 2023.04.04 |