[英]Does the Play! framework have any built in mechanism to prevent session hijacking?
[英]How to prevent tomcat session hijacking?
在我的web.xml中,我为某些资源定义了用户数据约束:
<security-constraint>
<web-resource-collection>
<web-resource-name>Personal Area</web-resource-name>
<url-pattern>/personal/*</url-pattern>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>User Area</web-resource-name>
<url-pattern>/user/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
我认为这是一个漏洞? 或者是我的配置错误?
我看到的问题如下:在使用cookie ID1浏览HTTP时,有一个攻击者正在监听我的网络流量。 他“窃取”我的cookie ID1。 现在我切换到HTTPS,我的cookie仍然是ID1。 我登录 然后攻击者能够接管我的会话,因为他知道我的cookie ...
如果它是Tomcat的最新版本,您可能没有问题。 但是,这取决于您检查与会话关联的SSL ID。 这可以使用如下代码获得
String sslId = (String) req.getAttribute("javax.servlet.request.ssl_session");
(请注意,属性键将来可能会更改为javax.servlet.request.ssl_session
_id
- 作为Servlet 3.0规范的一部分)。
我使用以下doGet
方法设置了一个servlet:
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession(true);
String sid = session.getId();
String sslId = (String) request.getAttribute(
"javax.servlet.request.ssl_session");
String uri = request.getRequestURI();
OutputStream out = response.getOutputStream();
PrintWriter pw = new PrintWriter(out);
HashMap<String, Object> secrets;
Object secret = null;
Object notSecret;
Date d = new Date();
notSecret = session.getAttribute("unprotected");
if (notSecret == null) {
notSecret = "unprotected: " + d.getTime();
session.setAttribute("unprotected", notSecret);
}
secrets = (HashMap<String, Object>) session.getAttribute("protected");
if (secrets == null) {
secrets = new HashMap<String, Object>();
session.setAttribute("protected", secrets);
}
if (sslId != null) {
if (secrets.containsKey(sslId))
secret = secrets.get(sslId);
else {
secret = "protected: " + d.getTime();
secrets.put(sslId, secret);
}
}
response.setContentType("text/plain");
pw.println(MessageFormat.format("URI: {0}", new Object[] { uri }));
pw.println(MessageFormat.format("SID: {0}", new Object[] { sid }));
pw.println(MessageFormat.format("SSLID: {0}", new Object[] { sslId }));
pw.println(MessageFormat.format("Info: {0}", new Object[] { notSecret }));
pw.println(MessageFormat.format("Secret: {0}", new Object[] { secret }));
pw.println(MessageFormat.format("Date: {0}", new Object[] { d }));
pw.close();
}
然后,我使用Firefox和Live HTTP Headers扩展来调用合适的不受保护的URL,以获取会话cookie。 这是我导航时发送的响应
http://localhost:8080/EchoWeb/unprotected
(我的web.xml和你的一样,只保护/ user / *和/ personal / *):
URI: /EchoWeb/unprotected SID: 9ACCD06B69CA365EFD8C10816ADD8D71 SSLID: null Info: unprotected: 1254034761932 Secret: null Date: 27/09/09 07:59
接下来,我尝试访问受保护的URL
http://localhost:8080/EchoWeb/personal/protected
并且,正如所料,我被重定向到
https://localhost:8443/EchoWeb/personal/protected
而且回应是
URI: /EchoWeb/personal/protected SID: 9ACCD06B69CA365EFD8C10816ADD8D71 SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1 Info: unprotected: 1254034761932 Secret: protected: 1254034791333 Date: 27/09/09 07:59
请注意,cookie /会话ID是相同的,但我们现在有一个新的SSLID。 现在,让我们尝试使用会话cookie来欺骗服务器。
我设置了一个Python脚本, spoof.py
:
import urllib2
url = "https://localhost:8443/EchoWeb/personal/protected"
headers = {
'Host': 'localhost:8080',
'User-Agent': 'Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'Accept-Language': 'en-gb,en;q=0.5',
'Accept-Charset': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7',
'Cookie' : 'JSESSIONID=9ACCD06B69CA365EFD8C10816ADD8D71'
}
req = urllib2.Request(url, None, headers)
response = urllib2.urlopen(req)
print response.read()
现在,您不需要了解Python,特别是 - 我只是尝试将HTTP请求发送到Cookie中具有相同会话ID的(不同的)受保护资源。 这是我两次运行恶搞脚本时的响应:
C:\temp>spoof URI: /EchoWeb/personal/protected SID: 9ACCD06B69CA365EFD8C10816ADD8D71 SSLID: 4abf0eafb4ffa30b6579cf189c402a8411294201e2df94b33a48ae7484f22854 Info: unprotected: 1254034761932 Secret: protected: 1254035119303 Date: 27/09/09 08:05 C:\temp>spoof URI: /EchoWeb/personal/protected SID: 9ACCD06B69CA365EFD8C10816ADD8D71 SSLID: 4abf0eb184cb380ce69cce28beb01665724c016903650539d095c671d98f1de3 Info: unprotected: 1254034761932 Secret: protected: 1254035122004 Date: 27/09/09 08:05
请注意,在上述响应中,在第一个未受保护的请求中设置的会话数据(时间戳为1254034761932
的值)已在整个过程中发送,因为Tomcat使用相同的会话,因为会话ID相同。 这当然不安全 。 但请注意, 每次 SSL ID 都不同 ,如果您使用这些 ID来键入会话数据(例如,如图所示),您应该是安全的。 如果我刷新我的Firefox选项卡,这是响应:
URI: /EchoWeb/personal/protected SID: 9ACCD06B69CA365EFD8C10816ADD8D71 SSLID: 4abf0d67549489648e7a3cd9292b671ddb9dd844b9dba682ab3f381b462d1ad1 Info: unprotected: 1254034761932 Secret: protected: 1254034791333 Date: 27/09/09 08:05
请注意,SSLID是一样的早期Firefox的请求。 因此,服务器可以使用SSL ID值来区分会话。 特别注意的是,“受保护的数据”是从Firefox的会议上提出的每个请求相同,但每个欺骗性的会议不同 ,从Firefox的会议上也有所不同。
我觉得它的设计就像这样。 您无法在会话中建立访问控制。 您需要使用其他参数。 您需要添加身份验证并使用基于角色的控制。
在Tomcat中,有保护但恰恰相反。 如果您在安全区域中进行会话,则该会话不会转移到不受保护的区域。 Tomcat通过在cookie上设置“secure”标志来实现这一点,因此cookie不会发送到HTTP连接。
我建议您在验证会话时更改sessionId。
通过这种方式,旧的sessionId变得无用,并且会话劫持是不可能的。
要更改servlet容器中的sessionId:
关于SSLID,请注意客户端和服务器可以随时关闭连接。 关闭时,将发生新的SSL握手并生成新的SSID。 因此,IMO SSLID不是跟踪(或帮助跟踪)会话的可靠方式。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.