WEB开发安全漏洞原因分析及解决

1、WEB开发安全漏洞原因分析及解决文档控制文档控制修改记录修改记录日期日期修改类型修改类型作者作者版本版本备注备注目目 录录1会话标识未会话标识未更更新新.51.1原因.51.2解决.52SQL注入注入.62.1原因.62.2解决.73XSS跨站脚本编制跨站脚本编制 .83.1原因.83.2解决.84XSRF跨站请求伪造跨站请求伪造.104.1原因.104.2解决.104.2.1使用的Struts框架开发的web应用.114.2.2Jsp+javabean开发的web应用 .135登录错误消息凭证枚举（不充分帐户封锁）登录错误消息凭证枚举（不充分帐户封锁）.155.1原因.155.2解决.156

2、HTML注释敏感信息泄露注释敏感信息泄露 .156.1原因.156.2解决.157应用程序错误应用程序错误.157.1原因.157.2解决.158已解密的登录请求已解密的登录请求.158.1原因.158.2解决.168.2.1prototype版 .168.2.2JQuery版.169启用了不安全的启用了不安全的HTTP方法方法.179.1原因.179.2解决.1710禁止页面缓存禁止页面缓存.1810.1原因.1810.2解决.1811数据库错误模式数据库错误模式.1811.1原因.1811.2解决.1912SQL注入文件写入（需要用户验证）注入文件写入（需要用户验证）.1912.1原因.1

3、912.2解决.2013不充分的帐号封锁不充分的帐号封锁.2013.1原因.2013.2解决.2014链接注入（便于跨站请求伪造）链接注入（便于跨站请求伪造）.2114.1原因.2114.2解决.2115通过框架钓鱼通过框架钓鱼.2216CAUCHO RESIN RESIN-ADMIN跨站点脚本编制跨站点脚本编制.2216.1原因.2216.2解决.2217HTTP 响应分割响应分割.2217.1原因.2217.2解决.2318APACHE TOMCAT WEB表单哈希冲突拒绝服务漏洞表单哈希冲突拒绝服务漏洞 .2418.1原因.2418.2解决.2419会话会话COOKIE中缺少中缺少HTT

4、PONLY属性属性.2419.1原因.2419.2解决.2420基于基于 DOM 的跨站点脚本编制的跨站点脚本编制.2520.1原因.2520.2解决.2621主机允许从任何域进行主机允许从任何域进行 FLASH 访问访问 .2721.1原因.2721.2解决.271 会话标识未更新会话标识未更新1.1原因在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说还是以前的那个session（事实上session也确实不会改变，因为没有建立新session，原来的session也没有被销毁）。很多人只是让会话invalida

