登录软件防重放攻击_防御web重放攻击

导航：

• 1、防止重放攻击的常用方法
• 2、Web怎样防止重放攻击
• 3、HTTPS如何防止重放攻击？
• 4、HTTPS/TLS是否可以防重放攻击?
• 5、登录移动显示防重放攻击
• 6、http与重放攻击

防止重放攻击的常用方法

1. 加随机数

该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数，就认为是重放攻击。缺点是需要额外保存使用过的随机数，若记录的时间段较长，则保存和查询的开销较大。

2. 加时间戳

该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步，同步越好，受攻击的可能性就越小。但当系统很庞大，跨越的区域较广时，要做到精确的时间同步并不是很容易。

3. 加流水号

就是双方在报文中添加一个逐步递增的整数，只要接收到一个不连续的流水号报文(太大或太小)，就认定有重放威胁。该方法优点是不需要时间同步，保存的信息量比随机数方式小。缺点是一旦攻击者对报文解密成功，就可以获得流水号，从而每次将流水号递增欺骗认证端。

Web怎样防止重放攻击

单独的随机数不能避免重放攻击，随机数一般会和签名加密技术，后台验证技术混合以提高破解和重放难度。

重放攻击（Replay Attacks）又称重播攻击、回放攻击或新鲜性攻击（Freshness Attacks），是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。

从重放攻击的定义上我们可以看到，重放攻击提交给服务器的数据是曾经有效的，如何防止这种数据，对特定信息给与一个特定的随机数，并且这个随机数保存在服务器内，在验证了用户信息前，首先会对随机数进行验证，如果发现提交的随机数和服务器保存的不同则，该条信息无效通过这种方法来防止重放攻击。

常用的防御重放攻击，不会直接暴露随机数，一般随机数会用在MD5，HASH（数字签名）上，比如在对有效值进行MD5加密时添加随机数，如用户名为test，密码为test的MD5加密过程可能为MD5("test","test",随机数)，这样在直接传输时不会暴露出随机值，黑客在提交重放攻击时系统发现MD5签名和系统签名计算后不同则，可被认定为重放攻击。

当然矛和盾是一种存在的，有可能该值刚好又一次的分配给了该用户，可能会重放攻击成功，但这个概率在科学计算上可以被视为0，而且随着随机数的位数的提高，概率会不断降低。

HTTPS如何防止重放攻击？

客户端拼接字符串规则如下：

接口+参数+时间戳+secretID（如果不是做对外开放性的API，是内部产品调用的话那么secretID可以是写死的一个ID值）

将以上字符串用对称加密，作为一个sign参数，请求服务端。

比如接口，login，参数有 name、password、加密后的sign

服务端接收到请求后，用对称解密sign，得到secretID，核对值是否正确，那么说明请求方是可信任的。返回接口结果，并把sign记录到redis。

下次接收到同样请求时发现redis已经有对应的sign值说明是接口重放，不予以正常相应。因为正常用户调用接口时间戳应该是改变的不可能产生同样的sign值。

如果发现sign解释出来的secretID是系统不存在的，那么说明请求方在伪造请求。不予以正常相应。

感谢应邀回到本行业的问题。

在回答这个问题之前我感觉我们因该先了解一个HTTPS。

HTTPS ：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

HTTPS 协议的主要作用可以分为两种： 一种 是建立一个信息安全通道，来保证数据传输的安全； 另一种 就是确认网站的真实性。

工作流程 为：

第一步：客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

第二步：Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

第三步：客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

第四步：客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

第五步：Web服务器利用自己的私钥解密出会话密钥。

第六步：Web服务器利用会话密钥加密与客户端之间的通信。

从其工作流程中，我们看出每个连接都会验证证书，交换密钥。别人就算截获你的数据包，重新发送一遍，因为socket不一样，密钥也不一样，后台解密后应该是一对乱码才对。所以https本身就是防止重放攻击的。

欢迎您的关注和留言评论，您的关注和鼓励才是给我们最大的动力。

HTTPS/TLS是否可以防重放攻击?

