重放攻击及防御方案

什么是重放攻击

  所谓重放攻击就是攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程。

  攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器。从这个解释上理解,加密可以有效防止会话劫持,但是却防止不了重放攻击。重放攻击任何网络通讯过程中都可能发生。

  重放攻击的类型

  根据消息的来源:

  协议轮内攻击:一个协议轮内消息重放

  协议轮外攻击:一个协议不同轮次消息重放

  根据消息的去向:

  偏转攻击:改变消息的去向

  直接攻击:将消息发送给意定接收方

  其中偏转攻击分为:

  反射攻击:将消息返回给发送者

  第三方攻击:将消息发给协议合法通信双方之外的任一方 

重放攻击是计算机世界黑客常用的攻击方式之一,它的书面定义对不了解密码学的人来说比较抽象。我就通过一个故事来说明它吧!


/故事的分割线/
阿里巴巴和40大盗的故事

人物:

黑客:阿里巴巴
用户:40大盗
系统:宝库
身份认证:石门


故事情节:

话说有一天,40大盗准备把一抢来得珠宝放进他们的宝库里去。
// 用户打算登陆系统

他们来到宝库面前,准备打开石门
// 系统要求身份认证,弹出口令窗口

40大盗的首领对着石门喊道:“芝麻开门”
//用户输入口令“芝麻开门”

不巧这一幕被阿里巴巴看到
//有黑客截获用户的登陆过程

40大盗将宝物放进宝库后,就离开了
//用户退出系统

等40达盗走远后,阿里巴巴来到石门前也大喊“芝麻开门”
//黑客对系统进行了重放攻击  ------------------------------------------------重点:重放攻击

石门打开了,阿里巴巴把宝物都搬回家了
//成功入侵系统

所谓重放攻击就是攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程。
为了抵御重放攻击,现在的身份认证一般采用挑战因答方式。

   用户                        系统
         -----申请登陆----〉

        〈---发送挑战值----

计算相应的应答值
    
         ------发送应答值--〉

                           判断应答值是否正确
      
       〈---通过认证(正确)--

                           不正确断开连接

这里要注意的是挑战值得熵值必须大(变化量要很大),若挑战值变化量不大,攻击者只需截获足够的挑战应答关系,就可以进行重放攻击了。

   
典型例子:

  重放攻击与cookie

  我们监听http数据传输的截获的敏感数据大多数就是存放在cookie中的数据。其实在web安全中的通过其他方式(非网络监听)盗取cookie与提交cookie也是一种重放攻击。我们有时候可以轻松的复制别人的cookie直接获得相应的权限。关于cookie,我想应该用单独的一篇文章来说明,在这里就不重复了。

  重放攻击的防御方案

  (1)时间戳

  “时戳”──代表当前时刻的数

  基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳

  原理──重放的时戳将相对远离当前时刻

  时钟要求──通信各方的计算机时钟保持同步

  处理方式──设置大小适当的时间窗(间隔),越大越能包容网络传输延时,越小越能防重放攻击

  适用性──用于非连接性的对话 (在连接情形下双方时钟若偶然出现不同步,则正确的信息可能会被误判为重放信息而丢弃,而错误的重放信息可能会当作最新信息而接收)

  (2)序号

  通信双方通过消息中的序列号来判断消息的新鲜性

  要求通信双方必须事先协商一个初始序列号,并协商递增方法

   (3)提问——应答

  “现时”──与当前事件有关的一次性随机数N(互不重复即可)

  基本做法──期望从B获得消息的A 事先发给B一个现时N,并要求B应答的消息中包含N或f(N),f是A、B预先约定的简单函数

  原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的

  时钟要求──无

  适用性──用于连接性的对话

 

转至:http://blog.sina.com.cn/s/blog_62d82c2f0100i79r.html

