XSS防御进阶之session失效解决方案

LK最近刚从宜昌回来，宜昌之前从没有去过，来了之后才知道是三峡大坝的所在地，那LK自然是不能错过这次千载难逢的机会，回北京的前一天和同事一起去了三峡大坝和三峡人家玩了一圈，大坝的雄伟和三峡人家的幺妹让人浏览往返。本章最后会附上几张图片供大家欣赏。
扯哪去了，来看看正题，LK前不久写过一片WEB安全漏洞的文章，当时在配制https时，一路下来都挺正常，测试时也很正常，但LK忽略了嵌套在浏览器中的applet,测试果然有问题，applet调用前后sessionid是不一致的，搞了好久才弄好，现在就将主要实践总结一下：
1. tomcat6—>tomcat7—>tomcat8版本特性
2. httponly和secure
3. 访问applet前后sessionid不一致原因及解决办法

1.tomcat6--->tomcat7--->tomcat8版本特性

提到session就必须提起web容器tomcat,每一代tomcat的版本升级就会带来重大变化，因为XSS防御需要进行tomcat配置，所以有必要了解tomcat的版本新特新。

先来看看tomcat7新特性：

• 使用随机数去防止跨站脚本攻击。
  主要是说tomcat7中有一个servlet过滤器，用于将随机数存储在用户每次请求处理后的seesion会话中。这个随机数，必须作为每次请求中的一个参数。 Servlet过滤器然后检查在请求中的这个随机数是否与存储在用户session中的随机数是一样的。如果它们是相同的，该请求是判断来自指定的网站。

• 改变了安全认证中的jessionid的机制，防止session攻击。
  这个就比较重要了，和后面要说的session失效有很大的原因。
  来看看什么是Session劫持攻击
  首先恶意攻击者会伪造一个带有Jsessionid的请求地址访问网页。
  因为cookie是以jessionid的形式保存在浏览器中的。
  当使用者点击这个请求时，提示输入验证信息之后就可以登陆系统。
  攻击者使用这个带jsessionid的链接，以受害者的身份登陆进系统。
  TOMCAT 7对此的解决方案是一个补丁，它在验证后改变了jsessionid
  经过验证就是这个httponly

• 内存泄露的侦测和防止
  开发者在部署他们写的程序到生产环境上时，经常会遇到Pemgen错误：OutOfMemoryError。这是由于内存泄露而引起的。通常开发者是通过增大permgen内存的大小去解决或者就是重新启动tomcat。

  TOMCAT 7包含了一个新的特性，它通过把不能垃圾回收的引用对象移走的方法，能解决一些Permgen内存泄露的问题。

• 在war文件外使用别名去存储静态内容。
  其它内容可以参考这篇博客：http://tech.it168.com/a2010/0925/1107/000001107436_3.shtml

再来看看tomcat8又有哪些改进：

• 支持servlet3.1, jsp 2.3, el表达式3.0 and Java WebSocket 1.0.
• 默认http与ajp请求实现non-blocking技术，即NIO技术。
• 多个应用发布的时候可以先打成jar包，然后打成一个总的war发布。
• 默认支持应用工程字符集为UFT-8
• 提升了日志性能，采用了异步技术
• 新增AJP 连接采用了Servlet3.1的non-blocking IO。

*总结：tomcat7会在验证Jessionid之后修改它的值。
　　 tomcat8继承tomcat7这一特性## Z*

2.httponly和secure

• 首先这两个属性都是用来增强cookie的安全性的
• tomcat7以后默认是自带“Usehttponly=“true””属性的。这也就是他会导致jsessionid不一致的原因。
• 在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。
• 当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。

总结：LK之所以解释这两个属性是因为httponly属性设置为true时，sessionid会改变。

3.访问applet前后sessionid不一致原因及解决办法

applet已经过时了，但老项目还在使用，不管他既然它存在就有它的合理性。 LK遇到的session不一致的原因

• 项目运行在tomcat6下时，内置在applet中的地址是以http开头并且端口号还是默认的8080
• 项目运行在tomcat7下时，除了以上原因，就是tomcat7新特性导致的。

解决方法：

• 将applet中的http请求换成https请求，端口号也改变。
• 在tomcat7中context.xml的content属性中添加UseHttpOnly=true属性
• 或者将客户端Jsessionid当作参数传递给applet，applet响应服务器请求时，把这个值重新设置给cookie的jessionid

参数

<applet code=Applet1.class codebase="app" width="200" height="200">
<param name="sessionid" value="YOURSESSIONID11111"/>
</applet>

cookie设置

Applet与服务器的交互可以使用HttpUrlConnection类，该类有个setRequestProperty方法用来设置请求报文头数据，例如Accept、Cookie等。执行con.setRequestProperty("Cookie","JSESSIONID=传入的SessionId");

下面是LK用来监听httpsession变化使用的代码

public class SessionListener implements HttpSessionListener {

	HashMap<String, HttpSession> sessions=null;
	/**
	 * Default constructor.
	 */
	public SessionListener() {
		// TODO Auto-generated constructor stub
	}

	/**
	 * @see HttpSessionListener#sessionCreated(HttpSessionEvent)
	 */
	public void sessionCreated(HttpSessionEvent e) {
		HttpSession session = e.getSession();
		  sessions = (HashMap<String, HttpSession>) session.getServletContext()
				.getAttribute("sessions");
		if (sessions == null) {
			sessions = new HashMap<String, HttpSession>();
		}
		sessions.put(session.getId(), session);
		session.getServletContext().setAttribute("sessions", sessions);
	}

	/**
	 * @see HttpSessionListener#sessionDestroyed(HttpSessionEvent)
	 */
	public void sessionDestroyed(HttpSessionEvent e) {
		HttpSession session = e.getSession();

		session.getServletContext().getAttribute("sessions");
		if (sessions != null) {
			sessions.remove(session.getId());
		}
	}

}

好到此整个处理结束，大家是不是早就迫不及待想看幺妹了呢！
185平台上开到的三峡大坝，云雾缭绕吧

湖中唱歌的幺妹