第 28 题：cookie 和 token 都存放在 header 中，为什么不会劫持 token？

Question

cookie：服务员看你的身份证，给你一个编号，以后，进行任何操作，都出示编号后服务员去看查你是谁。

token：直接给服务员看自己身份证

Answer 1

csrf例子：假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="<http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman>">
如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

这个 SameSite=strict 就可以对付了。

Answer 2

看了大家的回答，又去查了一下，写一下自己的理解，如果哪里不对，还请大家指正~ 谢谢~

cookie

cookie可以存一些用户信息。因为 HTTP 是无状态的，它不知道你有没有登陆过。故可以通过cookie里的信息解决无状态的问题。

而浏览器，会自动带上请求同域的cookie。（AJAX 不会自动携带cookie）

token

后端把用户信息和其他内容放进去，通过 jwt 生成 token，返回给前端。
浏览器是不会自动携带 token。

CSRF 跨站点请求伪造

通过浏览器会自动携带同域cookie的特点。cookie的传递流程是用户在访问站点时，服务器端生成cookie，发送给浏览器端储存，当下次再访问时浏览器会将该网站的cookie发回给服务器端

• 如果用户登陆了A网站，拿到了cookie，又点击了恶意的网站B。
• B收到请求以后，返回一段攻击代码，并且发出一个请求给网站A。
• 浏览器会在用户不知情的情况下，根据B的请求，带着cookie访问A。

由于HTTP是无状态的，A网站不知道这个请求其实是恶意网站B发出的，就会根据cookie来处理请求，从而执行了攻击代码。

而浏览器不会自动携带 token，所以不会劫持 token。

XSS

跨站脚本工攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或者JavaScript进行的一种攻击。

就是说，cookie和token都可能被拿到，所以都废了。

而浏览器，会自动带上请求同域的cookie。（AJAX 不会自动携带cookie） 应该是同站,而不是同域

Answer 3

cookie
举例：服务员看你的身份证，给你一个编号，以后，进行任何操作，都出示编号后服务员去看查你是谁。

token
举例：直接给服务员看自己身份证

是倒是这个理，不过你这个说的也太简陋了，
补充点：服务员给你的编号是状态化的，这个信息是会过期的，但是token使用的身份证号码是持久化的

Answer 4

cookie：登陆后后端生成一个sessionid放在cookie中返回给客户端，并且服务端一直记录着这个sessionid，客户端以后每次请求都会带上这个sessionid，服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie拿到了sessionid后，就可以完全替代你。

token：登陆后后端不返回一个token给客户端，客户端将这个token存储起来，然后每次客户端请求都需要开发者手动将token放在header中带过去，服务端每次只需要对这个token进行验证就能使用token中的信息来进行下一步操作了。

xss：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

csrf：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

csrf例子：假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="<http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman>">
如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

上面的两种攻击方式，如果被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。

以上面的csrf攻击为例：

• cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作。
• token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作。

这是个人理解的为什么只劫持cookie不劫持token的原因。

存在客户端的信息都是不安全。入侵者key轻松获取到token，在他的钓鱼网站也是很轻易的将偷来的token放在接口的header里的

Answer 5

token 为什么要放到 header 里面，作为 URL 参数传过去不也可以吗？

Answer 6

请求时token不会被自动带上，cookie会被自动带上；但是如果token存储在cookie里也会被劫持的啊。token只是身份认证是否合法，都放header里除非https防报文拦截，也只能做到传输的安全。

Answer 7

看了大家的回答，又去查了一下，写一下自己的理解，如果哪里不对，还请大家指正~ 谢谢~

cookie

cookie可以存一些用户信息。因为 HTTP 是无状态的，它不知道你有没有登陆过。故可以通过cookie里的信息解决无状态的问题。

而浏览器，会自动带上请求同域的cookie。（AJAX 不会自动携带cookie）

token

后端把用户信息和其他内容放进去，通过 jwt 生成 token，返回给前端。
浏览器是不会自动携带 token。

CSRF 跨站点请求伪造