tls具有防重放攻击机制。加密，时间戳，每个包要有包序号，每次同向加1，收到重复序号认为是攻击，可以抵御重放攻击。此外借助于HTTPS/TLS其自身机制，保证了消息完整性，并且可以抵御重放攻击。由于加密，对方也无法看到明文内容。

即使无法获取到后台登录信息, 攻击者也可以从网络中获取普通用户的隐秘信息, 包括手机号码, 身份证号码, 信用卡号等重要资料, 导致严重的安全事故。进行网络嗅探攻击非常简单, 对攻击者的要求很低。使用网络发布的任意一款抓包工具, 一个新手就有可能获取到大型网站的用户信息。

HTTP的缺点：

HTTP虽然使用极为广泛, 但是却存在不小的安全缺陷, 主要是其数据的明文传送和消息完整性检测的缺乏, 而这两点恰好是网络支付, 网络交易等新兴应用中安全方面最需要关注的。

关于 HTTP的明文数据传输, 攻击者最常用的攻击手法就是网络嗅探, 试图从传输过程当中分析出敏感的数据, 例如管理员对 Web 程序后台的登录过程等等, 从而获取网站管理权限, 进而渗透到整个服务器的权限。

登录移动显示防重放攻击

系统bug。登陆是一种进入软件的过程，移动显示防重放攻击是系统bug导致的，感兴趣的网友可前往咨询。bug是计算机领域专业术语用来指代计算机上存在的漏洞。

http与重放攻击

HTTP报文在客户端与服务器之间传输的形式是明文，在传输的过程中，HTTP报文会经过很多网络节点，首先是局域网的路由器（例如家庭的路由器），然后是运营商的交换机或路由器，接着到目标服务器所在局域网的路由器，最终到达目标服务器，被它接收。

之所以说HTTP不安全，是因为传输的数据是明文，在客户端与服务器之间传输的过程中，也就是明文经过中间的网络节点时，存在被嗅探的风险。

攻击方式：

（1）在运营商的交换机或路由器上嗅探流量。

（2）WiFi劫持，假WiFi中间人。

HTTPS的 "S" 是 "SSL"，在HTTP的基础上再增加一个协议，这个协议用于协商加密算法，位于传输层与应用层之间，在应用层的数据（例如 HTTP 报文）往下传给传输层之前，SSL对数据进行加密，然后再把密文封装到传输层协议中。

HTTP报文被加密后，即使攻击者在传输过程中捕获到报文，也无法解密成明文。攻击者无法理解报文的内容，也就无法窃取或篡改数据。这就保证了数据的保密性和完整性。

假设网站的前端与后端的通信协议是 HTTP ，在传输用户的登录口令时，可以在传输之前，前端计算口令的 MD5 值，然后再发送给服务器，这样可以尽可能地保证口令被窃取后不被破解。

攻击者可以截获报文，例如一个登录的请求报文，然后再发送一次给服务器，从而成功登录受害者的账号。

要防御这种攻击，可以在请求报文中加一个随机值（或者 salt），这个随机值可以和口令一起计算 MD5 值，也可以用一个独立的参数存储，被请求报文携带，发送到服务器上。在服务器上，也存储相同的随机值，用于验证从客户端发送过来的随机值。

最重要的一点是，这个随机值最好是一次性的，即使用一次就失效。这样的一次性正好挫败了重放攻击的重复性，也就防御了攻击。

我们先来回忆一下HTTPS的通信流程，HTTPS协议 = HTTP协议 + SSL/TLS协议，摘取一下网上一些八股文的回答(以RSA密钥交换的为例)！

画外音: 是不是贼熟悉，有背过网络八股文的，一看就懂！

关键问题就在步骤(6)，怎么进行加密的？很多文章都没有说明，甚至有的人以为，拿client_random+server_random+pre_master_secret直接拼成一个字符串，然后就是对称加密密钥，客户端和服务端拿这个密钥对数据进行加密通信！！

对此，我只能说:"Too young too simple!离谱啊！！"

那正确的过程是怎么样的呢，我们继续往下看！

