token可以被截获吗_token被拦截

最近有一位之前找过币牛牛的用户问了我们小编的一个问题，我相信这也是很多币圈朋友经常会疑惑的问题：token可以被截获吗相关问题，token被拦截相关问题，带着这一个问题，让专业的小编告诉您原因。

token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。

客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。

解决这个问题的一个简单办法

1、在存储的时候把token进行对称加密存储，用时解开。

2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。

这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。话说加密存储一个你要是被人扒开客户端看也不会被喷明文存储……

方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。

但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。

于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。

话说一个人连自己手机都保护不好还谈什么安全……

在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在post body里。

区别在于：

登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

客户端向服务器第一次发起登录请求（不传输用户名和密码）。

服务器利用RSA算法产生一对公钥和私钥。并保留私钥， 将公钥发送给客户端。

客户端收到公钥后， 加密用户密码，向服务器发送用户名和加密后的用户密码； 同时另外产生一对公钥和私钥，自己保留私钥, 向服务器发送公钥； 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。

服务器利用保留的私钥对密文进行解密，得到真正的密码。 经过判断， 确定用户可以登录后，生成sessionId和token， 同时利用客户端发送的公钥，对token进行加密。最后将sessionId和加密后的token返还给客户端。

客户端利用自己生成的私钥对token密文解密， 得到真正的token。

对于测试同学来说，计算机网络的基础知识是必不可少的，话不多说，先来整理一波高频网络面试题。

包括GET，POST ，PUT，DELETE，HEAD，OPTIONS，PATCH，TRACE ， CONNECT 等9种方法，常用的为前四种

1、请求效率。GET比POST的请求效率更高。GET产生一个TCP数据包，POST产生两个TCP数据包（划重点，最重要的区别）

2、安全性。Get是不安全的，在传输过程中，数据被放在请求的URL中，POST相对安全，将请求数据放在body中，但是通过抓包也是可以获取到参数的，想要真正的安全，需要用HTTPS的加密协议

3、传输数据量。GET请求数据大小受限于URL长度（1024字节），POST请求数据不受限制

4、使用场景。GET主要从服务器上获取数据，例如查看新闻功能，POST主要用于向服务器提交数据，例如用户登录功能

1XX。信息，服务器收到请求，需要请求者继续执行操作

2XX。成功，操作被成功接收并处理

3XX。重定向，需要进一步的操作以完成请求

4XX。客户端错误，请求包含语法错误或无法完成请求

5XX。服务器错误，服务器在处理请求的过程中发生了错误

200 OK ：服务器成功处理了请求

301 Moved Permanently（重定向）：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302 Found：临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

304 Not Modified：未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

400 Bad Request：客户端请求有语法错误，不能被服务器所理解

401 Unauthorized：请求未经授权。例如访问未经授权的页面

403 Forbidden：服务器收到请求，但是拒绝提供服务。例如访问被禁止的网站目录

404 Not Found ：请求资源不存在。例如：输入了错误的URL

500 Internal Server Error：服务器遇到错误，无法给请求提供服务

基于Token的身份验证流程：

1、客户端使用用户名uid和密码pwd去请求登录

2、服务端收到请求，将uid用一个算法例如（HMAC-SHA256算法） 秘钥（只有自己知道）去做签名sign，然后把这个签名sign和数据uid一起作为Token， 发送给客户端，服务端不保存Token

3、客户端收到 Token 以后把它存储起来，比如放在 Cookie 或者 Local Storage 里

4、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token

5、服务端收到请求，然后去验证客户端请求里面带着的 Token（即用uid按照同样的算法，将算出的结果与请求带过来的Token核对），如果验证成功，就向客户端返回请求的数据

基于Session的身份验证流程：

1、客户端使用用户名uid和密码pwd去请求登录

2、服务端收到请求，会生成一个会话标识Sessionid，即一个随机字符串，发送给客户端。每个用户登录都会生成一个，对服务器是一个巨大的开销

3、客户端收到Sessionid 以后可以把它存储起来，比如放在 Cookie 里

4、客户端每次向服务端请求资源的时候需要带着服务端返回的 Sessionid

5、服务端收到请求，然后去验证客户端请求里面带着的Sessionid，如果与保存在服务端的相同，就向客户端返回请求数据

三者的区别：

1、Cookie是客户端保存数据的一种手段，而Session是服务端保存数据的一种机制，Session保存在服务端内存中，机器重启之后就没有了，Token和Session均是一种身份认证机制

