安全開發規范

安全編碼的基本准則

 

1. 不要相信用戶的任何輸入數據，因為所有數據都是可以偽造的。用戶數據包括HTTP請求中的一切，例如：QueryString, Form, Header, Cookie, File
2. 服務端在處理請求前，必須先驗證數據是否合法，以及用戶是否具有相關的操作權限。注意：客戶端的界面權限控制 不能 保證系統安全性，那只是為了 增強用戶體驗 而已。
3. 禁止拼接，SQL注入，XSS攻擊的產生都與拼接有關，它們都是由於缺乏轉義處理造成的。
4. 客戶端對任何人都是透明的，因此盡量不要將敏感數據發送到客戶端，必要時一定要加密處理。
5. 敏感數據應該加密（或者Hash）保存，日志及調試手段中不能出現敏感數據。
6. 涉及數據修改的操作，必須采用POST方式提交，防止利用漏洞進行惡意調用。
7. 動態的反射調用應該僅針對公開方法或者有確定標記的方法。
8. 操作文件或者目錄，不能直接依據HTTP數據來決定路徑，應該有明確的目標（范圍）或者采用白名單方式。

 

SQL注入

 

原則：不允許拼接【SQL字符串】，只能使用參數化SQL語句。

注意：存儲過程中也不允許拼接【SQL字符串】，存儲過程中可以拼接參數化SQL，需要使用sp_executesql來執行參數化SQL。

 

XSS攻擊

 

原則：輸出到HTML中的文本部分，必須做編碼處理（HTML, URL, JS），可使用HttpUtility的相關方法： HtmlEncode，HtmlAttributeEncode，UrlEncode，JavaScriptStringEncode

注意：如果是在SQL中拼接HTML，需要在SQLSERVER中創建一個HtmlEncode自定義函數，並在拼接時調用。

如果是在JavaScript中拼接HTML，需要在前端創建一個HtmlEncode自定義函數，並在拼接時調用。

總之：任何地方都不能將用戶輸入的文本內容直接輸出到HTML中。

 

示例代碼：

 

1、服務端（ASP.NET 2.0 WebForm）

<pre class="description"><%= comment.Description.HtmlEncode() %></pre>

2、服務端（ASP.NET 4.0 WebForm )

<pre class="description"><%: comment.Description %></pre>

3、客戶端HtmlEncode實現：

String.prototype.HtmlEncode = function(){

var div = document.createElement("div");

div.appendChild(document.createTextNode(this));

return div.innerHTML;

};

 

Cookie安全

 

原則：不能將敏感數據【直接】保存到Cookie中。

注意：如果確實需要將敏感數據臨時保存到Cookie中，必須做加密處理。

在解密讀取Cookie時，如果解密失敗（出現異常），不能對外拋出異常！

 

保護Cookie的方法

 

1、加密Cookie，建議使用 FormsAuthentication.Encrypt()

private HttpCookie CreateSecurityCookie(string cookieName, string text)

{

FormsAuthenticationTicket ticket = newFormsAuthenticationTicket(

2, "fish", DateTime.Now, DateTime.Now.AddDays(30d), false, text);

string str = FormsAuthentication.Encrypt(ticket);

HttpCookie cookie = newHttpCookie(cookieName, str);

cookie.HttpOnly = true; // 不允許 JavaScrit 代碼訪問，主要也是為了防止XSS攻擊。

return cookie;

}

2、在web.config 中統一配置 HttpOnly

<httpCookies httpOnlyCookies="true" />

 

加密算法

 

原則：

1. 密碼之類的敏感數據一定不能明文保存，只能保存Hash值，並在計算Hash時加入salt處理。
2. 不得自己編寫加密算法，因為不專業，安全性無法保證，但允許對標准加密算法進行封裝。
3. Hash算法推薦選擇SHA256
4. 對稱加密算法推薦選擇AES
5. 解密失敗時，不得對外拋出異常，否則會被【Padding Oracle Attack】攻擊。
6. 不建議使用非對稱加密方法 。

HTTP請求

原則：

1. 涉及更新業務數據的請求，必須要采用POST請求，防止被XSS攻擊后產生惡意調用。

　　　　例如：<img src=“/service/User/Add.aspx?name=xxx&pwd=123&type=1”/>

2. 如果請求中包含敏感數據，必須要采用POST請求，防止代理服務器日志把敏感數據記錄下來。

3. 前端不得提交HTML代碼片段，防止被利用產生XSS攻擊。

敏感數據處理

 

原則：

1. 包含敏感信息的頁面，一定不能設置啟用HTTP緩存。需要調用Response.Cache.xxxxxxx()
2. 服務端敏感不得保存到Application和Session中，因為Trace信息中會顯示出來。
3. 日志或者調試信息不得記錄敏感信息，比如攜程信用卡資料泄露事故。

 

ASP.NET 的自身安全機制

 

原則：不要修改以下的配置項。

 

<httpRuntime

maxRequestLength="4096"

enableHeaderChecking="true"

/>

 

說明：

• maxRequestLength：是為了防止拒絕服務攻擊，不能隨意修改它。
• enableHeaderChecking：檢查HTTP標頭是否存在注入式攻擊。

 

正在發版的ASP.NET配置

 

原則：正式發布的配置不允許開啟調試功能。

 

<trace enabled="false"/>

<compilation debug="false">