安全性：通过api处理两个应用程序

Question

我有2个应用程序。第一个应用程序（A）有客户端（HTML）和服务器端（RUBY，PHP或其他）。第二个应用程序（B）是一个API。一切都是通过https。请考虑以下情况：

1. 用户在登录框（App A，客户端）中键入电子邮件和密码，然后单击“确定”
2. App A（服务器端）检查CSRF令牌并使用特定于API的HTTP凭证（仅限已知服务器端）向API（App B）发送电子邮件和密码
3. 应用B检查API凭据，然后检查用户凭据（电子邮件和密码）
4. App B回答App A（服务器端）
的一切正常
5. App A为用户创建会话，他可以知道使用该应用程序。有时App A（服务器端）会调用App B来询问某些内容。

它足够安全吗？这是愚蠢的吗？这是一种可接受的方法吗？

Answer 1

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

一些潜在的问题可能是

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

最后，我在这个描述中看不到任何批评。