Beyond XSS 2-1 ~ 2-3

[chuchiang]

《Beyond XSS》從 XSS 開始談前端資安 2-1 ~ 2-3

20241031 2-1~2-3

導讀人：Steven
筆記工：Lulu

2-1章節回顧

1. Sanitization 和 Encoding 的差異為何？什麼情境下應選擇其中一種方式來防範 XSS？

• Encoding 單純的去轉換編碼，Sanitization 刻意的去保留一些TAG，來確保我們在做 Sanitization 的過程中， 留下的是安全的 Html 內容；如果想要顯示出來的是純文字內容，要使用 Encoding，如果今天想要顯示的是 Html 文本內容，就要使用 Sanitization 做防範。

2. 為何不建議使用非專門處理 Sanitization 的函式庫（如 BeautifulSoup）來進行 XSS 防護？

• 雖然說 BeautifulSoup 可以把標籤名稱跟屬性去解析出來，然後自行去過濾，但跟自己做是一樣的意思，所以建議還是用專門去處理 Sanitization 的 library 去做，專門的苦以去做到自己想不到的東西會比較完整。

3. Sanitization 後進行後續處理為何會導致 XSS 風險增加？

• 會導致 Sanitization 被破壞，是因為淨化之後又去做操作，例如：去轉字串，攻擊者可以在後面的 function 去做駭入，你可能會假設這個東西是乾淨的，但這個假設應該也是錯的，應該要把 DOMPurify 放到最後一個步驟。

4.如何在設計中避免破壞 Sanitization 效果的後續處理？

• 如果在 Sanitization 後面做額外處理，會把安全的東西變不安全，應該要把 DOMPurify 放到最後一個步驟。

討論：

1. 對於前端工程師來說什麼時候需要做 Sanitization?

• 如果使用者要在 element 系統自己上文字稿，在前台會使用到 innerHTML ，把後端拿到的資料撈進去。
• 如果前端有使用 CKEditor，讓使用者去新增 HTML 內容，這個時候就需要做 Sanitization。

2. handlebarsjs 的 template 解析是怎麼處理的，兩個括號幫你做的事情是什麼?

• {{}}：自動 HTML 轉譯
• 作用： 將插入的數據自動轉換為 HTML 安全的格式
• 目的： 防止 XSS (跨站腳本攻擊) 等安全漏洞
• 行為： 會將特殊字符（如 <, >, & 等）轉換為 HTML 實體（例如 <, >, &）
• 有做編碼轉換，維護較舊程式碼可能會遇到
• 不是做 Sanitization，是做編碼轉換，例如：＜編碼成&lt，變成純文字而不是去掉(Encoding )
• https://handlebarsjs.com/guide/#html-escaping
• https://github.com/handlebars-lang/handlebars.js/blob/master/lib/handlebars/utils.js#L61
• 如果使用者在前端輸入 JavaScript 偽協議的內容，雖然編輯器會擋下，若攻擊者知道 API，直接使用打 API 的方式去打，前端收到後端資料直接去顯示還是會有危險，建議前端收到後端資料時還是要做處理，因為可能資料有被更改過，確認 OK 再顯示。

3. 到底要前端做還是後端做，或是全部都做?

• 如果 Encoding 是後端做，就代表是把資料存進去 DB 前需要做的事情，存的資料是已經處理過的資料，但是會遇到例如： HTML 呈現的載體可能是不一樣的，某段字簡訊寄出，如果編碼過 < 就會變成 &lt，不是原本想要呈現的內容，所以建議資料庫存的時候，就存資料原始樣子，後端不要特別處理，而是在每個前端，除了網頁還會有其他前端手機等等，在渲染前才去做處理。
• 理想上不管後端傳什麼進來，前端都需要做完 Sanitization，再呈現出來。

---

2-2章節回顧

1. 為什麼 XSS 防護需要設定 CSP 作為第二道防線？請說明開發上導致 XSS 漏洞的三個常見的原因。

• 第一道防線，處理使用者輸入，例如：Sanitization 和 Encoding，若第一道防線失效，就可以設定 CSP 安全政策，來阻止 script 或其他資源來載入，所以需要 CSP 來設定第二道防線。
• 不知道這樣子寫會出事情，例如：a 標籤 href 可以寫偽元素；忘記這樣做會有問題；知道這樣做會有問題，但基於其他原因，而繼續做；以上三個原因導致資安問題。

2. 在 CSP 中，如何限制 JavaScript 的執行來源？舉兩個常見的規則。

