漏洞分类及判定方法

1、 漏洞分类及判定方法A1 注入原因：代码中的逻辑裸依赖于外部的输入。分支：SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入名称现象解决方法SQL注入程序把用户输入的一段字符串直接用在了拼凑sql语句上，导致了用户可以控制sql语句，比如加入delete的行为、绕过用户密码验证等使用参数形式调用sql使用存储过程（存储过程中不要使用动态sql拼语句）使用Linq, EF等框架来写（不要使用里面的直接拼sql语句的方式）OS命令注入因为是由程序拼凑命令行（包括参数）来实现调用外部程序的，因此用户也能够通过小计量来突破限制，实现调用其他外部程序业务逻辑层要验证是否合法

2、输入通过System.Diagnostics.Process来实现调用外部程序XPATH注入/EmployeeUserName/text()=aaron and password/text()=password/EmployeeUserName/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

3、xs: string external;/ EmployeeUserName/text()=$userName and password/text()=$passwordLDAP注入LDAP查询和sql查询类似，也是可以通过拼字符串得来的，因此页存在注入漏洞JSON注入user: usera, sex, boyuser: usera, sex, boy这样会导致js报错传统webform下，使用JSON.NET来实现json数据的生成Mvc下，使用JSONResult来生成json数据URL注入如果还有个cookie，name为：p1, value: c则，最终获取这个参数的value为：a,

4、b,c这个认识的还不够深入，而且和服务器端语言有关，只要会把几个参数value合并起来，其他语言都只取到一个，但是取到的是第一个还是最后一个，就看语言了。这个和业务逻辑有很大的关系A2 失效的身份认证和会话管理原因：Session相关的数据没有被完整替换导致的安全问题解决关注点：Login通过后，立刻把当前Session（包含Session, Cache, Cookie）失效掉，把需要保存进Session的value重开一个Session保存进；Logout功能中，除了把当前Session失效掉外，还要把Session相关的Cache也remove掉登录在login验证事件中，一旦合法身份验证

5、通过后，就要把Session.Abort()，来重新获得新的Session（此时客户端的session cookie value也会被reset成新的）注销Session要Abort相关的缓存要clear额外的cookie也要被clearA3 跨站脚本（XSS）原因：和Injection类似，只不过xss的关注点落在了html, javascript注入上，由于内容比较多，因此单独拉出来，成为了XSS分支：反射式XSS、存储式XSS、基于DOM的XSS解决关注点：html的输入输出编码、javascript的编码、url的编码名称现象解决方法反射式XSS由于服务器端直接调用了客户端用户输入的数

6、据（没有经过无害化处理），导致了对广大客户端用户的损害比如获取客户端用户在某网站的所有cookie，这样恶意用户就能实现session劫持等更进一步的攻击对用户输入的数据要过滤特殊字符对输出到客户端的数据也要过滤特殊字符Html, js, url三大领域过滤方法不同，需要区别对待Server.HtmlEncode;Server.HtmlDecode;Server.UrlEncode;Server.UrlDecode;Server.UrlPathEncode;Js函数如下存储式XSS存储式XSS比反射式XSS更加深远，范围更广；因为这种未经处理的代码是保存到数据库中的，因此时间、范围都比较广基于

7、DOM的XSSAJAX程序中，JS代码没有过滤/转换用户输入的文本，导致了对DOM元素的结构性影响，或者导致了行为性的影响Js中使用escape函数来过滤特殊字符，包括元素value、元素Attribute，都要encode起来escape,encodeURI,encodeURIComponent的使用参考goody9807的这篇文章：Anti-XSS脚本过滤库，具体使用方法参考木子的这篇文章：Anti-XSS SRESRE: Security Runtime Engine的缩写是一个更智能的过滤系统，具体使用参考Syed的这篇文章：ASP.NET MVC 4不会进行转换会进行转换AllowH

8、tmltag尽量不改动默认的ValidateRequest属性A4 不安全的直接对象引用原因：解决关注点：url参数的编码和解码工具类IndirectReference/根据数据库中的entity id生成UI客户端用于显示的字符串id，这个字符串id类似于散列值，不容易猜测，但是能被还原String GenerateUIID(string/int/guid)/根据UI客户端ID还原成原始的entity id,具体类型由T决定String FromUIID(string)Webform开发模式下Aspx页面中a href=”product.aspx?productId=”产品APage_Loa

