EP54 - 安全性

Security 這四篇最佳實踐原來都是這麼大的議題www
我還以為是最佳範例之類那種
觀念的東西還是多吸收吧～不懂就先看過 www

回報漏洞 - Reporting Vulnerabilities​

當有漏洞被回報時，這會立即成為我們的首要關注事項，一位全職貢獻者會立即放下其他工作來處理此問題。如需回報漏洞，請發送電子郵件至 security@vuejs.org。

儘管發現新漏洞的情況很罕見，我們還是建議您始終使用最新版本的 Vue 及其官方伴隨函式庫，以確保您的應用程式保持盡可能安全。

規則一：絕對不要使用不可信任的模板 - Rule No.1: Never Use Non-trusted Templates

使用 Vue 時最基本的安全規則是絕對不要使用不可信任的內容作為元件模板。這相當於允許在您的應用程式中任意執行 JavaScript，更糟的是，如果在伺服器端渲染期間執行這段程式碼，可能會導致伺服器被入侵。以下是這種用法的例子：

Vue.createApp({
  template: `<div>` + userProvidedString + `</div>` // 絕對不要這麼做
}).mount('#app')

Vue 模板會被編譯成 JavaScript，且模板內的表達式會在渲染過程中執行。儘管這些表達式會在特定的渲染上下文中進行評估，但由於潛在的全域執行環境的複雜性，對於像 Vue 這樣的框架來說，想要完全防範潛在的惡意程式碼執行而不帶來不切實際的性能負擔是不現實的。避免這類問題的最簡單方法是確保您的 Vue 模板內容始終是可信任的且完全由您控制。

Vue 為了保護您所做的措施 - What Vue Does to Protect You​

HTML 內容

無論是使用模板還是 render 函數，內容都會自動進行轉義。這意味著在以下模板中：

<h1>{{ userProvidedString }}</h1>

如果 userProvidedString 包含：

'<script>alert("hi")</script>'

它將會被轉義為以下 HTML：

<script>alert("hi")</script>

從而防止腳本注入。這種轉義是使用原生的瀏覽器 API（如 textContent）來完成的，因此只有在瀏覽器本身存在漏洞時才可能存在漏洞。

屬性綁定 - Attribute bindings

同樣地，動態屬性綁定也會自動進行轉義。這意味著在以下模板中：

<h1 :title="userProvidedString">
  hello
</h1>

如果 userProvidedString 包含：

'" onclick="alert(\'hi\')'

它將會被轉義為以下 HTML：

" onclick="alert('hi')

從而防止關閉 title 屬性來注入新的任意 HTML。這種轉義是使用原生的瀏覽器 API（如 setAttribute）來完成的，因此只有在瀏覽器本身存在漏洞時才可能存在漏洞。

潛在的危險 - Potential Dangers​

在任何網頁應用中，允許未經過濾的使用者提供的內容以 HTML、CSS 或 JavaScript 的形式執行都是潛在的危險，所以應該儘可能避免這種情況。然而，有時候某些風險可能是可以接受的。

例如，像 CodePen 和 JSFiddle 這樣的服務允許使用者提供的內容執行，但這是在一個預期的環境中，並在 iframe 內部進行一定程度的沙盒處理。當某些重要功能本質上需要某種程度的漏洞時，則由您的團隊來衡量該功能的重要性與漏洞可能引發的最壞情況之間的權衡。

HTML 注入 - HTML Injection

如您先前所學，Vue 自動轉義 HTML 內容，防止您意外地將可執行的 HTML 注入到您的應用中。然而，在您確定 HTML 是安全的情況下，可以明確地渲染 HTML 內容：

使用模板：

<div v-html="userProvidedHtml"></div>

使用 render 函數：

h('div', {
  innerHTML: this.userProvidedHtml
})

使用帶有 JSX 的 render 函數：

<div innerHTML={this.userProvidedHtml}></div>

警告: 使用者提供的 HTML 永遠不能被認為是 100% 安全的，除非是在一個沙盒 iframe 中或在應用程式的一部分中，只有編寫該 HTML 的使用者才能看到。此外，允許使用者編寫自己的 Vue 模板也帶來了類似的危險。

URL 注入 - URL Injection

在這樣的 URL 中：

<a :href="userProvidedUrl">
  click me
</a>

如果 URL 未經過“消毒”以防止使用 javascript:，則存在潛在的安全問題。可以使用像 sanitize-url 這樣的庫來幫助處理這個問題，但請注意：如果您在前端進行 URL 消毒，那麼您已經有了安全問題。使用者提供的 URL 應始終由後端進行消毒，甚至在保存到資料庫之前。這樣，問題就可以避免所有連接到您的 API 的客戶端，包括原生移動應用程序。即使使用消毒過的 URL，Vue 也無法保證它們指向的目的地是安全的。