• 限制指定域名
• script-src 'self' https://trusted-cdn.com;
• 使用 nonce 去驗證
• script-src 'nonce-random123' 'strict-dynamic';
• 補充：很多網站會用 GA 腳本或 FacebookSDK 工具，這兩個東西也會出現在上面
• 若在網站上使用 Google Analytics 或其他需 inline script 狀況，如何在不使用 unsafe-inline 的情況下允許該 script 執行。
• 不使用 unsafe-inline 可以用 nonce，或先設定 script-src 的 self nonce 的隨機序，讓他可以去崁入設定的 script 腳本被允許，再搭配 hash 執行裡面要執行的 JavaScript 程式。

3. CSP 的 Report-Only 模式有什麼作用？如何利用此模式來測試和優化 CSP 設定？

• Report-Only 可以設 CSP 規則，違反情況發生時不會實際的去阻擋他執行，但會把違反狀況去寄到你指定的 URL ，就可以用這種方式看 CSP 規則會不會阻擋到使用者正常操作和執行，再一直去微調 CSP 使用規則，所以不安全方式就是 unsafe-inline 腳本。

討論：

1. 這種問題是公司要求去加，還是自己發現去加？

• 通常會有安全部們的人來說要加。

2. 用 React 要如何去拿到 nonce 的值？

• Next.js 放在 middleware 這一層，會在請求進來之前進到 middleware ，然後 middleware 就會產生 nonce 的值，然後會再把他設定到某個地方。
• https://nextjs.org/docs/app/building-your-application/configuring/content-security-policy

3. 駭客有沒有可能用 nonce 去做注入攻擊？

• nonce 通常都是後端產生，如果是純 SPA ，nonce 有加和沒加會是一樣的，nonce 一定是固定的，因為你是純 SPA ，所以要加 nonce 就需要後端來配合，這就是為啥 Next.js 文件是用後端產的，Next.js 本來就有後端 Sever ，nonce 產生規則是一個隨機uuid，為了不讓你預測出他 nonce 的值是啥，如果 nonce 的值可以被預測，確實駭客在攻擊時他知道 nonce，就代表 nonce 有設和沒設一樣，例如：Nextjs 是用自己的後端服務產出，如果用 React 搭配一個後端 Sever 那也是 Sever 要去做處理。

2-3章節回顧

1. XSS 多層次防護策略中的第三道防線是什麼？為什麼有了前面兩道，還需要第三道呢？

• 第三道防線是降低 XSS 攻擊成功後的影響範圍。
• 雖然第一道防線（使用者輸入處理）和第二道防線（CSP）可以有效防止大多數 XSS 攻擊，但在無法完全杜絕 XSS 的情況下，要設計降低 XSS 發生後的影響，這樣可以防止攻擊者獲取敏感資料或進行敏感操作，增加攻擊難度。

2. 多重驗證如何在 XSS 攻擊後降低攻擊的危害？多重驗證適合用在哪些操作上？

• 在進行一些敏感操作，例如：匯款、改密碼，就是加上多重驗證，確保 XSS 攻擊者無法取得使用者才知道的訊息，降低知道這個漏洞後攻擊的危害。

3. 在目前前端的機制中，唯一能防止 Token 被偷走的做法是什麼？

• 把 Token 存在 HttpOnly Cookie 裡面，唯一能防止 JavaScript 存取 Token 的方式。

4. 日本二手商品交易平台是如何防止 Token 被偷走呢？

• 使用 Web Worker 方式去隔離 Token，攻擊者無法直接從主線程存取到 Web Workers 中的 Token，因此能防止 Token 被 XSS 攻擊盜取。

5. 如何限制 Token 的權限？有什麼作法？

• 可以使用 Backend For Frontend (BFF) 的架構，前端所有請求都要經過 BFF ，就可以限制前端可以呼叫的 API 有哪些，降低和後端資料庫互動的範圍，也能限制攻擊者的範圍。

問題：

1. Web Worker 客戶端不知道會不會存到前面那兩個 function 或是有沒有機會拿到裡面的資料？

• Web Worker 是去阻止你偷 Token 的防禦方式，所以目的就是防止你把 Token 直接偷走，但是不能阻止你發 API，他程式內容可從外部 message 進來，只要填參數就可以打 API ，打 API 一樣是帶自己的 Token 出去的 ，所以攻擊者一樣可以透過 Web Worker 去發送請求，但是他不能知道你請求裡的 Token 是啥，因為我主要只是防止你偷 Token。
• 無法防止攻擊者發送請求，只能拿不到 Token，看你是否覺得拿不到 Token 值得做這麼多事情。有沒有拿到 Token 的差別，如果攻擊者偷不到 Token，使用者瀏覽器關掉後攻擊就停止，如果有 Token 當使用者關閉瀏覽器，攻擊者可藉由 Token 去做操作。
• Next.js 其實就是一種 BFF，尤其是現在有 server component 以後更為明顯。
• https://auth0.com/blog/the-backend-for-frontend-pattern-bff/