指令碼攻擊概觀
更新：2007 年 11 月
從伺服器的觀點而言，網頁只是一長串的字元字串。瀏覽器連續處理字串，顯示某些字元，並根據特殊規則解譯如 <b> 和 <script> 的其他字元。如果惡意使用者可以插入某些這類的特殊字元到網頁中，瀏覽器將無法知道這些字元原本並不存在，而會將它們視為網頁的一部分處理。
簡化的指令碼擅用，其可能的運作方式如下。如果應用程式允許使用者張貼最新影片的評論供其他使用者閱讀，則擅用步驟可能是：
應用程式顯示使用者可以輸入註解的表單。惡意使用者撰寫的評論中包含了 <script> 區塊。
在發佈表單後，惡意使用者的註解儲存在資料庫中。
另一個使用者造訪網站。當建構網頁時，它會從資料庫讀取註解，並將其放在網頁上。惡意使用者的 <script> 區塊會寫入網頁，就好像是文字評論一樣。
當第二個使用者的瀏覽器顯示網頁時，它會到 <script> 區塊上，將其執行。
惡意使用者還可以使用其他方法進行指令碼擅用攻擊。大多數指令碼擅用要求應用程式接受惡意輸入，並將其插入 (或 echo) 到網頁中，瀏覽器就會在網頁中執行指令碼。這類擅用攻擊的潛在損害程度取決於指令碼所執行的內容。可能微不足道，像是在瀏覽器中出現的惱人訊息。但藉由像是偷竊 Cookie、偷取使用者輸入 (如密碼)，以及如果網際網路安全性非常鬆散時，在使用者的電腦上執行機器碼等手段，也可能造成嚴重損害。
如需防止指令碼擅用的詳細資訊，請參閱 HOW TO：利用將 HTML 編碼套用至字串的方法，防止會在 Web 應用程式中發生的指令碼攻擊。
.gif "注意事項") 注意事項： |
|---|
ASP.NET 會檢查可能的危險字串 (如 "<!"、"</" 和 "<?")，並提供保護以免受偽裝為 URL 的指令碼擅用攻擊。 |
擅用 SQL 陳述式
指令碼擅用的變化型式，即是造成惡意 SQL 陳述式執行。當應用程式提示使用者輸入資訊，再將使用者輸入串連到表示 SQL 陳述式的字串中，就可能發生這種情況。例如，應用程式可能會以執行以下陳述式的方式，提示輸入客戶名稱：
"Select * From Customers where CustomerName = " & txtCustomerName.Value
但是惡意使用者如果熟悉資料庫，會使用文字方塊輸入含有客戶名稱的內嵌 SQL 陳述式，產生陳述式如下所示：
Select * From Customers Where CustomerName = 'a' Delete From Customers Where CustomerName > ''
當執行查詢時，就會危害資料庫的安全。
防範擅用指令碼
對於防範擅用指令碼的主要措施，就是絕對不要信任來自使用者的資訊。假定任何從瀏覽器發佈至您應用程式的資料，都可能含有惡意指令碼。
同樣地，每當您撰寫字串到網頁時，應該假設字串可能含有惡意指令碼 (除非您自己以程式的方式建立字串)。例如，當您從資料庫讀取字串時，應該假定其中可能含有惡意指令碼。最具安全性意識的開發人員，並不信任自己的資料庫，這是基於惡意使用者可能已經發現竄改資料庫方法的一種想法。
ASP.NET 提供您協助防範擅用指令碼的幾個方法：
ASP.NET 針對查詢字串和表單變數以及 cookie 值執行要求驗證。根據預設，如果目前的 Request 含有 HTML 編碼項目或某些 HTML 字元 (例如，— 代表長破折號)，ASP.NET 網頁架構會引發錯誤。
如果要在應用程式中顯示字串，但並不信任這些字串，則可在將字串寫回到回應時，對其套用 HTML 編碼。例如，使用編碼方式，標記 <b> 會變成 <b>。使用的時機為當您顯示來自資料庫的字串，但無法確定是否可以信任其內容時。
如果您想要應用程式接受一些 HTML (例如，使用者的某些格式化指示)，則應當在用戶端對 HTML 進行編碼，再將其送出到伺服器。如需詳細資訊，請參閱 HOW TO：利用將 HTML 編碼套用至字串的方法，防止會在 Web 應用程式中發生的指令碼攻擊。
若要協助防範擅用 SQL 陳述式，請勿使用字串串連建立 SQL 查詢。而是使用參數型查詢，並指派使用者輸入至參數物件。如需詳細資訊，請參閱資料配接器命令中的參數。
一定要使用一組預期的值和字串格式化/型別驗證來驗證表單輸入。例如，如果特定表單變數必須是整數，請使用 Int32.TryParse 方法驗證該值確實是整數，並使用範圍檢查確保該值在可接受的範圍內。
請參閱
工作
HOW TO：利用將 HTML 編碼套用至字串的方法，防止會在 Web 應用程式中發生的指令碼攻擊