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

[blockmood]

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

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

[fengT-T]

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 都凉了。

[lhban108]

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

--该题终结--

[zWingz]

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

[chaijinsong]

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的原因。

[lijiayi01]

题目可能有点问题，在劫持面前，不管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都能劫持，对开发者而言，做好这两种攻击即可。

[Thinking80s]

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

[SiyuanHu]

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

[pagemarks]

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

[ButcherV]

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给客户端”，多了个“不”字？

[Gebiuncle]

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哦

[lanOrage]

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