PROSAGA码农传奇-区块链扩展技术-保护REST API / Web服务的最佳实践

17 条回复

0#
回复此人
甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 您可能还想看看 <a href="http://oauth.net/" rel="noreferrer"> OAuth的 </A> ，一种新兴的基于令牌授权的开放式协议，专门针对http apis。 </p> <P> 它与采取的方法非常相似 <a href="http://www.flickr.com/services/api/" rel="noreferrer"> Flickr的 </A> 和 <a href="http://www.rememberthemilk.com/services/api/" rel="noreferrer"> 记住牛奶 </A> “休息”apis（不一定是restful apis的好例子，但是基于令牌的方法的好例子）。 </p> </DIV>

编辑
1#
回复此人
明月清风上善若水自由如风 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 除HTTP之外，没有REST标准。那里有成熟的REST服务。我建议你看看他们，并了解他们的工作方式。 </p> <P> 例如，我们在开发自己的S3 REST服务时借用了很多想法。但我们选择不使用基于请求签名的更高级安全模型。更简单的方法是基于SSL的HTTP Basic身份验证。你必须决定什么在你的情况下最有效。 </p> <P> 另外，我强烈推荐这本书 <a href="http://oreilly.com/catalog/9780596529260/" rel="noreferrer"> RESTful Web服务 </A> 来自O'reilly。它解释了核心概念并确实提供了一些最佳实践。您通常可以采用他们提供的模型并将其映射到您自己的应用程序。 </p> </DIV>

编辑
2#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我搜索了很多关于restful ws安全性的信息，我们最终还是使用了令牌从客户端到服务器来验证请求。我使用spring security来授权服务中的请求，因为我必须根据已经在DB中的指定安全策略对每个请求进行身份验证和授权。 </p> </DIV>

编辑
3#
回复此人
無口君 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我对客户端证书尚未提及SSL感到惊讶。当然，只有依靠证书识别的用户社区，这种方法才真正有用。但是许多政府/公司确实向用户发布了这些政府/公司。用户不必担心创建另一个用户名/密码组合，并且在每个连接上建立身份，因此与服务器的通信可以完全无状态，不需要用户会话。（并不意味着所提到的任何/所有其他解决方案都需要会话） </p> </DIV>

编辑
4#
回复此人
❀⚘粉༵红༵回༵忆༵⚘❀ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 对于Web应用程序安全性，您应该查看OWASP（ <a href="https://www.owasp.org/index.php/Main_Page" rel="nofollow"> https://www.owasp.org/index.php/Main_Page </A> ）提供各种安全攻击的备忘单。您可以采用尽可能多的措施来保护您的应用程序。关于API安全性（授权，身份验证，身份管理），已经提到了多种方式（Basic，Digest和OAuth）。 OAuth1.0中存在循环漏洞，因此您可以使用OAuth1.0a（由于担心规范，OAuth2.0未被广泛采用） </p> </DIV>

编辑
5#
回复此人
無口君 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我已经使用了OAuth几次，还使用了其他一些方法（BASIC / DIGEST）。我全心全意地建议OAuth。以下链接是我在使用OAuth时看到的最佳教程： </p> <P> <a href="http://hueniverse.com/oauth/guide/" rel="noreferrer"> http://hueniverse.com/oauth/guide/ </A> </p> </DIV>

