OWASP(开放Web软体安全项目- Open Web Application Security Project)是一个开放社群、非营利性组织,目前全球有130个分会近万名会员,其主要目标是研议协助解决Web软体安全之标准、工具与技术文件,长 期 致力于协助*或企业了解并改善网页应用程式与网页服务的安全性。
下表左边是2010年的排名,下表右边是2013年的排名,可以看出改变的地方有:
- 2010 年的Insecure Cryptographic Storage(不安全加密存储)和Insufficient Transport Layer Protection(传输层保护不足),在2013年合并为了一个:Sensitive Data Exposure(敏感数据暴露)
- 2010年的Failure to Restrict URL Access(不限制URL访问),在2013年成为了Missing Function Level Access Control(功能级别访问控制缺失)
- 2010年中Security Misconfiguration(安全配置错误)的一部分,在2013年单独拉出来,成为了Using Known Vulnerable Components(使用已知易受攻击组件)
OWASP Top 10 – 2010 (Previous) |
OWASP Top 10 – 2013 (New) |
A1 – Injection |
A1 – Injection |
A3 – Broken Authentication and Session Management |
A2 – Broken Authentication and Session Management |
A2 – Cross-Site Scripting (XSS) |
A3 – Cross-Site Scripting (XSS) |
A4 – Insecure Direct Object References |
A4 – Insecure Direct Object References |
A6 – Security Misconfiguration |
A5 – Security Misconfiguration |
A7 – Insecure Cryptographic Storage – Merged with A9 à |
A6 – Sensitive Data Exposure |
A8 – Failure to Restrict URL Access – Broadened into à |
A7 – Missing Function Level Access Control |
A5 – Cross-Site Request Forgery (CSRF) |
A8 – Cross-Site Request Forgery (CSRF) |
<buried in A6: Security Misconfiguration> |
A9 – Using Known Vulnerable Components |
A10 – Unvalidated Redirects and Forwards |
A10 – Unvalidated Redirects and Forwards |
A9 – Insufficient Transport Layer Protection |
Merged with 2010-A7 into new 2013-A6 |
A1 – Injection(注入)
原因:代码中的逻辑裸依赖于外部的输入。
分支:SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入
名称 |
现象 |
解决方法 |
SQL注入 |
程序把用户输入的一段字符串直接用在了拼凑sql语句上,导致了用户可以控制sql语句,比如加入delete的行为、绕过用户密码验证等 |
使用参数形式调用sql 使用存储过程(存储过程中不要使用动态sql拼语句) 使用Linq, EF等框架来写(不要使用里面的直接拼sql语句的方式) |
OS命令注入 |
因为是由程序拼凑命令行(包括参数)来实现调用外部程序的,因此用户也能够通过小计量来突破限制,实现调用其他外部程序 |
业务逻辑层要验证是否合法输入 通过System.Diagnostics.Process来实现调用外部程序 |
XPATH注入 |
//Employee[UserName/text()=’aaron’ and password/text()=’password’] à //Employee[UserName/text()=’aaron’ or 1=1 or ‘a’ =’a’ and password/text()=’password’] 这个和典型的sql注入一样,呵呵 |
解决方法和sql类似,也是对查询进行参数化,如下: Declare variable $userName as xs: string external; Declare variable $password as xs: string external; // Employee[UserName/text()=$userName and password/text()=$password] |
LDAP注入 |
LDAP查询和sql查询类似,也是可以通过拼字符串得来的,因此页存在注入漏洞 |
|
JSON注入 |
{‘user’: ‘usera’, ‘sex’, ‘boy’} à {‘user’: ‘usera’, ‘sex’, ‘bo’y’} 这样会导致js报错 |
传统webform下,使用JSON.NET来实现json数据的生成 Mvc下,使用JSONResult来生成json数据 |
URL注入 |
http://www.a.com/a.aspx?p1=a&p1=b 如果还有个cookie,name为:p1, value: c 则,最终asp.net获取这个参数的value为:a,b,c |
这个认识的还不够深入,而且和服务器端语言有关,只要asp.net会把几个参数value合并起来,其他语言都只取到一个,但是取到的是第一个还是最后一个,就看语言了。 这个和业务逻辑有很大的关系 |
A2 – Broken Authentication and Session Management (失效的身份认证和会话管理)
原因:Session相关的数据没有被完整替换导致的安全问题
解 决关注点:Login通过后,立刻把当前Session(包含Session, Cache, Cookie)失效掉,把需要保存进Session的value重开一个Session保存进;Logout功能中,除了把当前Session失效掉外, 还要把Session相关的Cache也remove掉
登录 |
在login验证事件中,一旦合法身份验证通过后,就要把Session.Abort(),来重新获得新的Session(此时客户端的session cookie value也会被reset成新的) |
|
注销 |
Session要Abort 相关的缓存要clear 额外的cookie也要被clear |
A3 – Cross-Site Scripting (XSS) (跨站脚本)
原因:和Injection类似,只不过xss的关注点落在了html, javascript注入上,由于内容比较多,因此单独拉出来,成为了XSS
分支:反射式XSS、存储式XSS、基于DOM的XSS
解决关注点:html的输入输出编码、javascript的编码、url的编码
名称 |
现象 |
解决方法 |
反射式XSS |
由于服务器端直接调用了客户端用户输入的数据(没有经过无害化处理),导致了对广大客户端用户的损害 比如获取客户端用户在某网站的所有cookie,这样恶意用户就能实现session劫持等更进一步的攻击 |
对用户输入的数据要过滤特殊字符 对输出到客户端的数据也要过滤特殊字符 Html, js, url三大领域过滤方法不同,需要区别对待 Server.HtmlEncode; Server.HtmlDecode; Server.UrlEncode; Server.UrlDecode; Server.UrlPathEncode; Js函数如下 |
存储式XSS |
存储式XSS比反射式XSS更加深远,范围更广;因为这种未经处理的代码是保存到数据库中的,因此时间、范围都比较广 |
|
基于DOM的XSS |
AJAX程序中,JS代码没有过滤/转换用户输入的文本,导致了对DOM元素的结构性影响,或者导致了行为性的影响 |
Js中使用escape函数来过滤特殊字符,包括元素value、元素Attribute,都要encode起来 escape,encodeURI,encodeURIComponent的使用参考goody9807的这篇文章: http://www.cnblogs.com/goody9807/archive/2009/01/16/1376913.html |
Anti-XSS |
脚本过滤库,具体使用方法参考木子的这篇文章: http://www.cnblogs.com/moozi/archive/2010/03/04/1677904.html |
|
Anti-XSS SRE |
SRE: Security Runtime Engine的缩写 是一个更智能的过滤系统,具体使用参考Syed的这篇文章: http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-security-runtime-engine.aspx |
|
ASP.NET MVC 4 |
<%=Html%>à不会进行转换 <%: Html%>à会进行转换 [AllowHtml]tag 尽量不改动默认的ValidateRequest属性 |
A4 – Insecure Direct Object References (不安全的直接对象引用)
原 因:http://www.a.com/userdetail.aspx?userId=1,容易认为的进行猜测userId=2等等,如果没有判断权 限,就容易出现信息泄露的问题;但是如果url是http://www.a.com/userdetail.aspx?userId=ABAWEFRA则 很难进行猜测
解决关注点:url参数的编码和解码
工具类 |
IndirectReference //根据数据库中的entity id生成UI客户端用于显示的字符串id,这个字符串id类似于散列值,不容易猜测,但是能被还原 String GenerateUIID(string/int/guid) //根据UI客户端ID还原成原始的entity id,具体类型由T决定 String FromUIID<T>(string) |
Webform开发模式下 |
Aspx页面中 <a href=”product.aspx?productId=<%= IndirectReference.GenerateUIID(this.productID) %>”>产品A</a> Page_Load中 this.productId= IndirectReference.FromUIID<int>(Request.QueryString[“productId”]); |
MVC开发模式下 |
为Entity增加IndirectReferenceID,然后ModelBinder就能自动绑定了 |
A5 – Security Misconfiguration (安全配置错误)
原则:最少使用模块配置、最小权限配置;适用范围:OS,IIS,数据库
解 决关注点:Web.config中的Error节点配置,比如404、403错误的重定向和日志记录、日志文件不能放在网站路径下;web.config 文件的加密(aspnet_regiis),具体命令如下:使用命令行,如(run as admin): C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -site "VulnerableApp" -app "/" -pe "connectionStrings"
A6 – Sensitive Data Exposure (敏感数据暴露)
原因:敏感信息需要加密保存(内存、数据库中、客户端)+加密传输(HTTPS)+不缓存(这个只是尽量,具体看情况)
解决关注点:登录、付款这样的页面要用https保护传输
加密方法 |
密码用单向加密,如MD5 |
传输层保护 |
貌似就https了,其他的不怎么了解 |
客户端cookie的保护 |
设置cookie的属性 HttpOnly Secure |
数据库的数据保护 |
除了程序中进行加密敏感数据外,数据库级别也要使用数据库加密 |
A7 – Missing Function Level Access Control (功能级别访问控制缺失)
原因:UI中显示了当前用户不能进行的操作,比如禁用了某个delete按钮(能被修改成disable: 0即可使用);权限验证是否覆盖到了某功能、UI;服务器端是否进行了权限验证(业务层级别)
解决关注点:权限验证
Sample: 读取文件时,比如下载时,如:download.aspx?file=a.txt,如果被修改成了download.aspx?file=http://www.cnblogs.com/config.xml 就麻烦了。
对UI的处理 |
导航栏中,如果没有权限访问的,就隐藏掉,不要弄disable之类的东西 具体页面中的按钮也是这样的处理方式,隐藏不要禁用(就是用户不能操作的,就不要让用户看到,省的麻烦) 在最终页面中要加入权限判断代码,这样即便直接输入了某特权url,由于还会在page中检查权限,因此还是安全的 |
|
对主要业务函数的处理 |
|
A8 – Cross-Site Request Forgery (CSRF) (跨站请求伪造)
原因:利用合法用户的身份,在合法用户的终端调用请求。这些请求可能是转账…
解决关注点:重要操作不要使用get方式,如:delete.aspx?id=1;要使用post方式;为每个能进行post动作的form增加token,并且在服务器端检查token是否合法,合法则进行操作;
Webform传统开发模式 |
给每个请求的页面加入token的解决方法:使用Anti-CSRF组件可解决,使用方法见:http://anticsrf.codeplex.com 自定义ViewState 默认的ViewState是没有加密的,很容易被看到具体的value,如通过这个工具就能看到:ViewStateDecoder,urlà http://download.csdn.net/detail/skt90u/3974340 可以通过给ViewState自定义来缓解那么一点点,但是没办法提升到像加入token那样的力度,代码很简单: this.ViewStateUserKey=Convert.ToString(Session[“UserID”]) 如上代码即可实现对ViewState的加密,会根据this.ViewStateUserKey的value对每个ViewState进行Salt类似的加密 |
MVC开发模式 |
[HttpPost] [ValidateAntiForgeryToken] public ActionResult Login(Usr usr) { return View(); } 在aspx模版或者Razor 模版中的form中增加如下代码: <%=Html.AntiForgeryToken() %> 具体的方式参考这篇文章:http://www.cnblogs.com/leleroyn/archive/2010/12/30/1921544.html |
A9 – Using Known Vulnerable Components (使用已知易受攻击组件)
原因:由于系统有意无意间使用了组件(自己的组件和第三方的组件,范围太广…),导致了不可预料的问题
解决关注点:对于自己的组件,要加强质量,这个已经和代码没有很多关系了,更多的是质量管理、版本管理方面的了,略;对于第三方的组件,要选择知名的提供商。
A10 – Unvalidated Redirects and Forwards(未验证的重定向和转发)
原
因:当系统接受重定向参数(login界面居多,如:http://www.a.com
/login.aspx?returnUrl=default.aspx),由于这个url会显示在浏览器地址栏中,只要修改这个url为http:
//www.a.com/login.aspx?returnUrl=http://wwv.a.com/login.aspx,用户输入密码后被重定向
到假冒站点的login界面(用户以为输入的密码错误了),用户再次输入密码,此时密码就被假冒站点保存起来了…
解决关注点:对于returnUrl这种参数值进行判断,只要在白名单中的url才能redirect,尽量使用相对路径来redirect
工具类 |
RedirectForwardDispatcher Void Config(List<string> whitelist) bool IsRedirectable(string newUrl) |
使用方法 |
String returnUrl=…; If(!RedirectForwardDispatcher.IsRedirectable(returnUrl)) { Throw exception(“Unvalidated Redirects and Forwards”); } |