http传输token会被篡改么的简单介绍

最近有很多小伙伴咨询关于http传输token会被篡改么的问题，小编结合多年的经验整理出来一些对应的资料，分享给大家。

为什么http会被篡改内容，而https不用？

因为HTTP协议是一种明文传输的网络协议。当你在浏览器中输入一个网址希望访问A网站的时候，其实在你的浏览器到达网站服务器的这个传输过程中，会经过很多个中间节点。假如这些中间节点受到了攻击（比如你的路由器）。那么你向服务器所传递的数据信息就会被这些中间节点所篡改。最终返回到你的浏览器中的页面信息就很可能被改变了。中间节点能完成得到数据的原文，那自然就能够进行篡改了。

而HTTPS不同，HTTPS采用了加密的数据传输方式，也就是说数据传输的过程中是以密文的形式传输的，就算中间节点能获取到数据，那也只是密文数据，是无法被篡改。因此HTTPS网站是能够从根本上预防网站劫持的。

鉴权必须了解的 5 个兄弟：cookie、session、token、jwt、单点登录

本文你将看到：

**「前端存储」**这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。

前端的存储方式有很多。

有，cookie。cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。一般过程是这样的：

「配置：Domain / Path」

cookie 是要限制::「空间范围」::的，通过 Domain（域）/ Path（路径）两级。

「配置：Expires / Max-Age」

cookie 还可以限制::「时间范围」::，通过 Expires、Max-Age 中的一种。

「配置：Secure / HttpOnly」

cookie 可以限制::「使用方式」::。

**「HTTP 头对 cookie 的读写」**回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？HTTP 返回的一个 Set-Cookie 头用于向浏览器写入「一条（且只能是一条）」cookie，格式为 cookie 键值 配置键值。例如：

那我想一次多 set 几个 cookie 怎么办？多给几个 Set-Cookie 头（一次 HTTP 请求中允许重复）

HTTP 请求的 Cookie 头用于浏览器把符合当前「空间、时间、使用方式」配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。

**「前端对 cookie 的读写」**前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用document.cookie可以创建、修改 cookie，和 HTTP 一样，一次document.cookie能且只能操作一个 cookie。

调用document.cookie也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。

现在回想下，你刷卡的时候发生了什么？

这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：

**「Session 的存储方式」**显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：

「Session 的过期和销毁」**很简单，只要把存储的 session 数据销毁就可以。****「Session 的分布式问题」**通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。

但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。**「node.js 下的 session 处理」**前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session - npm，用法就不贴了。这是它种的 cookie：

express-session - npm 主要实现了：

session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？

回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。

token 的流程是这样的：

**「客户端 token 的存储方式」 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 「token 的过期」**那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。

编码的方式丰俭由人。**「base64」**比如 node 端的 cookie-session - npm 库

默认配置下，当我给他一个 userid，他会存成这样：

这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb”} 的 base64 而已。 「防篡改」

是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session - npm 库中，增加两项配置：

