Loading

安全开发规范

安全编码的基本准则

 

  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”/>
  1. 如果请求中包含敏感数据,必须要采用POST请求,防止代理服务器日志把敏感数据记录下来。
  1. 前端不得提交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">
posted @ 2018-10-29 11:16  河马先森  阅读(1963)  评论(0编辑  收藏  举报