赞
踩
会话(Session)是一个客户与服务器之间的不中断的请求响应序列。对客户的每个请求,服务器能够识别出请求来自于同一个客户。当一个未知的客户向Web应用程序发送第一个请求时就开始了一个会话。当客户明确结束会话或服务器在一个预定义的时限内不从客户接受任何请求时,会话就结束了。当会话结束后,服务器就忘记了客户以及客户的请求。
客户向Web应用服务器发送的首次请求并不是指客户与服务器的第一次交互。首次请求指的是需要创建会话的请求。我们称之为首次请求是因为该请求是对多个请求计数的开始(逻辑上),也是服务器开始记住客户的请求。例如,当用户登录或向购物车中添加一件商品时,就必须开始一个会话。
web会话可简单理解为:用户开一个浏览器,访问某一个web站点,在这个站点点击多个超链接,访问服务器多个web资源,然后关闭浏览器,整个过程称之为一个会话。
这是百度百科给的解释,我的理解是:一次客户端发出的请求被服务器接受并返回请求,直至停止客户端请求的整个过程称为一个会话
首先应该了解http是一个无状态协议
什么是无状态呢?就是说这一次请求和上一次请求是没有任何关系的,互不认识的,没有关联的。即每次服务端接收到客户端的请求时,都是一个全新的请求,服务器并不知道客户端的历史请求记录;而Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。这种无状态的的好处是快速。
客户端访问服务器,服务器存储数据value,把session ID返回给客户端,客户端下次 session ID 来访问服务器,服务器就能给出客户端的数据。如果负载均衡,客户端访问了另一个服务器,那个服务器没有客户端的数据。(意思就是假如一段时间内 A 服务器的访问量激增,会转发到 B 服务器进行访问,但是 B 服务器并没有存储 A 的 Session,会导致 Session 的失效。)
客户端访问服务器,服务器返回cookie给客户端,客户端存储 cookie,下次需要带着cookie访问服务器,服务器返回相应的数据。
观察上面的过程,是不是发现两个过程基本相同?事实是,就是这样的。因为 sessionid 是包含在 cookie 里的。意思就是,sessionid 是存储在cookie里的,所以在客户端。具体过程是客户端第一次请求,服务器返回请求并给出 cookie,其中包含 sessionid ,随后客户端第二次带着 cookie 和 sessionid 请求服务器,服务器根据 sessionid 找到存储的 session 数据并返回。
区别
● 数据存放位置不同:Session数据是存在服务器中的,cookie数据存放在客服端当中;
● 安全程度不同:cookie放在客户端中并不安全,session放在服务器中,相对安全;
● 性能使用程度不同:session放在服务器上,访问增多会占用服务器的性能;考虑到减轻服务器性能方面,应使用cookie。
联系
● cookie只是实现session的其中一种方案。虽然是最常用的,但并不是唯一的方法。禁用cookie后还有其他方法存储,比如放在url中;
● 现在大多都是Session + Cookie,但是只用session不用cookie,或是只用cookie,不用session在理论上都可以保持会话状态。可是实际中因为多种原因,一般不会单独使用;
● 用session只需要在客户端保存一个id,实际上大量数据都是保存在服务端。如果全部用cookie,数据量大的时候客户端是没有那么多空间的;
● 如果只用cookie不用session,那么账户信息全部保存在客户端,一旦被劫持,全部信息都会泄露。并且客户端数据量变大,网络传输的数据量也会变大。
token 译为令牌,是用户身份的验证方式
最简单的token组成: uid (用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名)
token的认证流程跟cookie相似,不再赘述。
● token是开发定义的,session是http协议规定的;
● token不一定存储,session存在服务器中;
● token可以跨域,session不可以跨域(cookie也是),它是与域名绑定的。
● 总的来看,token安全性最高
云演给出的解释是:
会话固定(Session fixation), 是一种诱骗受害者使用攻击者指定的会话标识(SessionID) 的攻击手段。是利用服务器的 session 不变机制, 借他人之手获得认证和授权,然后冒充他人,就会发生认证问题和会话固定攻击。可能导致部分甚至全部导致账户遭受攻击。一旦成功,攻击者能执行受害用户的任何操作,因此特权账户是常见的攻击对象。
我对此理解的一个例子是:攻击者首先在未登录状态下访问网站得到 sessionid,然后把带有 sessionid 的链接发给受害者,受害者点击链接并登录,而由于 sessionid 是不变的,攻击者就可以用这个 sessionid 来登录,获取受害者的页面。更形象一点就是,我在网吧上号,然而忘了取消记住密码,然后我号就没了。
检测漏洞方法也很简单,登录网站前后查看 sessionid 是否有变化即可
由于没有找到存在会话固定漏洞的靶场,就用云演平台的测试吧。
作为攻击者,首先登录网站,获取网站 sessionid
然后构造钓鱼网页,发送给受害者
<html>
<body>
//目标网站url
<form action="http://ab9c9564.lxctf.net/" method="post">
<input type="hidden" name="session_id" value="a1bsj2lbbfgubvreqinfrooqa6">
//sessionid值
<input type="submit">
</form>
</body>
</html>
身份转变,我们现在是受害者,收到钓鱼网页直接点击,此时发现 sessionid 值确实是攻击者的 sessionid
作为受害者登录网站,这边不知道为啥登不上去…看了下前端代码逻辑,应该是可以爆破的,我没试
反正接下来登录之后发现 sessionid 的值仍然是不变的,而此时攻击者已经达成目的了。他不需要用户的账号密码,直接访问后台登录页面即可登陆上用户的账号来干坏事。
会话固定这个漏洞体现了 cookie 及其包含 sessionid 存储在客户端中极易被发现的特性,sessionid 不变也是该漏洞存活的最关键因素。
云演给出的解释是:
会话劫持(Session hijading),这是一种通过获取用户Session ID后,使用Session ID登录目标账号的攻击方法,此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户,因此需要保证会话标识不被泄漏。
感觉跟会话固定还是挺像的,不同的是,会话劫持需要获得受害者的cookie。偷 cookie 这事儿 xss 在行,所以俩兄弟经常结伴作恶。
首先注册一个账号并登录
随便在一首歌的评论区,可以看见前端对用户评论内容是没有任何过滤的
可以利用 xss 漏洞,输入 LBWNB"><script>alert(document.cookie)</script><span style="
可以看出弹出 cookie 了,但是是我们自己的,我们要获取管理员的。此时攻击已经完成了,坐等管理员上钩查看我们的评论。
受害者管理员被迫上线
查看刚刚我们的评论,发现 cookie 的 sessionid 弹出了(这边有个bug,测试当然我是攻击者也是受害者,那我这弹窗是受害者的弹窗攻击者又看不见,所以攻击者是怎么知道 cookie 的,应该是有什么工具?)
攻击者心满意足,回到自己的账户,把 sessionid 值改成管理员的
直接访问后台
无需账号密码即可访问
两个案例可以看出,都是通过 sessionid 来请求服务器并返回请求得到登陆权限。不同的是,会话固定使用的是攻击者自己的,而会话劫持的关键是盗取受害者的 cookie,后伪造成受害者来使坏
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。