1. 程式人生 > >SQL 盲注、SQL 注入、跨站點指令碼編制可能解決方案

SQL 盲注、SQL 注入、跨站點指令碼編制可能解決方案

跨站       3.點指令碼編制

詳細資訊

有多種減輕威脅的技巧:

[1] 策略:庫或框架

使用不允許此弱點出現的經過稽核的庫或框架,或提供更容易避免此弱點的構造。

可用於更輕鬆生成正確編碼的輸出的庫和框架示例包括 Microsoft 的 Anti-XSS 庫、OWASP ESAPI 編碼模組和 Apache Wicket。

[2] 瞭解將在其中使用資料的上下文,以及預期的編碼。在不同元件之間傳輸資料時,或在生成可同時包含多個編碼的輸出(如 Web 頁面或多部分郵件訊息)時,這尤為重要。研究所有預期的通訊協議和資料表示法以確定所需的編碼策略。對於將輸出到另一個 Web 頁面的任何資料(尤其是從外部輸入接收到的任何資料),請對所有非字母數字字元使用恰當的編碼。

相同輸出文件的某些部分可能需要不同的編碼,具體取決於輸出是在以下哪一項中:

[-] HTML 主體

[-] 元素屬性(如 src="XYZ")

[-] URI

[-] JavaScript 段

[-] 級聯樣式表和樣式屬性

請注意,“HTML 實體編碼”僅適用於 HTML 主體。

請諮詢 XSS Prevention Cheat Sheet

以獲取有關所需編碼和轉義型別的更多詳細資訊。

[3] 策略:識別和減少攻擊出現的機會

瞭解您的軟體中可能出現不可信輸入的所有潛在區域:引數或自變數、cookie、從網路讀取的任何內容、環境變數、反向 DNS 查詢、查詢結果、請求頭、URL 組成部分、電子郵件、檔案、檔名、資料庫以及嚮應用程式提供資料的任何外部系統。請記住,此類輸入可通過 API 呼叫間接獲取。

[4] 策略:輸出編碼

對於生成的每個 Web 頁面,請使用並指定 ISO-8859-1 或 UTF-8 之類的字元編碼。如果未指定編碼,Web 瀏覽器可能通過猜測 Web 頁面實際使用的編碼來選擇不同的編碼。這可能導致 Web 瀏覽器將特定序列視為特殊序列,從而使客戶機暴露在不易察覺的 XSS 攻擊之下。請參閱 CWE-116 以獲取與編碼/轉義相關的更多減輕威脅的方法。

[5] 策略:識別和減少攻擊出現的機會

要幫助減輕針對使用者會話 cookie 的 XSS 攻擊帶來的威脅,請將會話 cookie 設定為 HttpOnly。在支援 HttpOnly 功能的瀏覽器(如 Internet Explorer 和 Firefox 的較新版本)中,此屬性可防止使用 document.cookie 的惡意客戶機端指令碼訪問使用者的會話 cookie。這不是完整的解決方案,因為 HttpOnly 並不受所有瀏覽器支援。更重要的是,XMLHTTPRequest 和其他功能強大的瀏覽器技術提供了對 HTTP 頭的讀訪問權,包括在其中設定 HttpOnly 標誌的 Set-Cookie 頭。

[6] 策略:輸入驗證假定所有輸入都是惡意的。使用“接受已知善意”輸入驗證策略:嚴格遵守規範的可接受輸入的白名單。拒絕任何沒有嚴格遵守規範的輸入,或者將其轉換為遵守規範的內容。不要完全依賴於將惡意或格式錯誤的輸入加入黑名單。但是,黑名單可幫助檢測潛在攻擊,或者確定哪些輸入格式不正確,以致應當將其徹底拒絕。

執行輸入驗證時,請考慮所有潛在相關屬性,包括長度、輸入型別、可接受值的完整範圍、缺失或多餘輸入、語法、跨相關欄位的一致性以及業務規則一致性。以業務規則邏輯為例,“boat”可能在語法上有效,因為它僅包含字母數字字元,但如果預期為顏色(如“red”或“blue”),那麼它無效。

動態構造 Web 頁面時,請使用嚴格的白名單以根據請求中引數的預期值來限制字符集。所有輸入都應進行驗證和清理,不僅限於使用者應指定的引數,而是涉及請求中的所有資料,包括隱藏欄位、cookie、頭、URL 本身,等等。導致 XSS 脆弱性持續存在的一個常見錯誤是僅驗證預期會由站點重新顯示的欄位。常見的情況是,在請求中出現由應用程式伺服器或應用程式反射的其他資料,而開發團隊卻未能預料到此情況。另外,將來的開發者可能會使用當前未反映的欄位。因此,建議驗證 HTTP 請求的所有部分。請注意,適當的輸出編碼、轉義和引用是防止 XSS 的最有效解決方案,雖然輸入驗證可能會提供一定的深度防禦。輸入驗證會有效限制將在輸出中出現的內容。它並不總是能夠防止 XSS,尤其是在您需要支援可包含任意字元的自由格式文字欄位的情況下。例如,在聊天應用程式中,心型表情圖示(“<3”)可能會通過驗證步驟,因為它的使用頻率很高。但是,不能將其直接插入到 Web 頁面中,因為它包含“<”字元,該字元需要轉義或以其他方式進行處理。在此情況下,消除“<”可能會降低 XSS 的風險,但是這會產生不正確的行為,因為這樣就不會記錄表情圖示。

這可能看起來只是略有不便,但在需要表示不等式的數學論壇中,這種情況就更為重要。即使在驗證中出錯(例如,在 100 個輸入欄位中忘記一個欄位),相應的編碼仍有可能針對基於注入的攻擊為您提供防護。只要輸入驗證不是孤立完成的,便仍是有用的技巧,因為它可以大大減少攻擊出現的機會,使您能夠檢測某些攻擊,並提供正確編碼所無法解決的其他安全性優勢。請確保在應用程式內定義良好的介面中執行輸入驗證。即使某個元件進行了複用或移動到其他位置,這也將有助於保護應用程式。