所有文章 > API安全 > API签名及加密方式详解
API签名及加密方式详解

API签名及加密方式详解

API在使用的时候往往都会有一些签名加密之类的东西,那么具体来说都有什么加密方式?签名方式又有啥呢?来看看API签名及加密方式详解,今天我们从专业的角度来进行全面解析,从技术角度对API的签名方式,加密方式等进行详解。

那么在文章开始之前呢,我们可以先来看看API集成管理,这个API集成管理平台集成管理是指在一个组织中管理和协调不同API的使用、开发和维护的过程。API允许不同的软件应用之间进行通信,从而实现数据和服务的共享。有效的API集成管理对于确保系统之间的顺利交互、提升开发效率以及保障数据安全至关重要,所以我非常推荐使用这个平台,可以更好的提高安全性。

下面开始解析API签名和加密方式

HTTP 简单身份认证

在 HTTP 请求的 Header 中添加认证字段例如:

Authorization: 3F2504E04F8911D39A0C0305E82C3301

服务器处理前取出该字段进行校验即可。

Spring Boot 直接实现一个拦截器可进行判断:

<span class="hljs-type">String</span> <span class="hljs-variable">token</span> <span class="hljs-operator">=</span> request.getHeader(<span class="hljs-string">"Authorization"</span>);
<span class="hljs-keyword">if</span> (!Strings.isNullOrEmpty(token)) {
hasAuth = redisTemplate.hasKey(<span class="hljs-string">"userToken:"</span> + token);
}

这类方法实现比较简单,可以做基本的身份认证,防君子不防小人,可通过中间人攻击获得 Authorization。使用 HTTPS 安全性会得到提高,但是无法抵御重放攻击造成的影响,例如 DDOS,我们这里来分析一下会遭受什么攻击?怎么实现攻击手法

中间人攻击(MITM)

在非加密的HTTP连接上,任何在网络路径上的攻击者都可以截取和读取请求和响应的内容。这意味着如果Authorization头包含的是纯文本的用户名/密码组合或者是一个静态令牌,攻击者可以轻松地获取这些信息,并在后续的请求中重用它们来冒充合法用户。

重放攻击(Replay Attack)

即使使用HTTPS来加密通信,静态的认证令牌仍然容易受到重放攻击。在这种攻击中,攻击者不是截取和解密数据,而是简单地记录下一次成功的认证请求,然后重复发送这个请求来访问资源。这是因为静态令牌在一段时间内保持不变,所以攻击者可以多次使用同一个令牌

API签名认证流程

Part 1: 请求端加密

请求端加密是说,比如我对你说话,那么我是请求端,是我这里说话的时候进行加密,把我说的话加密一下再说给你,而你是服务端

  1. 秘钥分发:服务器向API使用者提供一对密钥,即AK(Access Key)和SK(Secret Key)。AK是公开的,而SK需要保密,因为它是用于生成签名的密钥。
  2. 签名规则
    • HTTP Header:请求头中包含AK,这允许服务器验证请求来自已注册的用户。
    • 参数排序与拼接:对于GET请求,所有参数按照key进行字典排序,并拼接成字符串;对于POST请求,根据不同的Content-Type进行相应处理。
    • 签名计算:使用HMAC-SHA256算法,以SK作为密钥,对拼接后的字符串进行签名,然后将签名结果base64编码。
  3. 请求构造:将X-Ca-Key(即AK)和X-Ca-Signature(即签名)添加到HTTP请求头中,一同发送至服务器。

看一下下面的图

Part 2: 服务器端验证

刚才我说道服务端是你,请求端是我,还用这个举例子,我把话说给你之后然后你是服务端,我加密了,说给你的话是加密的,这时候你需要验证并解密我说的话才行,那么是服务端解密和验证

  1. 验证AK:服务器收到请求后,首先检查请求头中的AK,确认请求者身份。
  2. 重新计算签名:服务器使用相同的算法和SK重新计算签名,以验证请求的完整性和一致性。
  3. 比较签名:将计算出的签名与请求头中的签名进行对比。如果匹配,则认为请求有效;如果不匹配,则拒绝请求,因为可能存在数据篡改或非授权访问。

防御重放攻击

主要防的是你burpsuite抓包重放,有了这个验证你想着通过bp抓包重放进行攻击,抱歉不可能了,因为会验证和加密,你抓包后在放包的时候会出现验证不过,会丢弃你那个包,到最后实现防御你这个攻击。API签名机制可以通过加入时间戳和nonce(一次性随机数)来进一步增强安全性,以防御重放攻击。时间戳和nonce都会被包含在签名计算中,且每个请求的时间戳和nonce都应该唯一。服务器会检查时间戳,确保请求没有过期,并且会跟踪nonce,以避免处理重复的请求。

为了提高安全性,通常会结合使用timestamp(时间戳)和nonce(一次性随机数),以防止重放攻击(replay attack)。下面我进行全面的讲解

Timestamp 和 Nonce 的作用

  • Timestamp:这是请求发出的时刻,通常精确到毫秒。服务器会检查这个时间戳,如果与当前时间相差超过预设的阈值,认为请求过期,不予处理。这有助于防止攻击者捕获旧的请求并稍后重放,这个时间戳大家学过linux应该知道,不是单纯一个时间而是一长串数字,可以转换时间,用这个验证也是说双方必须用标准时间,不能出现时间误差,不然可能出现第一次请求验证不过,因为两个人时间不一样,所以需要用到ntp时间服务器同步时间。
  • Nonce:这是一个随机数,每次请求都不同。服务器会存储最近收到的nonce,当接收到新的请求时,会检查这个nonce是否已经被使用过。如果nonce是新的,那么请求被认为是有效的;如果nonce已经存在,那么这可能是一个重放攻击。

使用Timestamp和Nonce的挑战

  • Nonce的存储:随着请求量的增加,服务器需要存储越来越多的nonce,这可能导致内存压力。通常,使用如Redis这样的键值存储系统来管理nonce,它可以设置过期时间(TTL),这样旧的nonce会自动被删除。

API签名与HTTPS的关系

我们讲到这里会有人询问,这个API签名加密和https是不是一回事?直接用https加密不行了还搞那么麻烦那么多事情干嘛?抱歉,这里我要说的是,不是一个概念,甚至这两个东西不是同样的东西,https是传输层的一个加密,和API签名不在同一层,我来进行一下解析。

  • HTTPS:提供了传输层的安全,确保数据在网络上传输时不会被窃听或篡改。但是,HTTPS本身并不提供对请求的验证或重放攻击的防护所以只是单单用一个https加密不太行,还得增加API签名。
  • API签名:在应用层上保证了请求的完整性和来源的真实性,防止数据被篡改,同时也可以防止重放攻击。

结合HTTPS和API签名,可以提供更全面的安全保障,既保护了数据在传输过程中的安全,也确保了到达服务器的请求是合法且未被篡改的。在实际部署中,这是推荐的做法,尤其对于涉及敏感数据和交易的API。

作者:幻城

#你可能也喜欢这些API文章!