SSL:如何平衡API性能与安全性?

发布于 2024-10-03 01:51:45 字数 305 浏览 2 评论 0原文

安全性很差的 API 很常见。例证 - 此报道

这就引出了一个问题,当涉及到 SSL 时,如何平衡安全性和性能?显然,用户名和密码等敏感信息应通过 SSL 发送。如果后续调用可能使用 API 密钥呢?当涉及需要身份证明的 API 调用时,什么时候可以使用未加密的连接?

APIs with terrible security are common place. Case in point - this story on TechCrunch.

It begs the question, how do you balance security with performance when it comes to SSL? Obviously, sensitive information such as usernames and password should be sent over SSL. What about subsequent calls that perhaps use an API key? At what point is it okay to use an unencrypted connection when it comes to API calls that require proof of identity?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

又爬满兰若 2024-10-10 01:51:45

如果允许混合内容,那么中间人可以重写混合内容以注入 JS 来窃取页面中已有的敏感信息。
由于咖啡馆等提供免费无线访问,中间人攻击并不是那么困难。

https://www.eff.org/pages/how-deploy-https- Correctly 给出了很好的解释:

当通过以下方式托管应用程序时
HTTPS,不能有混合内容;
也就是说,页面中的所有内容都必须
通过 HTTPS 获取。常见的是
请参阅网站上的部分 HTTPS 支持,位于
主要页面是通过以下方式获取的
HTTPS,但部分或全部媒体
元素、样式表和 JavaScript
页面中的内容是通过 HTTP 获取的。

这是不安全的,因为尽管
主页加载受到保护
主动和被动网络攻击,
其他资源都不是。如果一个
页面加载一些 JavaScript 或 CSS 代码
通过 HTTP,攻击者可以提供
虚假、恶意代码文件并采取
一旦页面加载,就会覆盖页面的 DOM。
然后,用户将返回到
没有安全感的情况。这
这就是为什么所有主流浏览器都会发出警告
关于加载混合页面的用户
内容。参考也不安全
通过 HTTP 传输图像:如果攻击者怎么办
交换了保存消息和删除消息
网络邮件应用程序中的消息图标?

您必须提供整个申请
通过 HTTPS 的域。重定向 HTTP
带有 HTTP 301 或 302 的请求
对等效 HTTPS 的响应
资源。

If you allow mixed content, then a man-in-the-middle, can rewrite mixed content to inject JS to steal sensitive information already in the page.
With cafés and the like providing free wireless access, man-in-the-middle attacks are not all that difficult.

https://www.eff.org/pages/how-deploy-https-correctly gives a good explanation:

When hosting an application over
HTTPS, there can be no mixed content;
that is, all content in the page must
be fetched via HTTPS. It is common to
see partial HTTPS support on sites, in
which the main pages are fetched via
HTTPS but some or all of the media
elements, stylesheets, and JavaScript
in the page are fetched via HTTP.

This is unsafe because although the
main page load is protected against
active and passive network attack,
none of the other resources are. If a
page loads some JavaScript or CSS code
via HTTP, an attacker can provide a
false, malicious code file and take
over the page’s DOM once it loads.
Then, the user would be back to a
situation of having no security. This
is why all mainstream browsers warn
users about pages that load mixed
content. Nor is it safe to reference
images via HTTP: What if the attacker
swapped the Save Message and Delete
Message icons in a webmail app?

You must serve the entire application
domain over HTTPS. Redirect HTTP
requests with HTTP 301 or 302
responses to the equivalent HTTPS
resource.

长亭外,古道边 2024-10-10 01:51:45

问题在于,在不了解应用程序性能的情况下,尝试在没有指标的情况下优化应用程序是错误的。这就是导致开发人员决定让 API 不加密的原因,只是认为它可以再争取 10 毫秒的性能。简而言之,平衡安全问题与性能的最佳方法是首先考虑安全问题,从真实客户那里获取一些负载(而不是某些架构师痴迷的白板简笔画),并在您怀疑性能可能是一个问题时从代码中获取真实指标。问题。我有一种奇怪的感觉,这与安全无关。

The problem is that without understanding the performance of your application it is just wrong to try and optimize the application without metrics. This is what leads to decisions by devs to leave an API unecrypted simply thinking it's eeking out another 10ms's of performance. Simply put the best way to balance security concerns versus performance is to worry about security first, get some load from real customers(not whiteboard stick figures being obsessed over by some architect) and get real metrics from your code when you suspect performance might be an issue. I have a weird feeling that it won't be security related.

夜深人未静 2024-10-10 01:51:45

在采取行动之前,您需要收集一些有关 SSL 所谓性能问题的证据。你可能会得到很大的惊喜。

You need to gather some evidence about the alleged performance issues of SSL before you leap. You might get quite a surprise.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文