5、te没有用（request.getSession().invalidate();），是因为invalidate方法不是真正的将session销毁，只是将session中的内容清空，所以当invalidate以后再新建session，新建的session其实不是新的，是将之前的session重新启用了。于是session的id不变就不奇怪了。只有cookie失效掉，才能换成新的session idCookie cookies = request.getCookies();for (int i = 0; i cookies.length; i+) if (cookiesi.getName().to

6、UpperCase().equals(JSESSIONID)cookiesi.setMaxAge(0);1.2解决在登录页面上加上一段代码：request.getSession().invalidate() ; /清空 sessionif (request.getCookies()!=null) Cookie cookies = request.getCookies();for (int i = 0; i cookies.length; i+) if (cookiesi.getName().toUpperCase().equals(JSESSIONID)cookiesi.setMaxAge(0

7、); / 让JSESSIONID 的 cookie 过期注：会话失效后，请不要在代码前面使用 SESSION 保存数据。2 SQL注入注入2.1原因1. 没有正确过滤转义字符 在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞：statement := SELECT * FROM users WHERE name = + userName + ; 将用户名变量(即username)设置为：a or t=t，此时原始语句发生了变化.2. 用户输入错误的数据类型

8、如果一个用户提供的字段并非一个强类型，或者没有实施类型强制，就会发生这种形式的攻击。当在一个SQL语句中使用一个数字字段时，如果程序员没有检查用户输入的合法性(是否为数字型)就会发生这种攻击。例如：statement := SELECT * FROM data WHERE id = + a_variable + ; 从这个语句可以看出，作者希望a_variable是一个与“id”字段有关的数字。不过，如果终端用户选择一个字符串，就绕过了对转义字符的需要。例如，将a_variable设置为:1; DROP TABLE users，它会将“users”表从数据库中删除，SQL语句变成：SELECT

9、 * FROM DATA WHERE id = 1; DROP TABLE users;3. 数据库服务器中的漏洞有时，数据库服务器软件中也存在着漏洞，如MYSQL服务器中mysql_real_escape_string()函数漏洞。这种漏洞允许一个攻击者根据错误的统一字符编码执行一次成功的SQL注入式攻击。4. 盲目SQL注入式攻击当一个Web应用程序易于遭受攻击而其结果对攻击者却不见时，就会发生所谓的盲目SQL注入式攻击。有漏洞的网页可能并不会显示数据，而是根据注入到合法语句中的逻辑语句的结果显示不同的内容。这种攻击相当耗时，因为必须为每一个获得的字节而精心构造一个新的语句。但是一旦漏洞的

10、位置和目标信息的位置被确立以后，一种称为Absinthe的工具就可以使这种攻击自动化。5. 条件响应注意，有一种SQL注入迫使数据库在一个普通的应用程序屏幕上计算一个逻辑语句的值：SELECT booktitle FROM booklist WHERE bookId = OOk14cd AND 1=1这会导致一个标准的面面，而语句SELECT booktitle FROM booklist WHERE bookId = OOk14cd AND 1=2在页面易于受到SQL注入式攻击时，它有可能给出一个不同的结果。如此这般的一次注入将会证明盲目的SQL注入是可能的，它会使攻击者根据另外一个表中的某

11、字段内容设计可以评判真伪的语句。6. 条件性差错如果WHERE语句为真，这种类型的盲目SQL注入会迫使数据库评判一个引起错误的语句，从而导致一个SQL错误。例如：SELECT 1/0 FROM users WHERE username=Ralph。显然，如果用户Ralph存在的话，被零除将导致错误。7.时间延误时间延误是一种盲目的SQL注入，根据所注入的逻辑，它可以导致SQL引擎执行一个长队列或者是一个时间延误语句。攻击者可以衡量页面加载的时间，从而决定所注入的语句是否为真。2.2解决1. 用预编译处理语言要防御SQL注入，用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反，用户的输入必须

12、进行过滤，或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中，SQL语句就得以修正。然后，用户输入就被限于一个参数。下面是一个使用Java和JDBC API例子：PreparedStatement prep = conn.prepareStatement(SELECT * FROM USERS WHERE PASSWORD=?);prep.setString(1, pwd);总体上讲，有两种方法可以保证应用程序不易受到SQL注入的攻击，一是使用代码复查，二是强迫使用参数化语句的。强迫使用参数化的语句意味着嵌入用户输入的SQL语句在运行时将被拒绝。2. 轨范出错

13、处理防范SQL注入，还要避免出现一些详细的错误消息，因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。3. 使用专业的漏洞扫描工具但防御SQL注入攻击也是不够的。攻击者们目前正在自动搜索攻击目标并实施攻击。其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具，如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。3 XSS跨站脚本编制跨站脚本编制3.1原因它指的是恶意攻击者往Web页

14、面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。3.2解决在防止这类问题时，输入内容的转义效果远比内容过滤要好。具体实施可以增加一个request的转码过滤器。代码：import java.io.IOException;import .URLDecoder;import java.util.Iterator;import java.util.Map;import javax.servlet.Filter;import javax.servlet.Filte

15、rChain;import javax.servlet.FilterConfig;import javax.servlet.ServletException;import javax.servlet.ServletRequest;import javax.servlet.ServletResponse;import javax.servlet.http.HttpServletRequest;import mons.lang.StringEscapeUtils;/* * Servlet Filter implementation class SqlEscapeFilter */public cl

16、ass SqlEscapeFilter implements Filter /* * Default constructor. */ public SqlEscapeFilter() /* * see Filter#destroy() */ public void destroy() /* * see Filter#doFilter(ServletRequest, ServletResponse, FilterChain) */ public void doFilter(ServletRequest request, ServletResponse response, FilterChain

17、chain) throws IOException, ServletException HttpServletRequest hreq = (HttpServletRequest)request; Map map = hreq.getParameterMap(); Iterator itr = map.keySet().iterator(); while( itr.hasNext() ) String key = itr.next().toString(); String values = hreq.getParameterValues(key); if( values != null ) f

18、or( int i = 0; i 1) hreq.setAttribute(key, values); else hreq.setAttribute(key, values0); chain.doFilter(request, response); /* * see Filter#init(FilterConfig) */ public void init(FilterConfig fConfig) throws ServletException private String cleanXSS(String value) throws IOException String coverValue

19、=URLDecoder.decode(value,utf-8); coverValue = coverValue.replaceAll(, >); coverValue = coverValue.replaceAll(, & #40;).replaceAll(), ));coverValue = coverValue.replaceAll(, ');coverValue = coverValue.replaceAll(eval(.*), );coverValue = coverValue.replaceAll(s*javascript:(.*), );coverValue

20、 = coverValue.replaceAll(script, );if(!value.equals(coverValue)coverValue=URLDecoder.decode(coverValue,utf-8); return StringEscapeUtils.escapeJavaScript(coverValue); 配置应用中的web.xmlWeb.xml: SqlEscapeFilter SqlEscapeFilter com.hna.hka.so.web.filter.SqlEscapeFilter SqlEscapeFilter *.jsp SqlEscapeFilter

21、*.action4 XSRF跨站请求伪造跨站请求伪造4.1原因CSRF利用方式比较类似XSS(跨站脚本 Cross Site Scripting) ,不过不同的是CSRF是构造一个提交来让其他人访问后,利用站点对这些人的信任来进行一些所期望的操作.比如:A和B在同一个有XSS漏洞的站点C,B登录过D站点,并且有这个D站点的Cookies,这时候如果A构造一个CSRF,内容为给 A在D站点的账户转移一些虚拟币,如果这时候在C站点浏览的B用户打开了A构造的含有CSRF的页面,这时候B的D站点用户会因为对B用户的信任而进行给 A转账的操作.4.2解决此类攻击的情景相对的比较复杂，具体解决可以参考以下

22、5点：第一：限制验证cookie的到期时间。这些cookie的合法时间越短，黑客利用你的Web应用程序的机会就越小。不过，这个时间越短，用户就越不方便。因此，你需要在安全性和方便性之间进行平衡。第二：执行重要业务之前，要求用户提交额外的信息。要求用户在进行重要业务前输入口令，这可以防止黑客发动CSRF攻击(只要浏览器中没有包含口令)，因为这种重要信息无法预测或轻易获得。第三：使用秘密的无法预测的验证符号。当保存在用户浏览器中的cookie仅由一次会话确认时，CSRF攻击才会有效。所以在每次HTTP请求(当然攻击者无法提前知道)中都有附加的特定会话的信息，这样就可以挫败CSRF攻击。不过，如果这

23、种应用程序存在跨站脚本漏洞，黑客就有可能访问这种验证符号。第四：使用定制的HTTP报头。如果执行交易的所有请求都使用XMLHttpRequest并附加一个定制的HTTP报头，同时拒绝缺少定制报头的任何请求，就可以用XMLHttpRequest API来防御CSRF攻击。由于浏览器通常仅准许站点将定制的HTTP报头发送给相同站点，从而了防止由CSRF攻击的源站点所发起的交易。第五：检查访问源的报头。在浏览者发送HTTP请求时，它通常会包含源自访问源报头的URL。理论上讲，你可以使用这些信息来阻止源自其它任何站点(而不是来自Web应用程序自身)的请求。综合公司以往平台报出此类漏洞产出的原因，基本上

24、都可以通过以下简单做法加以解决：在请求后面加上一次性令牌。如验证码，手机短信验证，或者sessionID等。4.2.1使用的Struts框架开发的web应用Struts有个Token机制，主要是用来解决表单重复提交的问题，对于跨站点请求伪造的工具，也可以通过该机制来预防。基本原理是：服务器端在处理到达的请求之前，会将请求中包含的令牌值与保存在当前用户会话中的令牌值进行比较，看是否匹配。在处理完该请求后，且在答复发送给客户端之前，将会产生一个新的令牌，该令牌除传给客户端以外，也会将用户会话中保存的旧的令牌进行替换。这样如果用户回退到刚才的提交页面并再次提交的话，客户端传过来的令牌就和服务器端的令

25、牌不一致，从而有效地防止了重复提交的发生。令牌的生成规则是根据用户会话ID和当前系统时间对于每个会话生成的一个唯一的标识。代码如下：html:link action=subject.do?method=add我要发贴/html:link subject.do 的 add 方法，public ActionForward add(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response)/前面的处理省略saveToken(request);return mappin

26、g.findForward(add);跳转到 subjectAdd.jsp 页面。页面的代码大概如下： html:text property=title / html:textarea property=content / html:submit property=发表 / html:reset property=重填 / html:form html:form action=subjectForm.do?method=insert如果在 add 方法里加了“saveToken(request);”这一句，那在 subjectAdd.jsp 生成的页面上，会多一个隐藏字段，类似于这样input

27、 type=hidden name=org.apache.struts.taglib.html.TOKEN value=6aa35341f25184fd996c4c918255c3ae点击发表后，表单提交到 subjectForm.do 里的 insert 方法后，你在 insert 方法里要将表单的数据插入到数据库中，如果没有进行重复提交的控制，那么每点击一次浏览器的刷新按钮，都会在数据库中插入一条相同的记录，增加下面的代码，你就可以控制用户的重复提交了。 if (isTokenValid(request, true) / 表单不是重复提交 /这里是保存数据的代码 else /表单重复提交或

28、者伪造攻击 saveToken(request); /其它的处理代码 注意，必须在 add 方法里使用了 saveToken(request)，你才能在 insert 里判断，否则，你每次保存操作都是重复提交。 记住一点，Struts 在你每次访问 Action 的时候，都会产生一个令牌，保存在你的 Session 里面，如果你在 Action 里的函数里面，使用了saveToken(request);，那么这个令牌也会保存在这个 Action 所 Forward 到的 jsp 所生成的静态页面里。如果在 Action 的方法里使用了 isTokenValid，那么 Struts 会将你从你的

29、 request 里面去获取这个令牌值，然后和 Session 里的令牌值做比较，如果两者相等，就不是重复提交，如果不相等，就是重复提交了。 4.2.2Jsp+javabean开发的web应用对于纯jsp+javabean开发的遗留系统，改造的原理是同Struts的Token机制实现一样的。通过比对一个以时间为因子的Token串提交前后是否一致来避免跨站请求伪造。具体代码如下：表单提交页面index.jsp： input type=hidden name=current id=current value= / 首先通过javascript生成一个时间戳，放到session中，同时在form里通

30、过隐藏字段把该时间戳也提交。目标页面index2.jsp: This is my JSP page. 通过比对token的有效性，来确保页面数据一定是我们form页提交的。在比对token时，比对完必须删除session中的token。IndexUtil.getSessionToken方法的代码如下：public static String getSessionToken(HttpSession session, String tokenName) / 获取值String value = getString(String) session.getAttribute(tokenName);if

31、(!StringUtils.isBlank(value) / 删除数据session.removeAttribute(tokenName);return value;说明：扫描工具扫描该漏洞的原理是只要扫描到页面代码中有form提交表单的，就会尝试发测试看服务器是否回应了200代码。所以通过查看扫描过程文件发现未对服务器程序造成影响的，可以认为是误报。除非运营商对平台有考核要求，不允许出现此类警告，那就要修改服务器返回值或者加入一次性Token，要考虑修改的工作量（因为可能要对所有form表单都要加入令牌机制）。5 登录错误消息凭证枚举（不充分帐户封锁）登录错误消息凭证枚举（不充分帐户封锁）5

32、.1原因当试图利用不正确的凭证来登录时，当用户输入无效的用户名和无效的密码时，应用程序会分别生成不同的错误消息。通过利用该行为攻击者可以通过反复试验，加暴力破解来发现应用程序的有效用户名、再继续尝试发现相关联的密码。5.2解决不论用户名或密码出现问题都提示同样的错误，且同时加上登陆失败次数达到规定次数，则执行帐户锁定功能。6 HTML注释敏感信息泄露注释敏感信息泄露6.1原因页面源代码不正确的注释方式。6.2解决将html中有关密码之类的敏感注释去掉或者用隐式注释。7 应用程序错误应用程序错误7.1原因未执行验证，可能输入参数数据类型不匹配。7.2解决实行严格的数据类型验证，不要把应用的错误堆

33、栈直接返回给最终用户。8 已解密的登录请求已解密的登录请求8.1原因AppScan 的推理是“AppScan 识别了不是通过SSL 发送的密码参数。8.2解决第一：采用基于SSL的HTTPS传输协议第二：对敏感信息加密并绕过扫描（只要不是采用SSL安全认证即使加密了但是AppScan还是会扫描出来）8.2.1prototype版第一：确保prototype已经被正常加入；第二：删除原页面中的密码框组件（被中划线选中部分），并为其父标签指定ID （添加标签的ID）；第三：为页面添加onload事件；（此处最好借用组件提供的onload事件处理方式）注意修改更新的input组件的名称；docume

34、nt.observe(dom:loaded, function() $(password).update();); 8.2.2JQuery版第一、 第二项操作请参看Prototype版；第三处代码参看以下部分：$(document).ready(function() $().appendTo($(#password););9 启用了不安全的启用了不安全的HTTP方法方法9.1原因除标准的GET与POST方法外，HTTP请求还使用其他各种方法。许多这类方法主要用于完成不常见与特殊的任务。如果低权限用户可以访问这些方法，他们就能够以此向应用程序实施有效攻击。以下是一些值得注意的方法：PUT，向指定

35、的目录上传附加文件；DELETE，删除指定的资源；COPY，将指定的资源复制到Destination消息头指定的位置；MOVE，将指定的资源移动到Destination消息头指定的位置；SEARCH，在一个目录路径中搜索资源。PROPFIND，获取与指定资源有关的信息，如作者、大小与内容类型。TRACE，在响应中返回服务器收到的原始请求。可以使用这种方法避开阻止跨站点脚本的防御9.2解决如何禁止DELETE、PUT、OPTIONS、TRACE、HEAD等协议访问应用程序应用程序呢？解决方法第一步：修改/conf/conf/下的下的web.xmlweb.xml文件的协议1. 2. 如果是如果是

36、web-app 里的里的 xsd 版本比版本比 2.4 高的，此步骤忽略，进行第二步修改。高的，此步骤忽略，进行第二步修改。第二步：在/conf/conf/下的下的web.xmlweb.xml 中添加如下的代码即可1. 2. 3./* 4.PUT 5.DELETE 6.HEAD 7.OPTIONS 8.TRACE 9. 10. 11. 12. 13. 14. BASIC 15. 备注：备注：对于前端有apache反向代理的架构，则在apache上面修改就可以了，后端tomcat就无需修改了，这样也不会影响后端tomcat的性能。修改httpd.conf，加入如下： Order Allow,De

37、ny Deny from all 10 禁止页面缓存禁止页面缓存10.1 原因能够访问到缓存的脱机数据导致泄密。10.2 解决建议在web管理后台程序的过滤器里增加如下代码： response.setHeader(Cache-Control, no-cache); /只是请求或响应消息不缓存 response.setHeader(Cache-Control, no-store); /在请求消息中发送将使得请求和响应消息都不使用缓存 response.setDateHeader(Expires, 0); /缓存距离过期的时间为0毫秒，即缓存立即过期 response.setHeader(Prag

38、ma, no-cache); /页面不缓存11 数据库错误模式数据库错误模式11.1 原因主要是一些数据连接错误信息，通过提交特殊构造的字符，程序会暴露一些数据库信息，也容易引起SQL注入攻击。现有平台发现的例子：Apache Tomcat/5.5.28 - Error report HTTP Status 500 - type Exception reportmessage description The server encountered an internal error () that prevented it from fulfilling this request.excepti

39、on javax.servlet.ServletException: org.hibernate.HibernateException: java.sql.SQLException: ORA-12899: value too large for column "QCSMS"."T_SYS_LOGON_LOG"."USER_CODE" (actual: 24, maximum: 20)标红的地方显示出输入数据未做有效性验证而导致数据库报出了底层错误并直接反馈给了浏览器而被appScan捕获。11.2 解决第一：加强输入数据的有效性验证，

40、第二：轨范代码错误捕获及日志打印。12 SQL注入文件写入（需要用户验证）注入文件写入（需要用户验证）12.1 原因“SQL 注入文件写入”并不是一个真正的测试，而更像是一个指示用户查看的指示。 缺省情况下此测试策略是禁用的，一旦开启，Appscan始终会报告此问题。仅仅开启测试策略“SQL 注入文件写入 (需要用户验证)”实际上并不会发送测试，它更多的是一种提醒，提醒您如果开启了以上“SQL 注入命令执行”中的任何或者两者变量（发送有效载荷“xp_cmdshell”），就需要检查服务器端文件系统中是否存在生成的文本文件。 两种变量为：向原始参数值中附加以下字符串向原始参数值中附加以下字符串:

41、 : ; execexec master.xp_cmdshellmaster.xp_cmdshell echoecho paramparam namename inin pathpath isis vulnerablevulnerable C:AppScanSQLTest.txt-(SQLC:AppScanSQLTest.txt-(SQL 注入探测注入探测) ) 和/或 向原始参数值中附加以下字符串向原始参数值中附加以下字符串: : execexec master.xp_cmdshellmaster.xp_cmdshell echoecho paramparam namename inin p

42、athpath isis vulnerablevulnerable C:AppScanSQLTest.txt-(SQLC:AppScanSQLTest.txt-(SQL 注入探测注入探测) ) 所以此漏洞警告就像他的名称中括号中注明的一样，需要用户自己到服务器上坚持是否真的生成了文本文件。12.2 解决第一：开启了此检查参数，必须到服务器应用目录下检查有无文本文件生成，第二：在appscan扫描时，在扫描配置 - 测试 - 测试策略中取消选择该策略。13 不充分的帐号封锁不充分的帐号封锁13.1 原因蛮力攻击是指恶意用户发送大量可能的密码和/或用户名以访问应用程序的尝试。 由于该技术包含大量登

43、录尝试，未限制允许的错误登录请求次数的应用程序很容易遭到这类攻击。 13.2 解决 请确定允许的登录尝试次数（通常是 3-5 次），确保超出允许的尝试次数之后，便锁定帐户。 为了避免真正的用户因帐户被锁定而致电支持人员的麻烦，可以仅临时性暂挂帐户活动，并在特定时间段之后启用帐户。帐户锁定大约 10 分钟，通常便足以阻止蛮力攻击。 可以采取验证码、短信等一次性权证的登录的方式。14 链接注入（便于跨站请求伪造）链接注入（便于跨站请求伪造）14.1 原因恶未对用户输入正确执行危险字符清理。“链接注入”是修改站点内容的行为，其方式为将外部站点的 URL 嵌入其中，或将有易受攻击的站点中的脚本 的 U

44、RL 嵌入其中。将 URL 嵌入易受攻击的站点中，攻击者便能够以它为平台来启动对其他站点的攻击，以及攻击这个易受攻击的站点本身。在这些可能的攻击中，有些需要用户在攻击期间登录站点。攻击者从这一易受攻击的站点本身启动这些攻击，成功的机会比较大，因为用户登录的可能性更大。“链接注入”漏洞是用户输入清理不充分的结果，清理结果会在稍后的站点响应中返回给用户。攻击者能够将危险字符注入响应中，便能够嵌入 URL 及其他可能的内容修改。以下是“链接注入”的示例（我们假设“”站点有一个用来问候用户的参数，称为“name”）。下列请求：HTTP:/ Smith会生成下列响应： Hello, John Smith

45、. 然而，恶意的用户可以发送下列请求：HTTP:/ Hello, . 14.2 解决对输入参数进行HTML的转义。private String htmlEscape(String input) return input.replace(&, &).replace(, >).replace(, <) .replace(, ').replaceAll(, "); 15 通过框架钓鱼通过框架钓鱼原因及解决同14节16 Caucho Resin resin-admin跨站点脚本编制跨站点脚本编制16.1 原因Resin是一款由Caucho Technology开

46、发的WEB服务器，可使用在Microsoft Windows操作系统下。Resin的resin-admin/digest.php页面错误地使用了REQUEST方式接受多个参数，远程攻击者可以通过提交恶意参数请求执行跨站脚本攻击，导致窃取基于Cookie的认证凭据。16.2 解决删除 Resin目录下的php/admin下的所有php文件。17 HTTP 响应分割响应分割17.1 原因由于HTTP标头结构“键：值”，其中每行由CRLF（回车、换行）组合分离。如果用户输入的值部分不正确转义/删除CRLF字符注入有可能改变了HTTP头结构。例子如下：示例：下列代码片段会从 HTTP 请求中读取网络日

47、志项的作者名字author，并在一个 HTTP 响应的 cookie 头文件中设置。 .author = Request.Form(AUTHOR_PARAM)Response.Cookies(author) = authorResponse.Cookies(author).Expires = cookieExpiration假设在请求中提交了一个字符串，该字符串由标准的字母数字字符组成，如 Jane Smith，那么包含该 cookie 的 HTTP 响应可能表现为以下形式：HTTP/1.1 200 OK.Set-Cookie: author=Jane Smith然而，因为 cookie 值来

48、源于未经校验的用户输入，所以仅当提交给 AUTHOR_PARAM 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。 如果攻击者提交的是一个恶意字符串，比如 Wiley HackerrnHTTP/1.1 200 OKrn.，那么 HTTP 响应就会被分割成以下形式的两个响应：HTTP/1.1 200 OK.Set-Cookie: author=Wiley HackerHTTP/1.1 200 OK.实际攻击如下：GET /shlm-wap/comments/user_comm_add_wap2.jsp?shopId=1405988&srcUrl=Foobar%3f%0d%0aApp

49、ScanHeader:%20AppScanValue%2f1%2e2%2d3%0d%0aSecondAppScanHeader:%20whatever HTTP/1.1Cookie: JSESSIONID=95DA32AD1747BC4E09E02EE0DCF5AD7A.worker2Accept: */*Accept-Language: en-USUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)Host: Referer: http:/ 302 Moved TemporarilyContent-Length: 0Date: Thu,

50、24 May 2012 01:04:23 GMTServer: Apache/2.2.3 (Unix) mod_jk/1.2.32Location: http:/ AppScanValue/1.2-3SecondAppScanHeader: whateverContent-Type: text/html;charset=UTF-8标红部分，提交参数srcUrl中有CRLF（%0d%0a），导致服务器返回时响应被分割。17.2 解决确保在适当位置进行输入验证并检验其属性是否正确，通过过滤器去掉CRLF字符等。18 Apache Tomcat Web表单哈希冲突拒绝服务漏洞表单哈希冲突拒绝服务漏洞

51、18.1 原因这个安全弱点利用了各语言的Hash算法的“非随机性”可以制造出N多的value不一样，但是key一样数据，然后让你的Hash表成为一张单向链表，而导致你的整个网站或是程序的运行性能以级数下降（可以很轻松的让你的CPU升到100%）。Apache Tomcat 拒绝服务（拒绝服务（CVE-2012-0022）受影响版本：Tomcat 7.0.0 7.0.22Tomcat 6.0.0 6.0.33Tomcat 5.5.0 5.5.3418.2 解决Tomcat 7.0.x 用户请升级至 7.0.23 或以上版本Tomcat 6.0.x 用户请升级至6.0.35 或以上版本Tomcat

52、 5.5.x 用户请升级至5.5.35 或以上版本19 会话会话cookie中缺少中缺少HttpOnly属性属性19.1 原因检测到所测试的 Web 应用程序设置了不含“HttpOnly”属性的会话 cookie。由于此会话 cookie 不包含“HttpOnly”属性，因此注入站点的恶意脚本可能访问此 cookie，并窃取它的值。任何存储在会话令牌中的信息都可能被窃取，并在稍后用于身份盗窃或用户伪装。如果使用了以下解决方法，那么通过js脚本将无法读取到cookie信息19.2 解决import java.io.IOException;import javax.servlet.Filter;i

53、mport javax.servlet.FilterChain;import javax.servlet.FilterConfig;import javax.servlet.ServletException;import javax.servlet.ServletRequest;import javax.servlet.ServletResponse;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;public class HttpOnlyFilter impl

54、ements Filter public void destroy() public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException HttpServletRequest request = (HttpServletRequest) req;HttpServletResponse response = (HttpServletResponse) res;/ 强制使用以下only 逻辑String sessionid = r

55、equest.getSession().getId();String contextPath = request.getContextPath();String secure = ;if (request.isSecure() secure = ; Secure;response.setHeader(SET-COOKIE, JSESSIONID= + sessionid + ; Path= + contextPath + ; HttpOnly + secure);chain.doFilter(req, res);public void addHttpOnly() public void ini

56、t(FilterConfig arg0) throws ServletException 20 基于基于 DOM 的跨站点脚本编制的跨站点脚本编制20.1 原因基于 DOM 的跨站点脚本编制不需要依赖于服务器端响应的内容，如果某些 HTML 页面使用了document.location、document.URL 或者 document.referer 等 DOM 元素的属性，攻击者可以利用这些属性植入恶意脚本实施基于 DOM 的跨站点脚本编制攻击解决。一个很简单的 HTML 页面来演示基于 DOM 的跨站点脚本编制原理。假设有这么一个静态 HTML 页面：Welcome!Hi var pos=document.URL.indexOf(name=)+5; document.write(document.URL.substring(pos,document.URL.length);Welcome to our system按照该页面 JavaScript 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息。链接如：welcome.html?name=Jeremy但如果恶意攻击者输入类似如下的脚本，该页面则会执行被注入的 JavaScript 脚本。链接如：welcome.html?name=alert(document.