Cross-Site Scripting: AI

傳送未經驗證的資料至網路瀏覽器，會導致瀏覽器執行惡意的程式碼。

Cross-site scripting (XSS) 弱點會在以下情況中出現：

1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中，不可信賴的來源通常為網頁要求，而在 Persisted XSS (也可稱為 Stored XSS) 案例中，來源通常為資料庫或其他後端資料儲存區。


2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。

傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現，但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡，但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容，或者利用易受攻擊的網站，在使用者的機器上執行其他惡意操作。

範例 1：以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼 eid，並將其向使用者顯示。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

如果 eid 只包含標準英數字元，則這個範例中的程式碼會正確地執行。如果 eid 中有包含中繼字元或來源程式碼中的值，那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。

一開始，這似乎不會輕易受到攻擊。畢竟，誰會在自己的電腦中輸入會執行惡意程式碼的 URL？其實，真正的危險在於攻擊者會建立惡意的 URL，接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時，他們即不知不覺地透過易受攻擊的 Web 應用程式，將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。

範例 2：以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工，並列印相應的員工姓名。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

如 Example 1 所述，name 的值正常運作時，此程式碼也會正常運作，但如果該值不正常運作，則會完全無法避免程式碼遭受攻擊。此外，這個程式碼之所以看似不那麼危險，是因為 name 的值是從資料庫中讀取的，而顯然這些內容是由應用程式管理的。但是，如果 name 的值是從使用者提供的資料中產生，那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證，那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS)，其性質特別狡詐，因為間接的資料儲存方式而難以辨別該威脅，且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript，所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響，因為使用者為何會攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 3：以下程式碼會在 Android 的 WebView 中啟用 JavaScript (預設狀況下停用 JavaScript)，並根據從 Android 用意接收的值載入頁面。

...
	WebView webview = (WebView) findViewById(R.id.webview);
  	webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

若 url 的值以 javascript: 開頭，隨後的 JavaScript 程式碼將在網頁範圍中的 WebView 內執行。

如同範例中所示，XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者：

- 如 Example 1 所述，會直接從 HTTP 要求中讀取資料，並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式，接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行，這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是，將惡意內容當作參數隱藏在公開發表的 URL 中，或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心，攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後，就會執行這些內容，並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者，或者執行其他惡意活動。

- 如 Example 2 所述，應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式，並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現：攻擊者把危險內容插入到之後會讀取的資料儲存區中，並包含在動態內容中。從攻擊者的角度來看，插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限，或者會與敏感資料進行互動，且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容，攻擊者可能會代替使用者去執行需要權限許可的作業，或者取得存取使用者專屬敏感資料的權限。

- 如 Example 3 所述，應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料，且之後這些危險資料會被當作信賴的資料回讀到應用程式，並會包含在動態內容中。

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。