樣式注入 - Style Injection

看這個例子：

<a
  :href="sanitizedUrl"
  :style="userProvidedStyles"
>
  click me
</a>

假設 sanitizedUrl 已經被消毒，因此它確定是一個真實的 URL 而不是 JavaScript。對於 userProvidedStyles，惡意使用者仍然可以提供 CSS 來進行“點擊劫持”，例如將鏈接樣式設置為一個透明框框在“登錄”按鈕上。那麼，如果 https://user-controlled-website.com/ 被設計得像您的應用程序的登錄頁面，他們可能剛剛捕獲了一個使用者的真實登錄信息。

您可以想像允許使用者提供的內容為 <style> 元素會帶來更大的漏洞，給予該使用者完全控制整個頁面的樣式。因此，Vue 防止在模板中渲染 <style> 標籤，例如：

<style>{{ userProvidedStyles }}</style>

為了讓您的使用者完全安全免受點擊劫持，我們建議僅允許在沙盒 iframe 內完全控制 CSS。或者，在通過樣式綁定提供使用者控制時，我們建議使用其物件語法，並且僅允許使用者提供特定屬性的值，這些屬性對他們來說是安全的，例如：

<a
  :href="sanitizedUrl"
  :style="{
    color: userProvidedColor,
    background: userProvidedBackground
  }"
>
  click me
</a>

JavaScript 注入 - JavaScript Injection

我們強烈不建議使用 Vue 渲染 <script> 元素，因為模板和 render 函數不應該有副作用。然而，這不是唯一一種在運行時包括會被作為 JavaScript 評估的字符串的方法。

每個 HTML 元素都有接受 JavaScript 字符串的屬性，如 onclick、onfocus 和 onmouseenter。將使用者提供的 JavaScript 綁定到任何這些事件屬性都是潛在的安全風險，所以應該避免這樣做。

警告: 使用者提供的 JavaScript 永遠不能被認為是 100% 安全的，除非是在一個沙盒 iframe 中或在應用程式的一部分中，只有編寫該 JavaScript 的使用者才能看到。

有時我們會收到關於如何在 Vue 模板中進行跨站腳本（XSS）攻擊的漏洞報告。一般來說，我們不認為這些情況是真正的漏洞，因為沒有實際的方法來保護開發者免於以下兩種情況：

1. 開發者明確要求 Vue 渲染使用者提供的、未經過濾的內容作為 Vue 模板。這本質上是不安全的，並且 Vue 無法知道其來源。
2. 開發者將 Vue 掛載到包含服務端渲染和使用者提供內容的整個 HTML 頁面。這本質上與第 1 點相同的問題，但有時候開發者可能在不知情的情況下這樣做。這可能會導致漏洞，攻擊者提供的 HTML 作為普通 HTML 是安全的，但作為 Vue 模板是不安全的。最佳做法是永遠不要將 Vue 掛載到可能包含服務端渲染和使用者提供內容的節點上。

最佳實踐 - Best Practices

一般規則是，如果您允許未經過濾的使用者提供的內容被執行（無論是 HTML、JavaScript 還是 CSS），您可能會面臨攻擊的風險。這個建議無論是在使用 Vue、其他框架，甚至不使用框架的情況下都適用。

除了上述關於潛在危險的建議外，我們還建議您熟悉以下資源：

• HTML5 Security Cheat Sheet
• OWASP's Cross Site Scripting (XSS) Prevention Cheat Sheet

然後，根據所學內容，審查您的依賴項的源代碼，以檢查是否存在潛在的危險模式，尤其是那些包含第三方組件或影響 DOM 渲染的部分。

後端協作 - Backend Coordination

像跨站請求偽造（CSRF/XSRF）和跨站腳本包含（XSSI）這樣的 HTTP 安全漏洞主要是在後端解決的，因此它們不是 Vue 的關注點。然而，與後端團隊溝通，了解如何最好地與他們的 API 交互仍然是個好主意，例如在提交表單時提交 CSRF 令牌。

伺服器端渲染 (SSR) - Server-Side Rendering (SSR)

在使用 SSR 時還有一些額外的安全問題，因此請確保遵循我們 SSR 文檔中概述的最佳實踐，以避免漏洞。

還算蠻有趣～原來有一堆injection
原本只以為就是SQL injection而已～
看來每個地方都有可能是漏洞www