Ajax 在内部网络上提供对我的自托管web api的internet访问。安全威胁？

首先，我对Web API/CORS和安全实现比较陌生

这个问题特别涉及安全问题。Web API包含极其敏感的数据，并为客户端提供在线执行事务的能力

背景：

• 我有一个Web API作为windows服务自托管，具有固定端口
• Web API位于内部网络上的防火墙/DMZ后面
• Web API（使用CORS）只允许来自外部服务器的流量
• 外部服务器使用IIS托管我们的网站
• Web API使用令牌身份验证（绑定到客户端IP以避免hi劫持）
• 外部网站和内部Web API都强制使用SSL

问题是：

网页通过javascript对web API进行ajax调用。然而，Web API并没有直接向internet公开

• 使用以下设置会对安全性产生什么影响
• 通过这样做，我也会暴露我的网络有哪些漏洞
• 有没有更好的方法来实现这样的设置

乙二醇

• 用户输入

  https://test.mydomain.com

  进入浏览器并提供一个页面

• ajax调用被调用到

  https://test.mydomain.com/api/test/action

• 外部服务器路由<代码>https://test.mydomain.com/api发送到内部服务器的消息

  https://myInternalWebAPI/api/test/action

  不向公众公开

---

所以这需要一点腿部工作，但它是在生产环境中实现的，所以我想我会分享解决方案

我创建了一个WCF服务和一个WebAPI

主WCF服务驻留在内部网络上，包含所有业务逻辑、数据库连接。 代理WebAPI模仿WCF服务结构，并向公众公开

---

代理WebAPI从客户端（javascript）调用，然后代理WebAPI调用承载WCF服务的内部服务器，瞧，victory。

这是一篇关于保护公共REST Web服务的伟大文章（IMO）：@EkoostikMartin感谢这个链接，但是，我已经在设计中使用了95%的实践。我的问题是，网络管理员是否愿意将已经受到保护的ajax流量转发到内部WebAPI，因为您实际上已经过火了（尽管我想这不是一件坏事）。DMZ中的Web服务器需要与DMZ之外的应用服务器通信，这在最简单的系统之外是不可避免的。这通常不是软件架构师需要担心的，而是网络/安全管理员需要担心的。例如，如果您使用基于IP地址的基于令牌的身份验证，则不确定为什么在内部服务器上需要HTTPS。除了现有的“安全性”（端口隔离、代理、AD）之外，应用程序的安全性由我负责，到目前为止，他们还没有很好地适应允许服务等端口的要求，并且在访问其网络方面受到了极大的限制。HTTPS的后续操作仅仅是为了确保端点之间的通信是安全的。过分的实现方式是简化产品的安装（他们的想法）。反向代理是的，但这也是一个网络工程师的事情。让它变得如此简单。我想和你一样吗？