api - 安全性:两个应用程序通过 API 进行处理

Question

我有 2 个应用程序。第一个应用程序 (A) 有客户端 (HTML) 和服务器端(RUBY、PHP 或其他)。第二个应用程序 (B) 是一个 API。一切都是通过https。考虑这种情况:

1. 用户在登录框中输入电子邮件和密码(应用程序 A，客户端)，然后点击“确定”
2. 应用 A(服务器端)检查 CSRF token ，并使用特定于 API 的 HTTP 凭据(仅已知服务器端)向 API(应用 B)发送电子邮件和密码
3. 应用 B 检查 API 凭据，然后检查用户凭据(电子邮件和密码)
4. 应用 B 向应用 A(服务器端)回答一切正常
5. 应用程序A为用户创建一个 session ，他可以知道如何使用该应用程序。有时应用程序A(服务器端)会调用应用程序B询问一些事情。

那么它足够安全吗？是不是很傻？这是一个可以接受的方法吗？

Answer 1

看起来还不错。作为攻击者，我会尝试直接伪造一个有效的请求 #2 到 AppB，看看会发生什么。但如果使用服务器端凭据，只要它们不弱，我就不会成功。

一些潜在的问题可能是

1. 暴力破解 - 如果高度安全或高流量，您可能需要考虑使用验证码或任何其他验证码来防止 #1 和 #2 的暴力破解。通常，您不会在前 5-10 次登录中显示验证码/验证，然后您开始要求人们表现得像人一样
2. #3 和 #4 - 确保无法“检查”该用户是否已注册到您的用户池以及(更重要的是)该密码是否有效。信息泄漏或类似的情况可能会帮助攻击者枚举用户或了解电子邮件(您的登录名)是否在您的数据库中，这是任何社会工程攻击的开始。
3. 重放攻击:拦截#2 请求的任何人是否有可能回复服务器？我认为这是错误的，因为您使用 HTTPs。
4. #2 session 时间 - AppA 和 AppB 之间的 session 持续多长时间？通常s2s(系统2系统) channel 没有 session (即AppA始终发送凭证)或无限 session (AppA第一次设置sessionID，并且它将永远持续)。在第二种情况下，至少要确保 session ID 不可重复使用。一次 session 的持续时间大约不应超过一周。
5. SSRF 及类似内容:我们渗透测试 list 中的一项精美新项目。这里没什么特别的，但要确保没有人可以使用 AppA 向 AppB 发出请求 - 例如，如果在 #5 中向 AppB 请求的内容可以由用户控制，那就是一个问题，请清理输入用户。
6. 固定数据包:如果您有非常小的 HTTPs 请求，并且每次都或多或少相同(#2 是一个很好的目标)，那么它们可能会受到诸如 CRIME 和 BREACH 等 HTTPs 攻击的影响。无论如何，这是一个复杂的话题，我只是提到可能性，但是，为了使这些内容适用，有很多事情需要考虑。
7. AppB 的服务器端凭据 - 更新密码:问问自己，如果 AppA 配置文件被盗，更改密码有多难？如果答案是“几乎不可能”，那就是一个关键问题。您应该考虑每 3-6-12 个月更改一次此类密码。

最后，我认为这个描述没有什么关键之处。