|frameset|ilayer|layer|bgsound|title|base>
OnX事件代码、Javascript、Vbscript和Style中的expression、behaviour、script、position等.
但过滤可能存在不完全的情况.建立自己的XSS攻击库,方便测试和收集新的攻击方式,使过滤函数更加完善.
优点：
支持HTML,有效防止大部分攻击代码.
缺点：
可能存在过滤不全的情况.
5.2SQL注入
5.2.1定义
什么是SQL注入
所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令.通过递交参数构造巧妙的SQL语句,从而成功获取想要的数据.
简单来说,注入往往是应用程序缺少对输入进行安全性检查所引起的,攻击者把一些包含指令的数据发送给解释器,解释器会把收到的数据转换成指令执行,注入漏洞十分普遍,通常能在SQL查询、程序参数等中出现.
下图为SQL攻击原理图：
5.2.2危害
注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务.注入漏洞有时甚至能导致完全接管主机,主要危害有以下几点：
Ø绕过防火墙进行攻击
Ø绕过web应用程序的验证过程
Ø非法越权操作数据库内容
Ø随意篡改网页内容
Ø添加系统账户或数据库账户
Ø上传和下载非法文件
Ø本地溢出并获取系统最高权限
Ø安装木马后门/僵尸网络
5.2.3解决方法
SQL注入实例：
StringsqlString="SELECT*FROMusersWHEREfullname=〞’+form.getFullName<>+’〞ANDpassword=〞’’’’‘+form.getPassword<>+’"〞;
正常：
username=tony,password=123456
SELECT*FROMusersWHEREusername=tony’ANDpassword=’123456’
攻击：
username=tony,password=’OR‘1’=’1
SELECT*FROMusersWHEREusername=tony’ANDpassword=‘’OR‘1’=’1’
参数化查询预处理
对于JDBC而言,SQL注入攻击只对Statement有效,对PreparedStatement是无效的,这是因为PrepareStatement不允许在不同的插入时间改变查询的逻辑结构.
如验证用户是否存在的SQL语句为：
selectcount<*>fromusertablewherename=’用户名’andpswd=’密码’
如果在用户名字段中输入’or‘1=1’or‘1’=’1
或是在密码字段中输入1’or‘1’=’1
将绕过验证,但这种手段只对Statement有效,对PreparedStatement无效,PreparedStatement相对Statement有以下优点：
Ø防注入攻击
Ø多次运行速度快
Ø防止数据库缓冲区溢出
Ø代码的可读性可维护性好
5.3恶意脚本执行
5.3.1定义
恶意文件执行是一种能够威胁任何形式的漏洞,只要攻击者在具有引入〔include〕功能程式的参数中修改参数内容,WEB服务器便会引入恶意程序内容从而收到恶意文件执行漏洞攻击.
5.3.2危害
攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权,进行不法利益或获取经济利益.
5.3.3解决方法
Ø验证输入,验证上传文件名
Ø检查上传文件的大小
5.4文件上传漏洞
5.4.1定义
Web应用程序在处理用户上传的文件时,没有判断文件的扩展名是否在允许的X围内,就把文件保存在服务器上,导致恶意用户可以上传任意文件,甚至上传脚本木马到web服务器上,直接控制web服务器.
5.4.2危害
攻击者可利用文件上传功能,上传Webshell从而控制整个主机系统.
5.4.3解决方案
Ø检查上传文件扩展名白,不属于白内,不允许上传.
Ø上传文件的目录必须是请求无法直接访问到的.如果需要访问的,必须上传到其他〔和web服务器不同的〕域名下,并设置该目录为不解析jsp等脚本语言的目录.
Ø上传文件要保存的文件名和目录名由系统根据时间生成,不允许用户自定义.
Ø图片上传,要通过处理〔缩略图、水印等〕,无异常后才能保存到服务器.
Ø上传文件需要做日志记录,请参照"ErrorHandingandLogging章节〞.
5.5传输敏感信息未使用安全通道
5.5.1定义
对于未加密的敏感数据在网络上传输时,需要使用安全的通道.否则应用程序将暴露身份验证或会话令牌.
5.5.2危害
Ø攻击者能够取得或者篡改##的或是私有的信息；
Ø攻击者通过这些私密信息的窃取从而进行进一步的攻击；
Ø造成企业形象破损,用户满意度下降,甚至会有法律诉讼等.
5.5.3解决方案
Ø提供合理的保护机制；
Ø对于敏感数据的传输,对所有连接都要使用TLS；
Ø在传输前对单个数据都要进行加密；〔如XML-Encryption〕
Ø在传输前对信息进行签名；〔如XML-Signature〕
Ø正确的使用这些机制；
Ø使用标准的强加密算法；
Ø合理管理密钥和证书；
Ø在使用前验证SSL证书；
5.6信息泄漏和错误处理不当
5.6.1定义
应用程序没有统一的异常处理页面,导致敏感信息泄漏,常常产生错误信息并显示给使用者.很多时候,这些错误信息是非常有利于攻击者发起攻击,因为他们揭示实施细节或者对利用漏洞有用的开发信息.
示例：
看到此信息,攻击者可以做以下判断：
a）数据库是oracle
b）查询语句的列数不正确
根据这个判断,攻击者调整get请求的内容,最终达到获取数据库所有数据的目的.
5.6.2危害
Ø泄漏太多细节〔如错误堆栈跟踪信息、SQL语句等等〕；
Ø登录失败后,通知用户是否用户ID或密码出错-登录失败可能是由于ID或密码错误造成的.这为一个对关键资产发动暴力破解的攻击者提供重要信息.
5.6.3解决方案
Ø通过web.xml配置文件实现,产生异常或者错误时跳转到统一的错误处理页面,避免泄漏过多敏感信息.
⏹
⏹
⏹/error.jsp
⏹
Ø针对登录尝试的攻击,如果输入用户名或者是口令错误,可以使用相同的报错信息,比如都提示"输入用户名或密码错误！
〞.
5.7跨站请求伪造
5.7.1定义
Cross-SiteRequestForgery〔CSRF〕,跨站请求伪造攻击.
攻击者在用户浏览网页时,利用页面元素〔例如img的src〕,强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求.
5.7.2危害
由于发生CSRF攻击后,攻击者是强迫用户向服务器发送请求,所以会造成用户信息被迫修改,更严重者引发蠕虫攻击.
CSRF攻击可以从站外和站内发起.从站内发起CSRF攻击,需要利用本身的业务,比如"自定义头像〞功能,恶意用户指定自己的头像URL是一个修改用户信息的,当其他已登录用户浏览恶意用户头像时,会自动向这个发送修改信息请求.
从站外发送请求,则需要恶意用户在自己的服务器上,放一个自动提交修改个人信息的html页面,并把页面地址发给受害者用户,受害者用户打开时,会发起一个请求.
如果恶意用户能够知道管理后台某项功能的URL,就可以直接攻击管理员,强迫管理员执行恶意用户定义的操作.
5.7.3代码示例
一个没有CSRF安全防御的代码如下：
代码中接收用户提交的参数"email,tel,realname〞,之后修改了该用户的数据,一旦接收到一个用户发来的请求,就执行修改操作.
提交表单代码：
当用户点提交时,就会触发修改操作.
5.7.4解决方案
要防御CSRF攻击,必须遵循一下三步：
1、在用户登陆时,设置一个CSRF的随机TOKEN,同时种植在用户的cookie中,当用户浏览器关闭、或用户再次登录、或退出时,清除token.
2、在表单中,生成一个隐藏域,它的值就是COOKIE中随机TOKEN.
3、表单被提交后,就可以在接收用户请求的web应用中,判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致,如果不一致或没有这个值,就判断为CSRF攻击,同时记录攻击日志〔日志内容见"ErrorHandingandLogging〞章节〕.
由于攻击者无法预测每一个用户登录时生成的那个随机TOKEN值,所以无法伪造这个参数.
示例：
代码中$csrfToken.hiddenField将会生成一个隐藏域,用于生成验证token,它将会作为表单的其中一个参数一起提交.
5.8访问控制缺陷
5.8.1权限提升
5.8.1.1定义
访问控制过程中身份验证有缺陷,导致用户越权访问信息.
5.8.1.2危害
由于web应用程序没有做权限控制,或仅仅在菜单上做了权限控制,导致的恶意用户只要猜测其他管理页面的URL,就可以访问或控制其他角色拥有的数据或页面,达到权限提升目的.这个威胁可能导致普通用户变成管理员权限.
5.8.1.3代码示例
一个仅仅做了菜单控制的代码：
恶意用户,可以直接猜测"管理所有用户〞的页面,通过URL访问,看到管理员页面.
5.8.1.4解决方案
在打开管理页面URL时,首先判断当前用户是否拥有该页面的权限,如果没有权限,就判定为"权限提升〞攻击,同时记录安全日志.
建议使用成熟的权限框架处理权限问题,比如springsecurity.
5.8.2不安全的直接对象引用
5.8.2.1定义
所谓"不安全的直接对象引用〞,指的是一个已经授权的用户,通过更改访问时的一个参数,从而访问到原本并没有得到授权的对象.Web应用往往在生成Web页面时会用它的真实名字,且并不会对所有的对象访问时来检查用户权限,所以这就造成不安全的对象直接引用漏洞.
我们看如下的一个示例,也许这样就更容易理解什么是不安全的对象直接引用.
Ø攻击者发现他自己的参数是6065,即?
acct=6065;
Ø他可以直接更改参数为6066,即?
acct=6066;
Ø这样他就可以直接看到6066用户的账户信息.
5.8.2.2危害
这种漏洞损害参数所引用的所有数据.除非名字空间很稀疏,否则攻击者很容易访问该类型的所有数据.或者恶意用户可以删除或修改其他人数据.
5.8.2.3代码示例
以下代码存在这个漏洞,web应用在修改用户个人信息时,从从用户提交的request参数〔用户可控数据〕中,获取了userid,执行修改操作.
修改用户个人信息页面：
表单中,将用户的userid作为隐藏字段,提交给处理修改个人信息的应用.
下面代码是修改个人信息的应用：
这段代码是从request的参数列表中,获取userid,也就是表单提交上来的userid,之后修改userid对应的用户数据.
而表单中的userid是可以让用户随意修改的.
5.8.2.4解决方案
从用户的加密认证cookie中,获取当前用户的id,并且需要在执行的SQL语句中,加入当前用户id作为条件语句.由于是web应用控制的加密算法,所以恶意用户无法修改加密信息.
示例代码：
代码中通过GetUseridFromCookie,从加密的COOKIE中获取了当前用户的id,并加入到SQL语句中的WHERE条件中.
5.9不安全的加密
5.9.1定义
系统中涉与到敏感信息的数据直接明文存储,极不安全,需要加密存储.或者采用程序员自己编写的"简单算法〞加密,一旦被人获取足够的"样本〞,将有可能被反向推测出解密算法,从而泄露重要信息.
一些低强度的密码算法,如DES、RC2等已经可以很容易的在短时间内被人所破解,其它一些容易被误用的"密码算法〞,如base64、escape、urlencode等,其实并不是密码算法,只是简单的编码而已,不能起到密码算法保护信息的作用.
5.9.2弱加密示例
线性加密算法,下面以"古典密码算法〞为例：
该算法对字符串做"Offset〞位偏移,极易被破解,不宜采用.
5.9.3解决方案
详见§6.3.
5.10限制URL访问失效
URL中或者其他参数包含文件、目录、数据库记录或者关键字等参照物,导致接口处信息泄露.
5.10.1定义
这个漏洞事实上也是与认证相关的,与我们前面提到的不安全的直接对象引用也是类似的,不同在于这个漏洞是说系统已经对URL的访问做限制,但这种限制却实际并没有生效.常见的错误是,我们在用户认证后只显示给用户认证过的页面和菜单选项,而实际上这些仅仅是表示层的访问控制而不能真正生效,攻击者能够很容易的就伪造请求直接访问未被授权的页面.
我们举个例子来说明这个过程：
Ø攻击者发现他自己的访问地址为/user/getAccounts;
Ø他修改他的目录为/admin/getAccounts或/manager/getAccounts;
Ø这样攻击者就能够查看到更多的账户信息.
5.10.2解决方案
对每个URL,我们必须做三件事：
Ø如果这个URL不是公开的,那么必须限制能够访问他的授权用户
●加强基于用户或者角色的访问控制；
●完全禁止访问未被授权的页面类型〔如配置文件、日志文件、源文件等〕
Ø验证架构
●在每一个层次都使用简单肯定的模型；
●确保每一层都有一个访问机制.
Ø验证实现
●不要使用自动化分析工具；
●确保每个URL都被外部过滤器或其他机制保护；
●确保服务器的配置不允许对非授权页面的访问.
5.11Session管理
5.11.1Cookieonlyflag
5.11.1.1定义
Cookieonly,是设置COOKIE时,可以设置的一个属性,如果COOKIE没有设置这个属性,该COOKIE值可以被页面脚本读取.当攻击者发现一个XSS漏洞时,通常会写一段页面脚本,窃取用户的COOKIE,为了增加攻击者的门槛,防止出现因为XSS漏洞导致大面积用户COOKIE被到,应该在设置认证COOKIE时,增加这个属性.
5.11.1.2代码示例
这段代码没有设置only属性：
response.setHeader<"SET-COOKIE","user="+request.getParameter<"cookie">>;
5.11.1.3解决方案
设置cookie时,加入属性即可：
response.setHeader<"SET-COOKIE","user="+request.getParameter<"cookie">+";Only">;
下图可以看到cookie已经加入了only属性：
5.11.1.4常见问题
Ø如何在COOKIE类中设置only？
⏹目前的jdk版本只支持在setHeader时,设置only.
Øonly已经可以防止用户COOKIE被窃取,还需要做XSS防御吗？
⏹这个flag只能增加攻击者的难度,不能达到完全防御xss攻击.
5.11.2CookieSecureflag
5.11.2.1定义
CookieSecure,是设置COOKIE时,可以设置的一个属性,设置了这个属性后,只有在s访问时,浏览器才会发送该COOKIE.
浏览器默认只要使用请求一个站点,就会发送明文COOKIE,如果网络中有监控,可能被截获.
如果Web应用全站是s的,可以设置COOKIE加上Secure属性,这样浏览器就只会在s访问时,发送cookie.
攻击者即使窃听网络,也无法获取用户明文cookie.
5.11.2.2代码示例
这段代码没有设置Secure属性
response.setHeader<"SET-COOKIE","user="+request.getParameter<"cookie">+";Only">;
进行网络监听,可以看到下图是没有设置Secure属性的COOKIE发送的数据包：
5.11.2.3解决方案
在设置认证COOKIE时,加
升级会员 