|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应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到web服务器上，直接控制web服务器。
5.4.2危害
攻击者可利用文件上传功能，上传Webshell从而控制整个主机系统。
5.4.3解决方案
Ø检查上传文件扩展名白名单，不属于白名单内，不允许上传。
Ø上传文件的目录必须是http请求无法直接访问到的。
如果需要访问的，必须上传到其他（和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配置文件实现，产生异常或者错误时跳转到统一的错误处理页面，避免泄漏过多敏感信息。
n
n
n/error.jsp
n
Ø针对登录尝试的攻击，如果输入用户名或者是口令错误，可以使用相同的报错信息，比如都提示“输入用户名或密码错误！
”。
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不是公开的，那么必须限制能够访问他的授权用户
l加强基于用户或者角色的访问控制；
l完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）
Ø验证架构
l在每一个层次都使用简单肯定的模型；
l确保每一层都有一个访问机制。
Ø验证实现
l不要使用自动化分析工具；
l确保每个URL都被外部过滤器或其他机制保护；
l确保服务器的配置不允许对非授权页面的访问。
5.11Session管理
5.11.1Cookiehttponlyflag
5.11.1.1定义
Cookiehttponly，是设置COOKIE时，可以设置的一个属性，如果COOKIE没有设置这个属性，该COOKIE值可以被页面脚本读取。
当攻击者发现一个XSS漏洞时，通常会写一段页面脚本，窃取用户的COOKIE，为了增加攻击者的门槛，防止出现因为XSS漏洞导致大面积用户COOKIE被到，应该在设置认证COOKIE时，增加这个属性。
5.11.1.2代码示例
这段代码没有设置httponly属性：
response.setHeader（"SET-COOKIE","user="+request.getParameter（"cookie"））;
5.11.1.3解决方案
设置cookie时，加入属性即可：
response.setHeader（"SET-COOKIE","user="+request.getParameter（"cookie"）+";HttpOnly"）;
下图可以看到cookie已经加入了httponly属性：
5.11.1.4常见问题
Ø如何在COOKIE类中设置httponly？
n目前的jdk版本只支持在setHeader时，设置httponly。
ØHttponly已经可以防止用户COOKIE被窃取，还需要做XSS防御吗？
n这个flag只能增加攻击者的难度，不能达到完全防御xss攻击。
5.11.2Cookie
升级会员 