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平台上开到的三峡大坝,云雾缭绕吧
XSS防御进阶之session失效解决方案_第1张图片
湖中唱歌的幺妹
XSS防御进阶之session失效解决方案_第2张图片

你可能感兴趣的:(tomcat,tomcat新特性,xss,session失效)