黑客怎么攻击token,黑客怎么攻击服务器

摘要： 大家好，今天小编关注到一个比较有意思的话题，就是关于黑客怎么攻击token的问题，于是小编就整理了2个相关介绍黑客怎么攻击token的解答，让我们一起看看吧。APP服务端接口，用j...

大家好，今天小编关注到一个比较有意思的话题，就是关于黑客怎么攻击token的问题，于是小编就整理了2个相关介绍黑客怎么攻击token的解答，让我们一起看看吧。

1. APP服务端接口，用jwt还是用redis和token，分别有什么优势？
2. 完全不使用cookie是否就可以防御CSRF攻击？

***服务端接口，用jwt还是用redis和token，分别有什么优势？

都可以，通常情况下正式点我会用shiro+redis实现权限session认证管理，免去了自己实现session认证的过程，并且它还提供了一些进阶的功能。简陋点的话，redis+token就可以了，要自己去设计实现，通常配合***实现session认证。

jwt是生成和校验解密token的工具，redis是缓存，他们之间并不冲突，加起来一起用效果更好，仅仅用token是不够的，因为一但设置token意味着其登录过期时间也就确定了。就无法让其在有效期内失效，这样不合理的。。所以可以通过redis记录token，控制其的有效性，和记录一些信息。所以 token加redis才是正确的选择。

以下内容纯手打：jwt 是json web token 的缩写，所以简单讲jwt只是token的一个标准实现，至于为什么要把redis和token结合起来用，是因为token仅存储于客户端，相对于服务端是无状态的，服务端通过标准的解密，实现对token的验证以及获取必要的payload。此时如果需要方便的对客户端进行强制下线或者实现单客户端登录则需要知道当前已经连接了多少客户端，有多少可用的token，这里就借助了redis存储，同时token在服务端也就变成了有状态了，所以请根据具体的使用场景决定是否配合redis等数据库工具

首先，***端，服务端，是一种典型的前后端分离的数据交换架构。前端（***）通过token从后端服务取数据，后端通过校验token，判断是否给前端（***）返回数据。楼主对jwt的认知不对，下边对这两种进行下说明。

jwt本身就是一个token，token的一种实现不过这个token自带一些用户权限信息。本身是一种无状态的设计概念，后端加密解密判断jwt本身是否过期有效，后端不存储任何跟token存储有关的东西，只有一套加密生成，解密校验的程序。

redis和token，redis是一个缓存数据库，可以存档token，可以设置过期时间。楼主所理解的应该是服务端通过redis存储token，然后前端***带着token进行访问的时候，服务端从redis中取token用来校验，如果过期说明token失效，也可能是伪造token。

最后，两者可以结合使用。

Jwt是带有签名的客户身份令牌。安全性还是比较高的。但是需要正确使用。它本身主要是证明客户身份，并不包含机密信息。如果需要避免重复使用，可以提供时间戳，可以一次性使用。这样很多安全问题就都解决了。现在很多服务都使用jwt认证。

完全不使用cookie是否就可以防御CSRF攻击？

首先可以明确的告诉你，完全禁用Cookie可以有效避免CSRF攻击，但是不能保证完全防御CSRF攻击。

CSRF攻击是“跨站请求伪造”的英文单词缩写，它本质上是利用某种“漏洞”在用户已登录的应用上执行非本意（不知情）的操作，说得通俗点就是用户虽然登录了某个系统，但某个操作并不是用户自己发出的请求，而是攻击者代为发出的（冒充用户做了某个操作）。

CSRF攻击其实是利用了Web系统对客户端浏览器的信任导致的（源于Web隐式身份验证机制），根源上还是Web应用系统对于请求没做严格校验。

1、客户端用户已登录Web应用并生成了Cookie存储在浏览器中；

2、该Cookie没有过期，而且用户在新窗口访问了发起攻击请求的网页。

Cookie只是一种会话机制，和服务器端的Session配合使用的。像现在的Token验证机制不会用到Cookie，但如果攻击者拿到了Token依旧可以发起CSRF攻击。所以说禁用Cookie只能最大限度避免CSRF攻击，但不能完全避免此类攻击。

CSRF攻击其实比较难防，但我们可以通过多种技术手段来规避此类攻击。

1、服务器端要验证请求来源

服务器端对于请求的Referer字段要做初步校验，如果是站外请求则拒绝。但是Referer请求头是可以伪造的，所以不能全信。

到此，以上就是小编对于黑客怎么攻击token的问题就介绍到这了，希望介绍关于黑客怎么攻击token的2点解答对大家有用。