9、d中ductId= IndirectReference.FromUIID(Request.QueryString“productId”);MVC开发模式下为Entity增加IndirectReferenceID，然后ModelBinder就能自动绑定了A5 安全配置错误原则：最少使用模块配置、最小权限配置；适用范围：OS,IIS,数据库解决关注点：Web.config中的Error节点配置，比如404、403错误的重定向和日志记录、日志文件不能放在网站路径下；web.config文件的加密（aspnet_regiis），具体命令如下：使用命令行，如(run as admin)：

10、 C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis -site VulnerableApp -app / -pe connectionStringsA6 敏感信息泄露原因：敏感信息需要加密保存(内存、数据库中、客户端)+加密传输(HTTPS)+不缓存(这个只是尽量，具体看情况)解决关注点：登录、付款这样的页面要用https保护传输加密方法密码用单向加密，如MD5信用卡账号等需要加密后再存储到数据库中（可逆的加密方式）传输层保护貌似就https了，其他的不怎么了解客户端cookie的保护设置cookie的属性HttpOnlySecure

11、数据库的数据保护除了程序中进行加密敏感数据外，数据库级别也要使用数据库加密A7 功能级访问控制缺失原因：UI中显示了当前用户不能进行的操作，比如禁用了某个delete按钮（能被修改成disable: 0即可使用）；权限验证是否覆盖到了某功能、UI；服务器端是否进行了权限验证（业务层级别）解决关注点：权限验证Sample: 读取文件时，比如下载时，如：download.aspx?file=a.txt，如果被修改成了download.aspx?file= 就麻烦了。对UI的处理导航栏中，如果没有权限访问的，就隐藏掉，不要弄disable之类的东西具体页面中的按钮也是这样的处理方式，隐藏不要禁用（就

12、是用户不能操作的，就不要让用户看到，省的麻烦）在最终页面中要加入权限判断代码，这样即便直接输入了某特权url，由于还会在page中检查权限，因此还是安全的对主要业务函数的处理1. 要有完善的安全系统2. 给主要业务函数贴上tagPrincipalPermission(SecurityAction.Demand, Role = Admin)public void RemoveUserFromRole(string userName, string role)Roles.RemoveUserFromRole(userName, role);A8 跨站请求伪造（CSRF）原因：利用合法用户的身份，在

13、合法用户的终端调用请求。这些请求可能是转账解决关注点：重要操作不要使用get方式，如：delete.aspx?id=1；要使用post方式；为每个能进行post动作的form增加token，并且在服务器端检查token是否合法，合法则进行操作；Webform传统开发模式给每个请求的页面加入token的解决方法：使用Anti-CSRF组件可解决，使用方法见：自定义ViewState默认的ViewState是没有加密的，很容易被看到具体的value，如通过这个工具就能看到：ViewStateDecoder，url 可以通过给ViewState自定义来缓解那么一点点，但是没办法提升到像加入token

14、那样的力度，代码很简单：this.ViewStateUserKey=Convert.ToString(Session“UserID”)如上代码即可实现对ViewState的加密，会根据this.ViewStateUserKey的value对每个ViewState进行Salt类似的加密MVC开发模式HttpPostValidateAntiForgeryTokenpublic ActionResult Login(Usr usr)return View();在aspx模版或者Razor 模版中的form中增加如下代码：具体的方式参考这篇文章：A9 使用含有已知漏洞的组件原因：由于系统有意无意间使用了组件（自己的组件和第三方的组件，范围太广），导致了不可预料的问题解决关注点：对于自己的组件，要加强质量，这个已经和代码没有很多关系了，更多的是质量管理、版本管理方面的了，略；对于第三方的组件，要选择知名的提供商。A10 未验证的重定向和转发原因：当系统接受重定向参数（login界面居多，如：解决关注点：对于returnUrl这种参数值进行判断，只要在白名单中的url才能redirect，尽量使用相对