通过浏览器会自动携带同域cookie的特点。cookie的传递流程是用户在访问站点时，服务器端生成cookie，发送给浏览器端储存，当下次再访问时浏览器会将该网站的cookie发回给服务器端

• 如果用户登陆了A网站，拿到了cookie，又点击了恶意的网站B。
• B收到请求以后，返回一段攻击代码，并且发出一个请求给网站A。
• 浏览器会在用户不知情的情况下，根据B的请求，带着cookie访问A。

由于HTTP是无状态的，A网站不知道这个请求其实是恶意网站B发出的，就会根据cookie来处理请求，从而执行了攻击代码。

而浏览器不会自动携带 token，所以不会劫持 token。

XSS

跨站脚本工攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或者JavaScript进行的一种攻击。

就是说，cookie和token都可能被拿到，所以都废了。

Answer 8

自我观点,不对请指出!!!谢谢~~
token为什么不能被劫持呢????前提是你是jwt的话,一般 都是放入sessionStorage中的,为什么不可以劫持呢?cookie还存在http only,Storage并不存在.所以我认为,jwt只是针对请求的安全性,并不在意你的token的安全.毕竟token的安全,那是后端属于jwt的加密算法,有效性验证了.后端要保证jwt的有效时限限制,刷新策略,比较策略等.那你要是说,不是我前端发的都要被过滤,那你总不能还不让人模拟请求吧???那你真要有这种需求,那你就加个白名单等的策略呗.
那再回到题目上:cookie 和 token 都存放在 header 中,为什么不会劫持token?
首先,cookie的劫持只是不在http only下,js篡改或其他脚本非法获取,还有就是cookie会被浏览器每次请求都会携带在header中,这也就是csrf攻击的来源.然而,传统的b/s web开发,都是用session 来做状态标识,而session id都会默认存在cookie中,浏览器每次都会携带cookie.

Answer 9

XSS跨站脚本攻击 利用的是用户对指定网站的信任，CSRF跨站请求伪造 利用的是网站对用户浏览器的信任。当用户(被攻击者)登录网站时就会执行这些恶意代码，通过这些脚本可以读取cookie,session tokens。所以对于XSS而言，token也没用。
所以这个问题应该是对于跨站请求伪造CSRF而言的。

Answer 10

1攻击者通过xss拿到用户的cookie然后就可以伪造cookie了。
2或者通过csrf在同个浏览器下面通过浏览器会自动带上cookie的特性
在通过 用户网站-攻击者网站-攻击者请求用户网站的方式 浏览器会自动带上cookie
但是token
1 不会被浏览器带上 问题2 解决
2 token是放在jwt里面下发给客户端的 而且不一定存储在哪里 不能通过document.cookie直接拿到，通过jwt+ip的方式 可以防止 被劫持 即使被劫持 也是无效的jwt

原问题是 #32 （在本问题的语境下，token 默认存储在js自定义http head上）
用问题一

1攻击者通过xss拿到用户的cookie然后就可以伪造cookie了。

来说明token比cookie安全并不成立。
都成功的xss了，我拿cookie干嘛，我直接插入脚本，都能直接在用户浏览器里面发ajax请求了（token也要存在页面上），管他token,cookie,都得完蛋。

但是问题二是成立的，对比token,cookie不安全的地方在于会被浏览器自动带上，所以crsf攻击才管用。

所以问题并不成立，在xss攻击面前，token 和 cookie 都凉了。

是csrf哦

Answer 11

cookie：登陆后后端生成一个sessionid放在cookie中返回给客户端，并且服务端一直记录着这个sessionid，客户端以后每次请求都会带上这个sessionid，服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie拿到了sessionid后，就可以完全替代你。

token：登陆后后端不返回一个token给客户端，客户端将这个token存储起来，然后每次客户端请求都需要开发者手动将token放在header中带过去，服务端每次只需要对这个token进行验证就能使用token中的信息来进行下一步操作了。

xss：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

csrf：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

csrf例子：假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="<http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman>">
如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

上面的两种攻击方式，如果被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。

以上面的csrf攻击为例：

• cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作。
• token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作。