编辑
6#
回复此人
一别而尽几念深i | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 这些答案中的每个人都忽略了真正的访问控制/授权。 </p> <P> 例如，如果您的REST API / Web服务是关于POSTing / GETing医疗记录，您可能需要定义访问控制策略，了解谁可以访问数据以及在何种情况下。例如： </p> <UL> <LI> 医生可以获得与他们有关系的患者的医疗记录 </LI> <LI> 没有人可以在练习时间之外发布医疗数据（例如9到5） </LI> <LI> 最终用户可以获得他们拥有的医疗记录或他们作为监护人的患者的医疗记录 </LI> <LI> 护士可以更新与护士属于同一单位的患者的医疗记录。 </LI> </UL> <P> 为了定义和实现这些细粒度的授权，您需要使用一种名为XACML的基于属性的访问控制语言，即可扩展的访问控制标记语言。 </p> <P> 这里的其他标准如下： </p> <UL> <LI> OAuth：id。联邦和授权授权，例如让服务代表我代理另一项服务（Facebook可以发布到我的Twitter） </LI> <LI> SAML：身份联合/ Web SSO。 SAML非常关注用户是谁。 </LI> <LI> WS-Security / WS- *标准：这些标准专注于SOAP服务之间的通信。它们特定于应用程序级消息传递格式（SOAP），它们处理消息传递的各个方面，例如可靠性，安全性，机密性，完整性，原子性，事件......没有覆盖访问控制，所有都是特定于SOAP的。 </LI> </UL> <P> XACML与技术无关。它可以应用于Java应用程序，.NET，Python，Ruby ... Web服务，REST API等。 </p> <P> 以下是有趣的资源： </p> <UL> <LI> OASIS XACML <a href="http://oasis-open.org/committees/tc_home.php?wg_abbrev=xacml"> 网站 </A> </LI> <LI> 该 <a href="http://csrc.nist.gov/projects/abac/"> NIST ABAC标准 </A> </LI> </UL> </DIV>

编辑
7#
回复此人
甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> OWASP（开放Web应用程序安全项目）有一些备忘单，涵盖了Web应用程序开发的所有方面。该项目是非常有价值和可靠的信息来源。关于REST服务，您可以检查： <a href="https://www.owasp.org/index.php/REST_Security_Cheat_Sheet"> https://www.owasp.org/index.php/REST_Security_Cheat_Sheet </A> </p> </DIV>

编辑
8#
回复此人
溪林 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 感谢您的出色建议。我们最终使用自定义HTTP标头将身份令牌从客户端传递到服务，以准备将我们的RESTful API与即将推出的Microsoft的Zermatt Identity框架集成。我已经描述了这个问题 <a href =“http://www.thefreakparade.com/2008/09/flowing-identity-from-a-client-to-a-service-when-using-restful-wcf-part-1-the-problem /“rel =”nofollow noreferrer“> 这里 </A> 和我们的解决方案 <a href =“http://www.thefreakparade.com/2008/09/flowing-identity-from-a-client-to-a-service-when-using-restful-wcf-part-2-a-solution /“rel =”nofollow noreferrer“> 这里 </A> 。我也拿了 <a href="https://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service#7562"> tweakt </A> 的建议并买了 <a href="http://oreilly.com/catalog/9780596529260/" rel="nofollow noreferrer"> RESTful Web服务 </A> - 如果您正在构建任何类型的RESTful API，这本书非常好。 </p> </DIV>

编辑
9#
回复此人
無口君 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> SOAP世界很好地涵盖了安全标准这一事实并不意味着默认情况下它是安全的。首先，标准是的<strong> 非常 </强> 复杂。复杂性不是安全性和实施漏洞的非常好的朋友，例如 <a href="https://ipsec.pl/node/1119" rel="noreferrer"> XML签名包装攻击 </A> 在这里流行。 </p> <P> 至于.NET环境，我不会帮助太多，但是 <a href="http://amzn.to/1auRwqA" rel="noreferrer"> 使用Java®构建Web服务 </A> （约有10位作者的砖块）对我有所帮助 <EM> 很多 </EM> 理解WS- *安全体系结构，特别是它的怪癖。 </p> </DIV>

编辑
10#
回复此人
甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 正如tweakt所说，亚马逊S3是一个很好的模型。他们的请求签名确实具有一些功能（例如合并时间戳），有助于防止意外和恶意请求重放。 </p> <P> HTTP Basic的优点是几乎所有HTTP库都支持它。当然，在这种情况下，您需要使用SSL，因为通过网络发送明文密码几乎是一件坏事。使用SSL时，Basic优于Digest，因为即使调用者已经知道需要凭据，Digest也需要额外的往返来交换nonce值。使用Basic，呼叫者只需在第一次发送凭据。 </p> <P> 一旦建立了客户端的身份，授权实际上只是一个实现问题。但是，您可以使用现有授权模型将授权委派给其他组件。关于Basic的优点还在于您的服务器最终会得到客户密码的纯文本副本，您可以根据需要将其简单地传递到基础架构中的另一个组件。 </p> </DIV>