<think>嗯,用户问的是如何防范和解决重放攻击的问题。首先,我需要回忆一下什么是会话重放攻击。根据之前的引用[^1],重放攻击攻击者截获有效的数据传输然后重新发送以欺骗服务器。那防御策略应该包括防止数据被重复使用的方法。 首先,时间戳是个常见的方法。给每个请求加上时间戳,服务器检查时间是否在合理范围内,比如几分钟内。这样可以防止旧的请求被重放。但要注意客户端和服务器的时间同步问题,否则可能会有误判。 然后,随机数(Nonce)应该也是有效的。服务器维护一个已使用随机数的列表,每个请求必须包含唯一的随机数,服务器验证是否重复。不过这样可能会增加存储负担,特别是高并发时。可能需要定期清理过期的随机数。 接下来,数字签名和MAC(消息认证码)可以确保数据完整性。使用HMAC或者数字证书对请求签名,这样即使攻击者截获了数据,没有密钥也无法伪造签名。这需要安全的密钥管理,防止密钥泄露。 序列号方法,每次交互递增序列号,服务器检查序列号是否有效。适用于有状态的协议,但如果是无状态的RESTful API可能不太适用,需要结合其他方法。 HTTPS是必须的,加密传输防止中间人截获数据。TLS协议本身有一些防重放机制,比如使用序列号和记录协议中的时间戳。引用[^2]提到金融行业的数据安全规范,使用HTTPS符合这些标准。 一次性令牌,比如在认证后的每个请求使用一次性token,用过后失效。OAuth 2.0中的机制可以参考,但实现起来可能复杂,需要维护令牌的状态。 业务逻辑层面的防御,比如转账加流水号、验证码、操作确认等,增加用户交互步骤,使攻击者难以自动化重放。 还有,法律法规和标准方面,引用[^2]提到金融行业的相关规范,遵循这些标准可以帮助设计更安全的系统,比如数据分级和加密要求。 综合解决方案可能需要结合多种方法,比如时间戳+随机数+数字签名,同时使用HTTPS和业务层防护。还要注意密钥管理和服务端验证逻辑,避免漏洞。 用户可能需要具体的实现例子,比如如何在代码中添加时间戳和Nonce,或者如何配置HTTPS。另外,可能还需要考虑性能影响,比如Nonce存储的优化,或者时间窗口的选择。 可能的相关问题包括:具体如何实现时间戳验证,Nonce存储的最佳实践,如何选择加密算法,或者金融行业中的具体案例。需要确保回答覆盖这些方面,同时引用提供的参考资料来支持建议的有效性。</think>### 防范重放攻击的解决方案及最佳实践 重放攻击(Session Replay Attack)通过截获并重复发送合法用户的数据包来欺骗系统[^1]。以下是防御重放攻击的核心方法及实践建议: --- #### **1. 时间戳验证** - **原理**:为每个请求附加时间戳,服务端验证请求时间与当前时间的差值是否在允许范围内(例如 ±5 分钟)。 - **实现**: ```python import time def validate_timestamp(client_timestamp): current_time = int(time.time()) return abs(current_time - client_timestamp) <= 300 # 5分钟时间窗口 ``` - **注意点**:需确保客户端与服务端时间同步(如使用NTP协议)。 --- #### **2. 随机数(Nonce)机制** - **原理**:每个请求包含唯一随机字符串(Nonce),服务端记录已使用的Nonce并拒绝重复值。 - **实现**: ```python from redis import Redis redis = Redis() def validate_nonce(nonce): if redis.exists(nonce): return False redis.setex(nonce, 300, "used") # 设置5分钟过期 return True ``` - **优化**:结合时间戳清理过期Nonce,减少存储压力。 --- #### **3. 数字签名与消息认证码(MAC)** - **原理**:使用密钥对请求内容生成签名(如HMAC-SHA256),服务端验证签名合法性。 - **实现**: ```python import hmac def generate_hmac(message, key): return hmac.new(key.encode(), message.encode(), "sha256").hexdigest() def verify_hmac(message, received_digest, key): expected_digest = generate_hmac(message, key) return hmac.compare_digest(expected_digest, received_digest) ``` - **注意点**:密钥需通过安全渠道分发,并定期轮换。 --- #### **4. HTTPS与传输层安全** - **强制使用HTTPS**:TLS协议通过加密和序列号机制天然防御重放攻击。 - **配置建议**: - 启用TLS 1.3,禁用旧版本协议。 - 使用HSTS头强制浏览器加密通信。 --- #### **5. 业务层防御** - **操作唯一性约束**:例如支付场景中,为每笔交易绑定唯一流水号。 - **用户交互验证**:敏感操作需二次确认(如短信验证码、生物识别)。 --- #### **综合方案示例** ```plaintext 1. 客户端生成请求:时间戳 + Nonce + 业务参数 + HMAC签名 2. 服务端验证: - 时间戳是否超时 - Nonce是否已存在 - HMAC签名是否正确 3. 通过后执行业务逻辑并标记Nonce为已使用 ``` --- ### 引用与行业规范 - **金融行业**:遵循《金融数据安全分级指南》要求,对敏感数据传输采用多重验证机制。 - **密钥管理**:使用硬件安全模块(HSM)或KMS服务保护签名密钥。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值