我先给本文提到的英文单词，给上我的中文翻译，以防大家混淆:

先大致有个印象，继续往下阅读

现在我们已经有三个参数client_random，pre_master_secret，server_random，服务端和客户端分别会根据这三个参数，推导出master_secret，一旦master_secret被推导出来，会立刻删除pre_master_secret。( 摘自rfc2246,section8.1 ）

当master_secret计算出以后，立刻计算key_block( 摘自rfc2246,section6.3 )，这个密钥块，有的文章里又说他是会话密钥！计算公式如下，

如公式所示，PRF是一个Hash算法，如SHA256这些，具体用哪一个取决于TLS协议的版本！我们得到key_block后，可以基于到key_block继续推导出6个密钥值，分别是

整个过程用一张图来说明，注意了这六把密钥是根据key_block推导而出，也就是意味着这六把密钥是服务端和客户端共同持有的！

[图片上传失败...(image-dd960a-1651718824022)]

大家一定也发现了，你的密钥前都带有client或者server前缀，这代表密钥是服务端使用还是客户端使用！例如，客户端用client_write_key进行数据加密，发送数据，服务端收到消息后利用client_write_key进行解密。而后服务端使用server_write_key进行数据加密回复信息，客户端收到消息后用server_write_key解密服务端发来的信息！

OK，我们继续往下看！

现在我们已经有了6把密钥了，已经需要发送的消息data，那么加密流程具体怎么样的呢？

TLS一共有三种加密模式，流加密模式、分组模式、 AEAD 模式，我以流加密模式来进行说明，如下图所示

[图片上传失败...(image-2ae534-1651718824022)]

我们现在来看上面的第二步，利用write_mac_key对数据加密，加上MAC验证码，利用MAC码来保证完整性。

那么，这个MAC验证码的生成公式又是怎么样的呢？

在流加密模式下，MAC验证码公式为( 摘自rfc2246,section6.2.3.1 )

[图片上传失败...(image-f2482f-1651718824022)]

看到入参中的seq_num了么？ 这就是数据的序列号，这个序号就是用来防止重放攻击的！ 那这个序列号怎么用的呢？

假设，此时服务端和客户端连接成功后 (1) 客户端会在内存中记录 client_send 和 client_recv，默认值为0.客户端每发送一条消息，client_send 会加1，每接收一条服务端发来的消息，client_recv 会加1。 (2) 服务端也会在内存中记录 server_send 和 server_recv，作用和客户端的作用一样。服务端每发送一条消息，server_send 会加1，每接收一条客户端发来的消息，server_recv 会加1。 (3) 客户端发送数据时，以当前client_send作为seq_num,计算mac值，发送给服务端，然后client_send加1。 (4) 服务端收到消息后，先以当前server_recv值，进行完整校验，校验成功后server_recv加1。然后以server_send为作为seq_num,计算mac值，发送给客户端，然后server_send加1。 (5) 也就是说，如果发送和接收都正常，那么 client_send = server_recv、client_recv = server_send

假设，客户端和服务端相互通信了4次，client_send = server_recv=3(从0开始，所以是3)，服务端检验完第4次消息后，server_recv加1，此时server_recv=4。攻击者如果想重放第4次消息，第4次消息中的client_send值是3，就会出现校验失败的情况！从而能够抵挡住重放攻击！

OK，讲到这里，基本上能回答最开始提出的问题了！

当然，TLS协议本身的内容比较多，我在这里放上TLS协议的地址，大家有兴趣可以自己去查看:

假设，我们用符号[]表示一次TCP连接，0,1,2,...代表数据包序号，根据上面的分析，对于这种形式的重放攻击，[0,0,0,1,1,2,2,3,3,3….]，HTTPS协议是能够拦截的！

那如果不是一次请求里的重放攻击呢？例如形式是[0,1,2,3….],[0,1,2,3….]，这种形式的重放攻击，HTTPS协议能够拦截么？有答案，可以在留言区进行回复！

提示 :想一想看，最开始的客户端随机数和服务端随机数的作用!

标签：登录软件防重放攻击