2、主要比较Session和Token机制的优缺点，Token的身份验证机制应用更普遍，优点如下：

A、无状态，可拓展

无状态：即程序需要验证每一次请求，从而辨别客户端的身份

可拓展：在服务端的内存中使用Session存储登录信息，伴随而来的是可拓展性问题，使用Token可以更好的拓展，同时节省了服务器的开销。把Token写到http请求头中，以保证Http请求的无状态。例如有多台服务器，使用负载均衡，第一次登录转发到了A，A中seesion缓存了用户的登录信息，第二次登录转发到了B，这时候就丢失了登录状态，当然这样也是有解决方案可以共享session，但token只需要所有的服务器使用相同的解密手段即可

B、支持移动设备

当客户端是原生平台时，cookie不被支持，可采取Token方式

C、跨程序调用

避免了跨域资源共享的问题

D、安全（防止csrf攻击）

签名校验机制。Session是基于Cookie进行用户识别的, Cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击,一般将Token写到HTTP请求头中。

举个csrf（即跨站点请求伪造）攻击的例子：

原理：（1）同一浏览器同一域名下的cookie可共享，跨域的不能携带cookie（2）httponly，后端开启关闭，开启之后，本地js读不到cookie的字段，不开启才能读到cookie的字段

在A项目中，先登录A项目，然后在构造的js文件中，加一个跳转至A项目的链接（比如做删除操作），A项目是没有加Token校验的，从js文件直接跳转至A项目，携带cookie，可做删除操作,加了Token校验之后，就无法进行删除操作了

从上而下：

1、应用层

为操作系统或网络应用程序提供访问网络服务的接口。

包含的主要协议：FTP（文件传送协议）、Telnet（远程登录协议）、DNS（域名解析协议）、SMTP（邮件传送协议），POP3协议（邮局协议），HTTP协议（Hyper Text Transfer Protocol）

2、表示层

表示层的数据转换包括数据的加密、压缩、格式转换等

3、会话层

负责建立、管理、终止进程之间的会话

4、传输层

传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题

包含的主要协议：TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报协议）

5、网络层

负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能

包含的主要协议：IP协议（Internet Protocol，因特网互联协议）、ICMP协议（Internet Control Message Protocol，因特网控制报文协议）、ARP协议（Address Resolution Protocol，地址解析协议）、RARP协议（Reverse Address Resolution Protocol，逆地址解析协议）

6、数据链路层

为网络层提供可靠的数据传输

包含的主要协议：以太网协议

7、物理层

确保原始的数据可在各种物理媒体上传输

目前我觉得中行是相对而言几大行里最安全的。我自己有中行和工行的网银。中行网银登陆和支付的时候都要输电子口令的数字，这个即使你电脑被盗了资料 你的口令牌又没丢 别人用不了啊~~工行的登录网银就不会核这个，直接就是用户名密码，所以我都不敢放很多钱。。。。

在设置中调整。

1、首先打开苹果手机设置，选择HTTPS选项卡。

2、其次选中DecrptHTTPStraffic，Fiddler就可以截获HTTPS请求。

3、然后打开网络代理设置，获取抖音的ip地址，命令行中输入，ipconfig，获取ip地址。

4、最后无线局域网找到你的网络连接，打开HTTP代理，就可以抓包抖音token。

粗略地分析， 登录机制主要分为登录验证、登录保持、登出三个部分。登录验证是指客户端提供用户名和密码，向服务器提出登录请求，服务器判断客户端是否可以登录并向客户端确认。 登录认保持是指客户端登录后， 服务器能够分辨出已登录的客户端，并为其持续提供登录权限的服务器。登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

上述简易的登录验证策略存在明显的安全漏洞,需要优化。

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

再仔细核对上述登录流程， 我们发现服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端。

1.3 TOKEN失效

用户登录出系统

失效原理：

在服务器端的redis中删除相应key为session的键值对。

App因为要实现自动登陆功能，所以必然要保存一些凭据，所以比较复杂。

App登陆要实现的功能：

这里判断时间，主要是防止攻击者截取到加密串后，可以长久地利用这个加密串来登陆。

不用AES加密，用RSA公钥加密也是可以的。AES速度比RSA要快，RSA只能存储有限的数据。

相信经过币牛牛小编对token可以被截获吗和token被拦截的介绍，你对token可以被截获吗了解更加地透彻了，感谢你对我们地支持与关注！