LocalStorage v.s. SessionStorage
==========================
###### tags: `JS`
# XSS攻擊
Cross-Site Scripting
攻擊手法, 駭客把一段它的script放到目標網站的目標瀏覽器上執行!
基於使用者對網站的信任
資料從不可信賴的來源 進到後端, 且後端再傳送未經驗證的資料到瀏覽器中, 導致瀏覽器執行惡意的程式碼.
XSS攻擊兩大要素:
1. 攻擊者提交惡意代碼
2. 瀏覽器執行惡意代碼: 防止HTML中出現注入HTML/JS, JS執行時避免直接Eval(js)
1. 惡意代碼, 透過後端存入DB, 並且被API撈出來在前端中執行.
把代碼做escape.
2. 把釣魚URL含JS, 一樣透過API返回, 用戶只要打開惡意URL就生效.
3. 惡意HTML, 一樣透過API返回, 讓JS渲染.
## 反射型
透過URL注入, 並把該內容返回給瀏覽器執行
## 存儲型
server收到惡意script後, 存放到database, 下次瀏覽相同頁面時, 就被撈取出來執行.
# Web Storage
## Local Storage
是client產生的, 並不會主動把該數據傳送給server, 僅保存在local, 不會主動刪除, 需要手動刪除.
## Session Storage
跟local storage類似, 但差別在life time, 在瀏覽器是窗關閉時, 就會刪除數據; 甚至在同一個瀏覽器但不同分頁時, 數據也不共享.
```javascript=
JSON.stringify(localStorage);
# 植入一些惡意代碼, 在前端依然可以歷尋所有的web storage內的內容, 並且修改後, 用來請求API, 就能串改了
```
從代碼演示能看出不管哪個storage都能被JS給訪問修改.
甚至也能被惡意JS給仿冒身分.
好處就, 不會主動觸發CSRF, 因為不會每次請求都夾帶這資訊.
## Cookie
Cookie可以由server或是client產生, 每次請求都會夾帶該資訊.
Cookie早期也是很容易被XSS攻擊, 因為能被外部的js存取.
後來在[RFC6265](https://datatracker.ietf.org/doc/html/rfc6265)中提出了HttpOnly, 用來防範XSS.
### HttpOnly
只要Cookie有設置HttpOnly屬性時,
瀏覽器會限制cookie只能經驗http(s)來存取, 並且攻擊者無法透過JS來存取有設置該屬性的cookie.
### Secure
只要Cookie有設置該屬性時,
cookie只能透過https傳送
透過上面幾個屬性, 在身分驗證上的cookie都會採取剛剛的屬性配置, 並加上expires.
越安全的防護, 使用上就會越困難!
Sign in with Wallet
Connect another wallet