最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
当前位置: 首页 - 正文

漏洞分类及判定方法

来源:动视网 责编:小OO 时间:2025-09-27 08:08:20
文档

漏洞分类及判定方法

漏洞分类及判定方法A1–注入原因:代码中的逻辑裸依赖于外部的输入。分支:SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入名称现象解决方法SQL注入程序把用户输入的一段字符串直接用在了拼凑sql语句上,导致了用户可以控制sql语句,比如加入delete的行为、绕过用户密码验证等使用参数形式调用sql使用存储过程(存储过程中不要使用动态sql拼语句)使用Linq,EF等框架来写(不要使用里面的直接拼sql语句的方式)OS命令注入因为是由程序拼凑命令行(包括参数)来实
推荐度:
导读漏洞分类及判定方法A1–注入原因:代码中的逻辑裸依赖于外部的输入。分支:SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入名称现象解决方法SQL注入程序把用户输入的一段字符串直接用在了拼凑sql语句上,导致了用户可以控制sql语句,比如加入delete的行为、绕过用户密码验证等使用参数形式调用sql使用存储过程(存储过程中不要使用动态sql拼语句)使用Linq,EF等框架来写(不要使用里面的直接拼sql语句的方式)OS命令注入因为是由程序拼凑命令行(包括参数)来实
 漏洞分类及判定方法

A1 –注入

原因:代码中的逻辑裸依赖于外部的输入。

分支: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 –失效的身份认证和会话管理

原因: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 –跨站脚本(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的XSSAJAX程序中,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 SRESRE: 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 –不安全的直接对象引用

原因: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(string)

Webform开发模式下Aspx页面中

”>产品A

Page_Load中

this.productId= IndirectReference.FromUIID(Request.QueryString[“productId”]);

MVC开发模式下为Entity增加IndirectReferenceID,然后ModelBinder就能自动绑定了
 

 

A5 –安全配置错误

原则:最少使用模块配置、最小权限配置;适用范围: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 –敏感信息泄露

原因:敏感信息需要加密保存(内存、数据库中、客户端)+加密传输(HTTPS)+不缓存(这个只是尽量,具体看情况)

解决关注点:登录、付款这样的页面要用https保护传输

加密方法密码用单向加密,如MD5

信用卡账号等需要加密后再存储到数据库中(可逆的加密方式)

传输层保护貌似就https了,其他的不怎么了解
客户端cookie的保护设置cookie的属性

HttpOnly

Secure

数据库的数据保护除了程序中进行加密敏感数据外,数据库级别也要使用数据库加密
 

 

A7 –功能级访问控制缺失

原因:UI中显示了当前用户不能进行的操作,比如禁用了某个delete按钮(能被修改成disable: 0即可使用);权限验证是否覆盖到了某功能、UI;服务器端是否进行了权限验证(业务层级别)

解决关注点:权限验证

Sample: 读取文件时,比如下载时,如:download.aspx?file=a.txt,如果被修改成了download.aspx?file=http://www.cnblogs.com/config.xml 就麻烦了。

对UI的处理导航栏中,如果没有权限访问的,就隐藏掉,不要弄disable之类的东西

具体页面中的按钮也是这样的处理方式,隐藏不要禁用(就是用户不能操作的,就不要让用户看到,省的麻烦)

在最终页面中要加入权限判断代码,这样即便直接输入了某url,由于还会在page中检查权限,因此还是安全的

对主要业务函数的处理1.要有完善的安全系统

2.给主要业务函数贴上tag

[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]

public void RemoveUserFromRole(string userName, string role)

{

Roles.RemoveUserFromRole(userName, role);

}

 
 

 

A8 –跨站请求伪造(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 –使用含有已知漏洞的组件

原因:由于系统有意无意间使用了组件(自己的组件和第三方的组件,范围太广…),导致了不可预料的问题

解决关注点:对于自己的组件,要加强质量,这个已经和代码没有很多关系了,更多的是质量管理、版本管理方面的了,略;对于第三方的组件,要选择知名的提供商。

 

A10 –未验证的重定向和转发

原因:当系统接受重定向参数(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 whitelist)

bool IsRedirectable(string newUrl)

使用方法String returnUrl=…;

If(!RedirectForwardDispatcher.IsRedirectable(returnUrl))

{

Throw exception(“Unvalidated Redirects and Forwards”);

}

文档

漏洞分类及判定方法

漏洞分类及判定方法A1–注入原因:代码中的逻辑裸依赖于外部的输入。分支:SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入名称现象解决方法SQL注入程序把用户输入的一段字符串直接用在了拼凑sql语句上,导致了用户可以控制sql语句,比如加入delete的行为、绕过用户密码验证等使用参数形式调用sql使用存储过程(存储过程中不要使用动态sql拼语句)使用Linq,EF等框架来写(不要使用里面的直接拼sql语句的方式)OS命令注入因为是由程序拼凑命令行(包括参数)来实
推荐度:
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top