编辑
11#
回复此人
757461156 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 关于安全性与REST相关的最好的帖子之一已经过去了 <a href="http://1raindrop.typepad.com/1_raindrop/2006/12/rest_security_o.html" rel="noreferrer"> 1 RainDrop </A> 。 MySpace API也使用OAuth来保证安全性，并且您可以完全访问RestChess代码中的自定义通道，我对此进行了大量探索。这是在Mix上演示的，你可以找到帖子 <a href =“http://blogs.msdn.com/vbertocci/archive/2008/03/10/wcf-rest-at-mix08-the-tale-of-myspace-apis.aspx"rel =”noreferrer“ > 这里 </A> 。 </p> </DIV>

编辑
12#
回复此人
木木 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我想添加（与stinkeymatt一致），最简单的解决方案是将SSL证书添加到您的站点。换句话说，请确保您的网址是HTTPS：//。这将涵盖您的运输安全（砰的一声）。使用RESTful url，想法是保持简单（与WS * security / SAML不同），您可以使用 <a href="https://github.com/thinktecture/Thinktecture.AuthorizationServer" rel="nofollow"> oAuth2 / openID连接 </A> 甚至是Basic Auth（在简单的情况下）。但是你仍然需要SSL / HTTPS。请在此处检查ASP.NET Web API 2安全性： <a href="http://www.asp.net/web-api/overview/security" rel="nofollow"> http://www.asp.net/web-api/overview/security </A> （文章和视频） </p> </DIV>

编辑
13#
回复此人
北极星微控 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 这已经有一段时间了，但问题仍然存在，尽管答案可能会有所改变。 </p> <P> API网关将是一种灵活且高度可配置的解决方案。我测试并使用过 <a href="http://getkong.org" rel="nofollow noreferrer"> KONG </A> 相当多，真的很喜欢我所看到的。 KONG提供了自己的管理REST API，您可以使用它来管理用户。 </p> <P> <a href="http://express-gateway.io" rel="nofollow noreferrer"> Express-gateway.io </A> 是最新的，也是一个API网关。 </p> </DIV>

编辑
14#
回复此人
与之 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 由于@Nathan最终得到了一个简单的HTTP标头，有些人说过OAuth2和客户端SSL证书。它的要点是......你的REST API不应该处理安全性，因为它应该超出API的范围。 </p> <P> 相反，应该在其上放置一个安全层，无论它是Web代理后面的HTTP头（一种常见的方法，如SiteMinder，Zermatt甚至是Apache HTTPd），还是像OAuth 2那样复杂。 </p> <P> 关键是请求应该在没有任何最终用户交互的情况下工作。所需要的只是确保与REST API的连接经过身份验证。在Java EE中，我们有一个概念 <code> userPrincipal </code> 可以通过获得 <code> HttpServletRequest </code> 。它还在部署描述符中管理，URL模式可以是安全的，因此REST API代码不再需要检查。 </p> <P> 在WCF世界中，我会使用 <code> ServiceSecurityContext.Current </code> 获取当前的安全上下文。您需要将应用程序配置为要求身份验证。 </p> <P> 我上面的语句有一个例外，那就是使用nonce来防止重放（可能是攻击或只是提交相同数据两次的人）。该部分只能在应用程序层中处理。 </p> </DIV>

编辑
15#
回复此人
取之 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我推荐OAuth 2/3。您可以在以下位置找到更多信息 <a href="http://oauth.net/2/" rel="noreferrer"> http://oauth.net/2/ </A> </p> </DIV>

编辑

登录后才能参与评论