加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > PHP教程 > 正文

php – REST API身份验证:如何防止中间人重放?

发布时间:2020-12-13 16:52:36 所属栏目:PHP教程 来源:网络整理
导读:我正在编写REST API,并希望实现类似于AWS的身份验证系统. http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html 基本上,在AWS上,客户端使用客户端和服务器之间共享的密钥对一些请求数据加密Authorization标头. (授权:AWS用户:) 服务器
我正在编写REST API,并希望实现类似于AWS的身份验证系统.

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

基本上,在AWS上,客户端使用客户端和服务器之间共享的密钥对一些请求数据加密Authorization标头. (授权:AWS用户:)

服务器使用密钥使用共享密钥解密标头,并与请求数据进行比较.如果成功,这意味着客户端是合法的(或者至少拥有合法密钥).

下一步可以是执行请求,或者最好是向客户端发送一个唯一的,基于时间的令牌(例如:30分钟),该令牌将用于实际请求(例如,添加到令牌头).客户端无法解密此令牌(使用仅服务器密钥).

在下一个请求中,服务器检查令牌(不再是授权)并授权执行请求.

但是,即使在SSL加密的连接上,是否可以重放这些经过令牌验证的请求?即使MITM不知道消息中的内容,他/她也可能造成损害,例如通过多次订购产品.如果服务器收到重播消息并且令牌仍在有效时间戳内,则服务器将认为这是有效请求并执行它.

AWS尝试使用时间戳要求解决此问题:

A valid time stamp (using either the HTTP Date header or an x-amz-date
alternative) is mandatory for authenticated requests. Furthermore,the
client timestamp included with an authenticated request must be within
15 minutes of the Amazon S3 system time when the request is received.
If not,the request will fail with the RequestTimeTooSkewed error
code. The intention of these restrictions is to limit the possibility
that intercepted requests could be replayed by an adversary. For
stronger protection against eavesdropping,use the HTTPS transport for
authenticated requests.

但是,15分钟仍然足以让重播请求,不是吗?在这种情况下,可以采取哪些措施来防止重放攻击?或者我是否过度思考,如果你提供足够的机制,一定程度的不确定性是可以接受的?

我正在考虑要求客户端在每个请求主体上添加一个唯一的字符串.此字符串将被传输加密,MITM无法进行修改.在第一次收到时,服务器将记录此字符串并拒绝在同一上下文中包含相同字符串的任何新请求(例如:两个POSTS被拒绝,但POST和DELETE都可以).

编辑

谢谢(你的)信息.似乎我需要的是cnonce.在维基百科图上,似乎只发送了一次cnon,然后生成一个令牌,让它可以重用.我想有必要在每次调用时使用相同的令牌发送新的cnonce. cnonce应该包含在主体上(受传输保护)或共享密钥保护并包含在标头中.身体保护似乎是最好的(具有明显的SSL),因为它避免了双方的一些额外处理,但它可以被共享密钥加密并包含在头部(很可能被添加到临时令牌).服务器可以直接在主体上读取它或从头部解密(额外处理).

解决方法

你提到的独特字符串 Cryptographic nonce确实是一种很好的安全措施.它将阻止重复使用请求.每个请愿书都应该是独一无二的,与其性质无关.

包括时间戳并丢弃在某个到期日期之后发出的所有请求也是一种很好的做法.保持使用的nonce注册表简短,并有助于防止冲突.

nonce注册表应与用户关联,以防止冲突.消费者应该使用cryptographically secure pseudorandom number generators.

如果使用伪随机数生成器的可预测种子,例如microtime,则可能发生两种令人讨厌的事情.

>随机数可能变得可预测.虽然如果通信是加密的,这不是一个问题,因为他们会无法修改请求,因此无法篡改nonce.>可能会丢弃同一用户的合法请求.对于例如,如果共享身份验证密钥的两台服务器试图这样做两个不同的“后”动作同时发生,随机数可能会发生碰撞.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读