增加图注释
This commit is contained in:
8
06.4.md
8
06.4.md
@@ -27,19 +27,27 @@ count.gtpl的代码如下所示:
|
||||
|
||||

|
||||
|
||||
图6.4 浏览器端显示count数
|
||||
|
||||
随着刷新,数字将不断增长,当数字显示为6的时候,打开浏览器(以chrome为例)的cookie管理器,可以看到类似如下的信息:
|
||||
|
||||
|
||||

|
||||
|
||||
图6.5 获取浏览器端保存的cookie
|
||||
|
||||
下面这个步骤最为关键: 打开另一个浏览器(这里我打开了firefox浏览器),复制chrome地址栏里的地址到新打开的浏览器的地址栏中。然后打开firefox的cookie模拟插件,新建一个cookie,把按上图中cookie内容原样在firefox中重建一份:
|
||||
|
||||

|
||||
|
||||
图6.6 模拟cookie
|
||||
|
||||
回车后,你将看到如下内容:
|
||||
|
||||

|
||||
|
||||
图6.7 劫持session成功
|
||||
|
||||
可以看到虽然换了浏览器,但是我们却获得了sessionID,然后模拟了cookie存储的过程。这个例子是在同一台计算机上做的,不过即使换用两台来做,其结果仍然一样。此时如果交替点击两个浏览器里的链接你会发现它们其实操纵的是同一个计数器。不必惊讶,此处firefox盗用了chrome和goserver之间的维持会话的钥匙,即gosessionid,这是一种类型的“会话劫持”。在goserver看来,它从http请求中得到了一个gosessionid,由于HTTP协议的无状态性,它无法得知这个gosessionid是从chrome那里“劫持”来的,它依然会去查找对应的session,并执行相关计算。与此同时 chrome也无法得知自己保持的会话已经被“劫持”。
|
||||
## session劫持防范
|
||||
### cookieonly和token
|
||||
|
||||
Reference in New Issue
Block a user