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属性。