这样会多种一个 .sig cookie，里面的值就是 {"userid":"abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (System.Security.Cryptography) | Microsoft Docs。

好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。**「JWT」**但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introduction - jwt.io 横空出世了。

它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：

这串东西是怎么生成的呢？看图：

类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 - JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt - npm koa-jwt - npm

token，作为权限守护者，最重要的就是「安全」。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。

有了 refresh token 后，几种情况的请求流程变成这样：

如果 refresh token 也过期了，就只能重新登录了。

session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是「种在 cookie 上、数据存在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。**「客户端存 cookie / 存别地儿」**存 cookie 固然方便不操心，但问题也很明显：

存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。 「服务端存数据 / 不存数据」

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。

简单的，如果业务系统都在同一主域名下，比如wenku.baidu.com tieba.baidu.com，就好办了。可以直接把 cookie domain 设置为主域名 baidu.com，百度也就是这么干的。

比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」

**「完整版本：考虑浏览器的场景」**上面的过程看起来没问题，实际上很多 app 等端上这样就够了。但在浏览器下不见得好用。看这里：

对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：

图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。

谢谢大家哦

http有什么危害？安装https证书可以解决吗？

http的危害：

（1） 窃听风险：第三方可以获知通信内容。

（2） 篡改风险：第三方可以修改通信内容。

（3） 冒充风险：第三方可以冒充他人身份参与通信。

安装https证书是可以解决上述危害的，https传输协议本就是为了保护网站信息传输安全而开发出来的。

token什么意思 前端如何使用token

大家好，从网上找了很多关于token的文章，都是提到要生成一个token，然后前端每次请求的时候，要使用这个token，请问下如何在前端使用生成的token？

前端能就使用jQuery搞定，还是需要其他的前端框架配合？能有这方面的完整示例吗？

做后端的，对前端的东西有些不太懂，请见谅

先谢谢大家了！！

解决方案1:

一般是后端有个结构给你拿token的，然后你请求的时候，根据约定

把token

放在header中

放uri参数中

放body表单里

给后端

解决方案2:

因为http协议是无状态的 token是后台给你发的一个唯一标识 你再去访问后台时带上这个token 后台就知道你是谁了

同session的作用

解决方案3:

前台生成的token，可能会存在安全性问题吧

解决方案4:

你做后台应该很了解token才对呀。

用户登录后，生成一个session_id，即token，可以存在redis里。然后前端或客户端保存起来，存cookie或者LS都行，然后所有的请求作为基类参数带上（也有通过cookie带的），然后server端再取到后，验证你是不是你。

解决方案5:

使用领域很多，以表单为例子：

后台生成token.

前端打印表单,并且讲该token变成隐藏项。input type="hide" value="{{token}}"

客户提交表单。

后台验证提交的token合法性。

验证成功，处理表单。验证失败，返回错误处理页面。

解决方案6:

token一般都是后端生成的，在登陆之后返回，前端保存token，之后每次请求都带上token来验证身份。

解决方案7:

问题是前端生成的token给后台有用吗

解决方案8:

一般token都是服务器端生成，做csrf的。我在补充下我见过前端生成的栗子，虽然没啥卵用，但让我废了好大的劲才发现。

譬如你有一个验证码的表单，你在传递验证码的时候，新增一个隐藏域，将验证码用你本地的js加密后，作为参数传递，这样在服务器端可以检测验证码是不是被篡改过。

但这样没啥卵用，因为在提交的时候用同样的js模拟即可。

解决方案9:

大多数情况下，token作为一种令牌，都是在服务器端生成，生成的方法很多，从简单点的对时间或者id或者两个混合起来进行哈希运算的值到自己设计更复杂的算法都可以，生成的目的是为了给前端下一次通信时使用这个token作为令牌，当作为一个请求资源的许可的标识，而服务器则会视这个token在一段时间内都是有效的，并且还可以额外看情况加上是否是同一个ip之类的其它的限制，从而防止某种资源被非法访问

偶有前端（包括本地客户端或者app）生成token的情况是已经约定好了一个好的加密机制，服务器可以信任客户端的这个输入的情况下可以由前端或者客户端生成

OAuth2.0原理和验证流程分析

第三方授权就是，委托第三方来对既定的用户进行鉴定，鉴定成功之后，下发信任凭证，信任凭证和用户挂钩，同时可以使用此凭证来去第三方平台，获得该用户开放的部分信息.

直白的说，就是将用户授权的工作交给第三方来做，而自己只维护信任凭证，并且获取用户信息。就像我们的QQ和微博一样，你在逛各大论坛的时候，总会有一种途径就是第三方的app登陆。显然这种验证是要在第三方做的，而论坛只需要维护一个token，并且可以获取你的个人信息，然而没什么软用。你如果想用部分功能，还是得注册，因为你相当于论坛只是一个有部分信息的游客，而没有成为它的用户，这种手段可以看成是提高自己访问量或转化率的一种手段吧。其实这种授权方案不一样只用在互联网，部分企业级的网站做资源的共享访问也是这么做的。比如两个网站合作，A站点账户可以登陆B站点，B站点账户可以登陆A站点，这样A站点就能拿到B站点相关资源，反过来也是。就做到了资源共享。

那么这种授权是怎么做的呢？到底安全不安全？那么可能就要引出OAuth协议了。

首先OAuth只是一个授权协议，不是一个实现或是一个中间件。

OAuth1于2007年10月建立，之后又在2009年6月重新修订和发布

OAuth1.0授权流程是什么？

流程很复杂，因为OAuth需要保证授权码和Token在传输的时候不被截取和篡改，所以使用了很多签名反复的验证。

OAuth1.0的问题：

反复的签名，开放平台本来就面对开发者，但是反复的签名导致开发的流程太过于复杂。

没有引入回跳地址的判断，导致会跳可能会篡改，这样授权码和Token会被Hack掉（1.0a的时候修复了这个漏洞）。

授权流程过于单一化。

OAuth2.0的引入：

抽象验证流程

由于OAuth1过于复杂，之后对OAuth进行了改造引入了Oauth2.0。OAuth的授权过程如下：

(A) 客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者，或者间接地通过授权服务器这样的中介，而后者更为可取。

(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。

(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。

(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。

(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。

(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。

上面只是一个抽象的验证流程，根据上面的抽象流程演化出四种验证模式：

授权码模式

授权码模式和上述的 抽象验证模式流程比较相似：

(A) web客户端通过将终端用户的user-agent重定向到授权服务器来发起这个流程。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（借助于user-agent），并确定终端用户是否许可客户端的访问请求。

(C) 假定终端用户许可了这次访问，授权服务器会将user-agent重定向到之前提供的重定向URI上去。授权服务器为客户端传回一个授权码做获取访问令牌之用。

(D) 客户端通过验证并传入上一步取得的授权码从授权服务器请求一个访问令牌。（需要带上ClientId和Secret，ClientId和Secret是通过平台授予）

(E) 授权服务器验证客户端私有证书和授权码的有效性并返回访问令牌。

授权码模式（implicit grant type）

User-Agent子态适用于客户端不能保存客户端私有证书的app（纯客户端app，无Server参与）。因为可纯客户端的程序不能保存密钥

(A) 客户端将user-agent引导到终端用户授权endpoint。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（通过user-agent）并确认终端用户是许可还是拒绝了客户端的访问请求。

(C) 如果终端用户许可了这次访问，那么授权服务器会将user-agent引导到之前提供的重定向URI。重定向URI会在URI片断{译者注：URI片断是指URI中#号之后的内容}中包含访问令牌。

(D) user-agent响应重定向指令，向web服务器发送不包含URI片断的请求。user-agent在本地保存URI片断。

(E) web服务器返回一个web页面（通常是嵌入了脚本的HTML网页），这个页面能够访问完整的重定向URI，它包含了由user-agent保存的URI片断，同时这个页面能够将包含在URI片断中的访问令牌（和其它参数）提取出来。

(F) user-agent在本地执行由web服务器提供的脚本，该脚本提取出访问令牌并将它传递给客户端。

密码模式

密码模式就是将密码托管给第三方app，但是必须要保证第三方app高度可信。

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

客户端模式

这种模式不需要终端用户的参与，只是Client和Server端的交互。通常只用于Client状态的获取。

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

授权流程

这里以授权码方式流程说明，主要流程分为两步，获取授权码和通过授权码获取资源票据：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

A步骤中，客户端申请认证的URI，包含以下参数：

response_type：表示授权类型，必选项，此处的值固定为"code"

client_id：表示客户端的ID，必选项

redirect_uri：表示重定向URI，可选项

scope：表示申请的权限范围，可选项

state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

C步骤中，服务器回应客户端的URI，包含以下参数：

code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。

state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。

code：表示上一步获得的授权码，必选项。

redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

client_id：表示客户端ID，必选项。

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

access_token：表示访问令牌，必选项。

token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。

expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。

refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。

scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

资源访问过程：

此处主要由资源服务方实现，对于access_token进行校验。

token过期刷新过程：

客户端使用“refresh_token”访问许可类型和下列参数传入刷新令牌：

refresh_token：

必需参数。与待刷新的访问令牌相关联的刷新令牌。

grant_type=refresh_tokenclient_id=s6BhdRkqt3client_secret=8eSEIpnqmMrefresh_token=n4E9O119d

授权服务器必须验证客户端私有证书（如果存在），验证刷新令牌是否有效，以及验证资源拥有者的授权是否仍然有效。如果请求有效，授权服务器则发布一个访问令牌响应，原来的Token失效。以后访问必须使用新Token。

OAuth2看上去很美好，但是细心观察其实还是有一些漏洞的。

参考资料：

人人网OAuth历程:

app怎样防止token被盗取

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

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

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

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

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

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

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

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

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

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

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

关于http传输token会被篡改么和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。