1、取消控件的參數綁定。

2、對所有輸入框進行完全的過濾，既包括能拼接成html和js的特殊字符，也包括所有的js函數。

總結——Xss注入的防范

• 完善的過濾體系。使用攔截器把能拼接成html或js的特殊字符、函數全都過濾掉。
• Html encode。假設某些情況下，我們不能對用戶數據進行嚴格的過濾，那末就需要對輸入的html標簽之類的特殊字符進行轉義。
• 將重要的cookie標記為http only或secure,  這樣的話Javascript中的document.cookie語句就不能獲得到cookie了，或只有用https才能使用cookie
• 開啟閱讀器中的XSS過濾器。具體方法，大家可以自行百度。
• 完善的測試。手工腳本注入測試+自動化xss漏洞掃描工具掃描。

CSRF

總結——CSRF的防范措施

• 完善過濾和攔截機制。
• 正確使用GET,POST和Cookie。
• 查詢操作用get，增加、刪除和修改等操作用post。
• 在非GET要求中使用securityToken。服務端收到用戶要求后，把客戶端傳過來的securityToken和通過session計算出來的進行比對就能夠判斷是不是是合法要求了。

我們有個用戶登錄的頁面，代碼中驗證用戶登錄的sql 以下：select COUNT(*) from Users where Password = 'a' and UserName = 'b' 

這段代碼返回Password和UserName都匹配的用戶數量。

注入方法以下：

如果將UserName設置為 “b' or 1=1 –”.那末，上述sql就變成了： select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'

不難看出，SQL的語意產生了改變。為何產生改變呢？由于沒有重用之前的履行計劃，對注入后的SQL語句重新進行了編譯，重新履行了語法解析。

其實，要保證SQL語義不變，即我寫的SQL就是我想表達的意思，不因sql注入而改變語義，就應當重用履行計劃。從這個角度說，任何動態的履行SQL 都有注入的風險，由于動態意味著不重用履行計劃，而如果不重用履行計劃的話，那末就基本上沒法保證你寫的SQL所表示的意思就是你要表達的意思，SQL的語意如果變化了，所表達的查詢就會變化。

重用履行計劃，這就好像小學時做的填空題：查找密碼是(____) 并且用戶名是(____)的用戶。不管你填的是甚么值，我所表達的就是這個意思。只要語義不變，就沒有風險。

最后再總結1句：由于參數化查詢可以重用履行計劃，并且如果重用履行計劃的話，SQL所要表達的語義就不會變化，所以就能夠避免SQL注入,如果不能重用履行計劃，就有可能出現SQL注入。存儲進程之所以安全，也是1樣的道理！

~這是最近1個月發現的系統中的web安全問題，做個記錄，加深點印象，以時時提示自己革命還沒有成功，測試還需警省！