輸入和輸出
目前應用程式最常見的安全性弱點是無法正確地傳遞從外部來源 (特別是「使用者輸入」) 接收的資料。 您應該每次都要仔細查看任何輸入，使用前先確定其已經過驗證。 若未分析使用者輸入是否為潛在攻擊，可能會導致資料遺失或曝光、權限提高，或甚至在其他使用者的電腦上執行惡意程式碼。
此情況中的悲劇是此情節容易解決的問題。 在此單元中，我們將討論如何處理資料；收到資料時、資料顯示於畫面時，以及儲存資料供後續使用時。
為何需要驗證我們的輸入？
假設您要組建讓使用者可在您網站上建立帳戶的介面。 我們的設定檔資料包括我們將對每個造訪網站使用者顯示的名稱、電子郵件和暱稱。 如果有新的使用者建立設定檔，並輸入含有某些 SQL 命令的暱稱，將會如何？ 例如，如果惡意使用者輸入如下內容時怎麼辦：
Eve'); DROP TABLE Users;--
如果我們盲目地將此值插入資料庫中，其可能會改變 SQL 陳述式，執行我們絕對不想要執行的命令！ 此範例稱為「SQL 插入式」攻擊，是您未正確處理使用者輸入時可能遭受的眾多惡意探索類型之一。 那麼，我們可以做什麼來修正此情況？ 此單元將教導您驗證輸入的時機、如何輸出編碼，以及如何建立參數化查詢 (以解決上述惡意探索)。 這些技術是防止惡意輸入進入您應用程式的三個主要防禦技巧。
何時需要驗證輸入？
答案是一律都要。 您必須驗證應用程式的每個輸入。 這包括 URL 中的參數、使用者的輸入、資料庫中的資料、API 的資料，以及以純文字形式傳遞而讓使用者有可能操縱的任何內容。 一律使用「允許清單」方法，這表示您只接受「已知良好」輸入，而不要使用「封鎖清單」(特別尋找不當輸入)，因為不可能列出一份完整的潛在危險輸入清單。 請在伺服器上執行此工作，不要在用戶端執行 (或同時在伺服器和用戶端執行)，以確保無法規避您的防禦。 將所有資料視為不受信任的資料，您就能抵禦大部分常見的 Web 應用程式弱點。
如果您使用 ASP.NET，其架構會提供用戶端和伺服器端絕佳的驗證輸入支援。
如果您使用其他 Web 架構，OWASP 輸入驗證速查表上有提供一些可執行輸入驗證的優質技術。
一律使用參數化查詢
SQL 資料庫通常用來儲存資料；例如，您的應用程式可以將使用者設定檔資訊儲存在資料庫中。 請勿使用原始使用者輸入在您的程式碼中建立內嵌 SQL 或其他資料庫查詢，並直接將其傳送到資料庫；此行為會造成災害，如前述所示。
例如，請勿建立像下列內嵌 SQL 範例的程式碼：
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
在此，我們會將文字字串串連在一起來建立查詢，取用使用者的輸入並產生動態 SQL 查詢，以查閱使用者。 同樣地，如果惡意使用者發現我們這麼做，或只是嘗試不同的輸入樣式來查看是否有弱點，我們最終可能會蒙受重大災害。 請改為使用參數化 SQL 陳述式或預存程序，例如：
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
透過這個方法，您就能安全地從程式碼叫用程序，並為其傳遞 userName 字串，不需擔心其被視為 SQL 陳述式的一部分。
一律將您的輸出編碼
您應該一律編碼並逸出以視覺化方式或在文件中呈現的任何輸出。 這樣即使在清理階段中遺漏了某個項目，或程式碼意外產生可能遭到惡意使用的項目，您仍可受到保護。 此設計準則可確保所有項目都顯示為輸出，且非無異解譯為不應該執行的項目，這是稱為「跨網站指令碼」(XSS) 的另一個常見攻擊技術。
因為 XSS 防護是一般應用程式需求，此安全性技術是 ASP.NET 將會為您處理的另一個區域。 所有輸出都預設為已編碼。 如果您使用其他 Web 架構，則可以使用 OWASP XSS 防護速查表，確認可用於網站上的輸出編碼選項。
摘要
若要確保您的輸入有效並可安全地使用及儲存，清理和驗證輸入是必要的需求。 現今大部分的 Web 架構都提供內建功能，可將一部分此工作自動化。 您可以查看您慣用架構的文件，並查看它可提供哪些功能。 雖然 Web 應用程式是最常發生這種情況的位置，但是請記得其他類型的應用程式也很容易遭受攻擊。 請不要因為您的新應用程式是桌面應用程式。就認為您很安全。 您仍需適當處理使用者輸入，以確保他人無法使用您的應用程式損毀您的資料，或破壞您所屬公司的信譽。