网络安全-已解密的登录请求，会话标识未更新，跨站点请求伪造

这些没有那么麻烦，一天就搞定了。所以简单记录一下。

已解密的登陆请求是非常简单的,随便找个浏览器，火狐谷歌都行。打开F12找到网络

就可以非常清楚的看到这里是明文密码。虽然这里是客户端，还没有到传输阶段，这里的明文密码也是非常危险的。

这里使用抓包工具抓包，也是得到相同的结果，密码是明文。

经过度娘的千般指点，得到3个方法：

1，使用SSL加密，就是给网站增加https。这种办法风险低，而且只需要改配置，不需要修改程序，非常简单。

2，使用安全控件，就是各大网银，淘宝，之类的安全控件。这种控件风险更小，只是实现起来复杂度高。

3，前端做不可逆加密。

我的首选是https加密，但是，因为和使用HTTP动词篡改的认证旁路遇到一样的问题。所以我https并没有添加成功。

安全控件在本公司使用的概率小，不能自己开发一个加密算法，所以也放弃了。

这里需要感谢 CSDN用户aqwe23共享的MD5加密文件 MD5.js

我在前端做了md5加密，所以比明文密码要相对来说要安全一点。

document.forms[0].onsubmit = function(e) {  var password = document.forms[0].password.value;document.forms[0].password.value = hex_md5(password);
}

我们公司登陆这里做的还是比较好的，加密算法有2层，使用md5加密之后还有个加密算法，才存入到数据库。在改写验证登陆算法之后我实现了登陆。如果有人使用的不是md5加密，把js换成对应的加密方式即可。

会话标识未更新

我从没想过会遇到这个问题，还是度娘解惑。这个问题引起的原因非常简单，struts在登陆之后往cookis之中写入了一个叫JSESSIONID值。这个值用来寻找服务器的sessionid，经过我多方对比发现这个值和sessionid完全不一样。我说我明明在登陆后建session重置了，怎么还会有这个问题。这个问题根本就不是session的问题，只是对于cookies的标识的问题。所以服务器后端完全没必要重置session只需要将JSESSIONID值更改即可。

<span style="white-space:pre">  </span>/*** 设置当前Session到Cookie中* @param request* @param response*/public static void setCookiesByJsessionid(HttpServletRequest request, HttpServletResponse response){Cookie[] cookies = request.getCookies(); //先检查是否存在JSESSIONIDboolean flag = true;for(int i=0;i<cookies.length;i++){Cookie c = cookies[i];if("JSESSIONID".equals(c.getName())){c.setValue(request.getSession(true).getId());response.addCookie(c);flag = false;}}//如果不存在JSESSIONID就新增一个 存活期为1个月if(flag){//存活期为一个月 (日*时*分*秒)int maxAge = 30 * 24 * 60 * 60;Cookie cookie = new Cookie("JSESSIONID", request.getSession(true).getId());cookie.setMaxAge(maxAge);response.addCookie(cookie);}System.out.println("Cookie已经保存: JSESSIONID=" + request.getSession(true).getId()); }

在登陆完成调用此方法即可，我这里是将jsessionid改成了和sessionid一样，各位可以根据需要修改。

跨站点请求伪造

去年就解决过了跨站点的各种问题，这里怎么又冒出来一个，回头看下自己的过滤器，没发现配置少啊，然后咨询安全检查的相关人员，原来只是referer头的问题。

/*** 检查头文件* @param request* @param response* @return 头文件符合标准则返回false   不符合标准则为true*/private boolean checkReferer(HttpServletRequest request,HttpServletResponse response) {String referer = request.getHeader("referer");if(null==referer){return false;}else if(referer.startsWith("http://"+service_name)||referer.startsWith("https://"+service_name)){return false;}return true;}

添加了一个Referer头的方法，搞定，service_name这个是在配置文件中的设置，大家自行修改。这里的验证其实还是太简单了一些，下次改成正则，或者会安全一点。

网络安全-已解密的登录请求，会话标识未更新，跨站点请求伪造相关推荐

一个过滤器不仅解决了会话标识未更新同时还顺带解决了已解密的登录请求
废话不多说直接上代码,少点套路,多点真诚. 过滤器代码如下: package com.filter; import java.io.IOException; import java.util.Enum ...
会话标识未更新 java_Appscan漏洞之会话标识未更新
本次针对 Appscan漏洞会话标识未更新进行总结,如下: 1. 会话标识未更新 1.1.攻击原理在认证用户或者以其他方式建立新用户会话时,如果不使任何现有会话标识失效,攻击者就有机会窃取已认证的 ...
java或者jsp中修复会话标识未更新漏洞
appscan扫描出来的. 1. 漏洞产生的原因: AppScan会扫描"登录行为"前后的Cookie,其中会对其中的JSESSIONOID(或者别的cookie id依应用而定) ...
使用https协议解决掉顽固不化的已解密的登录请求
1.1 已解密的登录请求概述在应用程序测试过程中,检测到将未加密的登录请求发送到服务器.由于登录过程所用的部分输入字段(例如:用户名.密码.电子邮件地址.社会保险号码,等等)是个人敏感信息,建议通过 ...
java已解密的登录请求_使用https协议解决掉顽固不化的已解密的登录请求
1.1 已解密的登录请求概述在应用程序测试过程中,检测到将未加密的登录请求发送到服务器.由于登录过程所用的部分输入字段(例如:用户名.密码.电子邮件地址.社会保险号码,等等)是个人敏感信息,建议通过 ...
【burpsuite安全练兵场-客户端12】跨站点请求伪造CSRF-12个实验（全）
前言: 介绍: 博主:网络安全领域狂热爱好者(承诺在CSDN永久无偿分享文章). 殊荣:CSDN网络安全领域优质创作者,2022年双十一业务安全保卫战-某厂第一名,某厂特邀数字业务安全研究员,edus ...
如何解决跨站点请求伪造
转载自:http://www.cnblogs.com/jimor/p/3417998.html IBM appscan扫描漏洞--跨站点请求伪造 appscan修订建议: 如果要避免 CSRF 攻击, ...
密码学系列之:csrf跨站点请求伪造
文章目录简介 CSRF的特点 CSRF的历史 CSRF攻击的限制 CSRF攻击的防范 STP技术 Cookie-to-header token Double Submit Cookie SameSi ...
Web渗透-CSRF跨站点请求伪造(Cross—Site Request Forgery)
CSRF/XSRF 跨站点请求伪造 `也被称为"One Click Attack"或者Session Riding` 一种对网站的恶意利用漏洞但你不能保证以下情况不会发生: CS ...

网络安全-已解密的登录请求，会话标识未更新，跨站点请求伪造

网络安全-已解密的登录请求，会话标识未更新，跨站点请求伪造相关推荐

最新文章

热门文章