OWASP (Open Web Software Security Project - Open Web Application Security Project) is an open community, non-profit organization with nearly 10,000 members in 130 chapters around the world. Its main goal is to discuss and assist in solving Web software security standards, Tools and technical documents, long-term commitment to help governments or enterprises understand and improve the security of web applications and web services.
The left side of the table below is the ranking in 2010, and the right side of the table below is the ranking in 2013. It can be seen that the changes are:
- Insecure Cryptographic Storage and Insufficient Transport Layer Protection in 2010, merged into one in 2013: Sensitive Data Exposure
- Failure to Restrict URL Access in 2010 (unrestricted URL access) became Missing Function Level Access Control in 2013
- Part of Security Misconfiguration in mid-2010, pulled separately in 2013 and became Using Known Vulnerable Components (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
Reason: The logic in the code depends on external input.
Branches: SQL Injection, OS Command Injection, XPATH Injection, LDAP Injection, JSON Injection, URL Injection
| name |
Phenomenon |
Solution |
| SQL injection |
The program directly uses a string entered by the user to piece together the sql statement, so that the user can control the sql statement, such as adding delete, bypassing user password verification, etc. |
call sql with parameters Use stored procedures (do not use dynamic sql spelling statements in stored procedures) Use Linq, EF and other frameworks to write (do not use the direct spelling sql statement in it) |
| OS command injection |
Because the program assembles the command line (including parameters) to call the external program, the user can also break through the limit and call other external programs through small measurement. |
The business logic layer needs to verify whether the input is valid Calling external programs through System.Diagnostics.Process |
| XPATH injection |
//Employee[UserName/text()=’aaron’ and password/text()=’password’] at //Employee[UserName/text()=’aaron’ or 1=1 or ‘a’ =’a’ and password/text()=’password’] This is the same as typical sql injection, hehe |
The solution is similar to sql, but also parameterizes the query, as follows: Declare variable $userName as xs: string external; Declare variable $password as xs: string external; // Employee[UserName/text()=$userName and password/text()=$password] |
| LDAP injection |
LDAP query is similar to sql query, it can also be obtained by spelling strings, so there is an injection vulnerability in the page |
|
| JSON injection |
{‘user’: ‘usera’, ‘sex’, ‘boy’} at {‘user’: ‘usera’, ‘sex’, ‘bo’y’} This will cause js to report an error |
Under traditional webform, use JSON.NET to generate json data Under Mvc, use JSONResult to generate json data |
| URL injection |
http://www.a.com/a.aspx?p1=a&p1=b If there is still a cookie, the name is: p1, value: c Then, the final asp.net obtains the value of this parameter as: a, b, c |
This understanding is not deep enough, and it is related to the server-side language. As long as asp.net will combine several parameter values, other languages will only get one, but whether it is the first or the last one, it depends on the language. . This has a lot to do with business logic |
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”); } |
原文地址：http://blog.csdn.net/dyllove98/article/details/8759910