这是个人理解的为什么只劫持cookie不劫持token的原因。

“token：登陆后后端不返回一个token给客户端”，多了个“不”字？

Answer 12

服务端下发token,客户端需要存储本地,在需要token的请求中带上发给后端.
储存策略设计不当,攻击者还是可以写脚本(XSS)获取token,进而进行CSRF攻击.

Answer 13

分享一篇文章，讲如何防止CSRF攻击。
https://tech.meituan.com/2018/10/11/fe-security-csrf.html

Answer 14

1、token防止为了防止CSRF，防止频繁请求一种手段，验证码当然也可以；
2、CSRF攻击利用浏览器会自动带上会话信息劫持，token属于安全上流程判断；

Answer 15

题目可能有点问题，在劫持面前，不管cookie还有token，都能劫持。

只是说： cookie会自动携带上，而token需要设置header才可。

具体说一下xss层面的劫持和csxf层面的劫持：

xss: 劫持cookie或者localStorage，从而伪造用户身份相关信息。前端层面token会存在哪儿？不外乎cookie localStorage sessionStorage,这些东西都是通过js代码获取到的。解决方案：过滤标签<>,不信任用户输入， 对用户身份等cookie层面的信息进行http-only处理。

csxf：是后端过于乐观的将header区的cookie取到（所以这才是主要原因，不是因为会自动携带cookie所以不安全，是后端代码不安全而已），并当作用户信息进行相关操作。解决方案也很简单，对于cookie不信任，对每次请求都进行身份验证，比如token的处理。

所以说，不管cookie token都能劫持，对开发者而言，做好这两种攻击即可。

Answer 16

cookie：登陆后后端生成一个sessionid放在cookie中返回给客户端，并且服务端一直记录着这个sessionid，客户端以后每次请求都会带上这个sessionid，服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie拿到了sessionid后，就可以完全替代你。

token：登陆后后端不返回一个token给客户端，客户端将这个token存储起来，然后每次客户端请求都需要开发者手动将token放在header中带过去，服务端每次只需要对这个token进行验证就能使用token中的信息来进行下一步操作了。

xss：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

csrf：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

csrf例子：假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="<http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman>">
如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

上面的两种攻击方式，如果被xss攻击了，不管是token还是cookie，都能被拿到，所以对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别了。

以上面的csrf攻击为例：

• cookie：用户点击了链接，cookie未失效，导致发起请求后后端以为是用户正常操作，于是进行扣款操作。
• token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的token验证不会通过，所以不会进行扣款操作。

这是个人理解的为什么只劫持cookie不劫持token的原因。

Answer 17

我可以把token放在body中啊.
我也可以不用token这个关键字.
主要还是cookie会被浏览器自动带上, 劫持了才容易攻击.

Answer 18

1、首先token不是防止XSS的，而是为了防止CSRF的；
2、CSRF攻击的原因是浏览器会自动带上cookie，而浏览器不会自动带上token

--该题终结--

Answer 19

1攻击者通过xss拿到用户的cookie然后就可以伪造cookie了。
2或者通过csrf在同个浏览器下面通过浏览器会自动带上cookie的特性
在通过 用户网站-攻击者网站-攻击者请求用户网站的方式 浏览器会自动带上cookie
但是token
1 不会被浏览器带上 问题2 解决
2 token是放在jwt里面下发给客户端的 而且不一定存储在哪里 不能通过document.cookie直接拿到，通过jwt+ip的方式 可以防止 被劫持 即使被劫持 也是无效的jwt

原问题是 #32 （在本问题的语境下，token 默认存储在js自定义http head上）
用问题一

1攻击者通过xss拿到用户的cookie然后就可以伪造cookie了。

来说明token比cookie安全并不成立。
都成功的xss了，我拿cookie干嘛，我直接插入脚本，都能直接在用户浏览器里面发ajax请求了（token也要存在页面上），管他token,cookie,都得完蛋。

但是问题二是成立的，对比token,cookie不安全的地方在于会被浏览器自动带上，所以crsf攻击才管用。

所以问题并不成立，在xss攻击面前，token 和 cookie 都凉了。