# front-end security
### (SECURE) Development Lifecycle
- Software Development Lifecycle (SDLC)
- 一般常見的軟體開發週期
- Secure Software Development Lifecycle (SSDLC)
- 是一種在軟體開發過程中整合安全性的**方法論**。
- 目標是在軟體開發的==每個階段==，從需求分析到維護，==保證軟體的安全性和可靠性==。
### Security Testing
1. 弱點掃描 Vulnerability Scanning
- 通常是自動化的過程
2. 漏洞評估 Vulnerability Assessment
- 需要人工進行各種測試和分析
- 使用漏洞掃描工具進行檢測
3. 滲透測試 Penetration Test
- 會模擬攻擊者的行為對系統、應用程式或網路進行模擬攻擊以發現和評估系統中存在的漏洞和弱點 😈
4. 紅隊演練 Red Teaming
找一組人扮演駭客，模擬駭客對企業發動網路攻擊，製造一種相當於遭遇駭客攻擊的情境來考驗企業的防禦，並且累積第一線事件回應的經驗。

> [!INFO] > Secure Coding
> 然而測試並非就不會有疏忽，開發工程師在編寫代碼時就應盡可能地避免漏洞的出現～


---

### XSS 跨站脚本攻擊
*Cross-Site Scripting*
網站上被攻擊者植入惡意的程式碼 🥲
> [!WARNING] > Don’t trust user input/request

現代框架 React, Vue... 都有做一些基本的 XSS 防範～
但這樣就夠了嗎 🙃？

function Profile({name, avatar, url})(
	<div>
		<h3>{name}</h3>
		<img src={avator} />
		<a href={url}>Website</a> 
	</div>
)

#### Javascript pseudo protocol

function Profile({name, avatar, url})(
	<div>
		<h3>{name}</h3>
		<img src={avator} />
		<a href="javascript:alert(1)"}>Website</a>  // 😈
	</div>
)

- 是一種用 JS 來操作 `HTML DOM` 的方法。`javascript:`
- 初期的 Web 瀏覽器中，各種技術和規範還沒有被完全制定和普及，開發人員往往需要使用 `JS Pseudo Protocol` 來繞過瀏覽器的限制，實現一些網頁交互的功能，如彈出窗口、執行腳本等。
- 現在常被駭客當成一種攻擊手段，用來盜取敏感信息、偽造用戶身份、篡改網頁內容等。

❗️如今我們應該避免使用以確保網站的安全性和性能～
❗️以下是一些可以使用 `JS Pseudo Protocol` 需特別注意的情境：

<a href="javascript:alert(1)" />
<form action="javascript:alert(1)" />

// 👇 三個需要更加注意 因為他們可以載入 subResource 
<iframe src="javascript:alert(1)" />  // top.location = 😈
<object data="javascript:alert(1)" />
<embed src="javascript:alert(1)" />

windows.location = "javascript:alert(1)"
windows.href = "javascript:alert(1)"
windows.replace("javascript:alert(1)")
windows.assign("javascript:alert(1)")

##### 👉 Mitigation
列舉白名單的方式～

// 我檢查 javascript: 就好啦～
<a href="&#106;avascript:alert(1)" />  // nice try 😈

- 設置 [[CSP Content Security Policy]]
- ~~`unsafe-inline `~~ -> `nonce` 或 `hash`
- (google.com) 也不是絕對沒問題 還是有 `jsonp`... 之類的漏洞
![[Pasted image 20230304182332.png|500]]
![[Pasted image 20230306015804.png]]
![[Pasted image 20230306015911.png]]
- URL 的檢查
- `http://` or `https://`
- 使用 `new URL()` 去檢查 protocal
- `iframe` 可以設置 `sandbox` 屬性

<iframe sandbox="" />

// sandbox="allow-download"
//         "allow-popups"
//         "allow-form"
//         "allow-modals"

[w3schools iframe sandbox](https://www.w3schools.com/tags/att_iframe_sandbox.asp)
- `javascript: false`
---

### CSRF 跨站請求偽造
*Cross-Site Request Forgery*
![[Pasted image 20230306163015.png|600]]
是一種常見的網絡攻擊方式，攻擊者利用用戶已經登錄了一個網站的狀態，通過偽造請求（通常是鏈接或圖像），使用戶在不知情的情況下發送一些不必要的或有害的請求到另一個網站，從而導致被攻擊網站的某些行為發生不良的變化。
- 竊取密碼
- 重複扣款
##### 👉 Mitigation
- CORS
設置 header
- CSRF token
- same-site `Access-Control-Allow-Origin`
- `sameSite` 是一種 `cookie` 的屬性。
它限制了瀏覽器是否允許發送 cross site 的 cookie。從而防止 CSRF 攻擊。
- `sameSite` 屬性
- `Strict`
只在 first-party 的環境下允許帶入 cookie
- `Lax`
允許一些即使是 cross-site 的環境也能帶入 cookie
（即允許 `GET` request 且會觸發瀏覽器 `Navigation` 行為的情境不需再重新登入）
- 在網址列輸入輸入網址
- 點擊連結  `<a href="...">`
- 送出表單 `<form method="GET">`
- 背景轉譯 `<link rel="prerender" href="...">`
- `None`
想要送出 Third-party cookie 就必須設定為 `SameSite=None; Secure` ...
- 不是每個瀏覽器都支援（Hi safari 🙂）
- ** 2020 Chrome 將 `Cookie` 的 `SameSite` 屬性預設為 `Lax`
使用到 Third-party cookies 的服務若沒有設定 SameSite 都可能受到影響：)
![[Pasted image 20230305130513.png|500]]

origin vs site
![[Pasted image 20230305125050.png|500]]

---

### Others attacks
Prototype Pollution
mitigation:
`Object.create(null)` -> 之間建立 object 不會有 prototype
`Object.freeze(Object.prototype)` -> 防止人家竄改 Object
`hasOwnProperty`

CSS Injection
:has() -> new selector
![[Pasted image 20230305232059.png|500]]
XSLeak