java - 如何保护来自最终用户浏览器的 api 调用中的合作伙伴凭据

Question

团队，

我有一个要求，比如我必须支持我的合作伙伴(第三方)门户通过使用其浏览器中的凭据进行 api 调用来直接调用我们。

e.g.) Partner portal browser makes AJAX Call with below:

      URL      ---> https://example.com/request
      HEADER   ---> user_id   : foo
      HEADER   ---> password  : mypasswd
      payload  ---> {
                       "request_time" : 2232876435,
                       "request_name" : "get_user_info",
                       ...
                       ...
                    }

他们的浏览器/门户可由不受信任的用户访问/使用。所以现在的问题是因为调用是来自前端的；最终用户可以轻松地检查浏览器以查看网络 API 调用以及我们向合作伙伴提供的在我们这边授权的凭据。

因此，我计划向合作伙伴提出建议，要求他们加密门户后端服务器中的有效负载和 header ，并在门户中呈现加密信息，如下所示。

Encrypt (payload)   using mypasswd.
Encrypt (password)  using request_time  <NOW OPTIONAL TO PASS>

现在，

e.g.) URL      ---> https://example.com/request
      HEADER   ---> user_name : foo
      HEADER   ---> password  : ENCRYPTED<mypasswd>  <-- OPTIONAL
      payload  ---> ENCRYPTED< 
                       {
                       "request_time" : 2232876435,
                       "request_name" : "get_user_info",
                       ...
                       ...
                       } 
                    >

因此，在我们的系统中，我们将使用为 user_id foo 检索到的 mypasswd 来解密有效负载。因此，如果解密成功，则该请求来自有效资源。

现在最终门户用户无法理解浏览器检查的请求。

注释:

1. 我无法建议我的合作伙伴从他们的后端调用电话。
   
2. 从请求负载中，我可以通过唯一的事务 ID 识别重复的相同请求，因此他们无法重新提交相同的请求。从而避免重放攻击。

问题:

Q1)此解决方案有任何缺陷或建议吗？
Q2)在java中是否可以通过密码判断解密是否成功？我是加密新手，您能否分享任何代码或链接来实现此目的？

你的想法对我来说很有值(value)。

总而言之:

引用文献:

基本加密详细信息

https://blog.storagecraft.com/5-common-encryption-algorithms/

https://www.veracode.com/blog/research/encryption-and-decryption-java-cryptography

https://gooroo.io/GoorooTHINK/Article/13023/The-difference-between-encryption-hashing-and-salting/2085#.W2L_KdgzZD0

Java 加密

How to encrypt and decrypt String with my passphrase in Java (Pc not mobile platform)?

Java Security: Illegal key size or default parameters?

通过此异常判断解密成功:

Given final block not properly padded

Answer 1

编辑:我误解了这个问题。如果信息在到达最终用户之前由第三方加密，那么这种方法通常是安全的。重放攻击是需要注意的主要问题。如果发出的请求是幂等的，那么您实际上不需要担心，但否则您可能需要为已用 token 实现一个短期数据库以及到期时间或类似的东西。

<小时/>

您解决这个问题的方法是错误的。让最终用户代表第三方向您发出此请求是愚蠢的 - 如果请求来自他们的浏览器，那么根据定义，他们控制他们发送的信息及其发送方式。加密无法解决此问题，因为加密逻辑也是客户端。

解决这个问题的方法是消除最终用户。该请求应直接由第三方发送给您。这可能来自最终用户向第三方 API 发出请求，也可能不是 - 这并不重要。