AWVS扫描漏洞修改记录

Slow HTTP Denial of Service Attack
原因：当恶意攻击者以很低的速率发起HTTP请求，使得服务端长期保持连接，这样使得服务端容易造成占用所有可用连接，导致拒绝服务
解决办法：将../tomcat/conf/server.xml文件中的connectionTimeout="20000"改为"8000"左右
在${tomcat-home}/conf/server.xml中更改Connector的实现（修改后需重启服务）：
（1）使用NIO(非阻塞IO)实现替换默认的BIO(阻塞IO)实现，提高并发连接的数量。
（2）把connectionTimeout配置项值改成8000左右(即8秒)，严格控制请求超时时间。
示例配置如下：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="8000" redirectPort="8443" /> 

Password type input with auto-complete enabled
原因：HTML <input>标签中的autocomplete属性规定输入字段是否应该启用自动完成功能。默认值是on，即允许浏览器预测对字段的输入。当用户在字段开始键入时，浏览器会基于之前键入过的值进行预测显示。当type="password"时，自动补充功能可能造成攻击者知道密码的部分内容即可利用cache完成密码破解，是一个不安全因素。
解决办法：为type="password"的input标签元素添加autocomplete="off"配置。

Acunetix WVS found a HTML form with no apparent CSRF protection implemented.
背景知识：CSRF（Cross-site request forgery，跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF或者XSRF），是一种对网站的恶意利用。和跨站脚本攻击（XSS）不同，XSS是利用站点内的信任用户，而CSRF则是通过伪造来自受信任用户的请求来利用受信任的网站。
解决办法：
1、利用SecureRandom产生一个加密随机数。
2、将这个随机数设置到session中。
3、将这个随机数隐藏在jsp表单中并和表单信息一起传递到后端。
4、表单数据提交到后端时，对传递过来的随机数参数和session中保存的随机值进行比较验证，验证通过才进行相关业务处理。
示例代码如下：
<%
    SecureRandom srRandom = SecureRandom.getInstance("SHA1PRNG");
    String csrfRandom = "" + srRandom.nextLong();
    session.setAttribute("csrfRandom", csrfRandom);
%>

<form>
    <input type="text" name="userName" id="userName" required placeholder="用户名" autocomplete="off">
    <br />
    <input type="password" name="userPwd" id="userPwd" required placeholder="密码" autocomplete="off">
    <br />
    <input type="hidden" name="csrfRandom" value="<%=csrfRandom%>"></input>
    <button>提交</button>
</form>

String csrfRandom = request.getParameter("csrfRandom");
String csrfRandomSession =(String)request.getSession().getAttribute("csrfRandom");
if(csrfRandom != null && csrfRandom.equalsIgnoreCase(csrfRandomSession)){
    // dosomething
}

Login page password-guessing attack
密码猜想攻击，可通过提升密码加密强度解决，比如将MD5加密改为rsa加密等。

Session Cookie without HttpOnly flag set
背景知识：Session数据保存在服务器端, 但是每一个客户端都需要保存一个SessionID（SessionID保存在Cookies中, 关闭浏览器时过期），在向服务器发送的HTTP请求中会包含SessionID, 服务器端接收到后根据SessionID获取此用户的Session信息并进行认证。可以在web.xml里加上如下配置避免该异常，但可能导致一些其他问题。。。
<cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
</cookie-config>

Session Cookie的HttpOnly和secure属性说明：
secure属性是防止信息在传递的过程中被监听捕获后信息泄漏。当设置为true时，表示创建的Cookie会被以安全的形式向服务器传输，只能在HTTPS连接中被浏览器传递到服务器端进行会话验证，如果是HTTP连接则不会传递该信息，从而不会被窃取到Cookie的具体内容。 ---> 会导致http协议下的Cookie不能传输，使得http协议下的部分功能不能使用。
备注：若要在应用中支持两种协议，可以通过request.getScheme()获取是哪种协议，然后根据协议动态控制secure配置，eg：
String url = req.getHeader("Referer");      
if(url.startsWith("https")){
    cookie.setSecure(true);
} else {
    cookie.setSecure(false);
}
HttpOnly属性的目的是防止程序获取cookie后进行攻击。如果设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，从而能有效的防止XSS攻击。--->会导致js中操作cookie的相关功能异常。
备注：GlassFish2.x支持的是servlet2.5，而servlet2.5不支持Session Cookie的"HttpOnly"属性。GlashFish3.0(支持servlet3.0)默认开启Session Cookie的HttpOnly属性。