RESTful服务最佳实践——（十一）

安全服务器

确认给定的请求是从服务已知的某人（或者某个系统）给出的，且请求者是他自己所声明的那个人，这样的过程叫做认证。然而授权却是去确认请求者得到了执行被请求的操作的允许。

本质上，这个过程是像这样的：

1. 客户端发出一个指令，在X-Authentication头中包含认证令牌，或者在请求中包含令牌查询串参数。
2. 服务器证实了授权令牌的存在，使其生效（有效且未过期），并且基于内容去分析或者加载认证主体。
3. 服务器会对授权服务发出调用，该服务提供认证主体、被请求资源和必要的操作许可。
4. 如果授权通过了，服务器将会继续正常运行。

以上的第三步可能会需要大的代价，但是假设有一个可缓存的权限控制列表（ACL），那么在发出远程请求前，在本地创建一个授权客户端来缓存最新有效未过期的ACL将是可能的。

身份验证

当前的最佳实践是使用OAuth身份验证。强烈推荐OAuth2，但是它仍处于草稿状态。OAuth1绝对是一个可以接受的选择。某些情况下三条腿的OAuth也是可以选择的。阅读更多关于OAuth的规范：

http://oauth.net/documentation/spec/

OpenID是另一个选择。然而建议将OpenID作为一个额外的选项，使用OAuth为主。阅读更多关于OPenID的规范：

http://openid.net/developers/specs/

传输安全

所有的认证都应该使用SSL。OAuth2需要授权服务器和访问令牌证书使用TLS。在HTTP和HTTPS之间切换引入安全弱点，最佳实践是所有通讯默认使用TLS。

授权

为服务授权与为任何应用程序授权，实际上没有任何不同。它是基于一个问题：“这个主体是否具有给定资源的必要许可？”给定简单的三项数据（主体，资源和许可），很容易构造一个支持这种概念的授权服务。其中主体是被授予资源访问许可的人或系统。使用这些通用概念，就可以有一个用于每一个主体的缓存访问控制列表（ALC）。

应用程序安全性

对RESTful服务来说，开发一个安全的web应用适用同样的原则。

• 在服务器上验证所有输入。接受“已知”的友好输入并且拒绝坏的输入。
• 防止SOL和NoSQL注入。
• 输出使用已知库（如微软Anti-XSS或OWASP AntiSammy）编码的数据。
• 将消息大小限制在确切的字段长度内。
• 服务应该只显示通用的错误消息。
• 考虑业务逻辑攻击。例如，攻击者可以跳过多步骤的订购流程，订购产品而无需输入信用卡信息吗？
• 记录可以活动。

RESTful 的安全注意事项：

• 验证数据的JSON和XML格式。
• 动词应该被限制在允许的方法中。例如，GET请求不能删除一个实体。一个GET将读取实体而DELETE删除实体。
• 意识到竞争条件（资源竞争）。
  API网关可用于监视、节流和控制对API的访问。以下可以由网关或RESTful服务实现。
• 使用API的监视用途可以知道什么活动是友好的，什么是正常使用模式以外的东西。
• 节流API的使用，使恶意用户不能删除一个API端点（DOS攻击），并且有能力阻止恶意IP地址。
• 在加密的安全密钥库中存储API密钥。

---

原文如下

Securing Services

Authentication is the act of verifying that a given request is from someone (or some system) that is known to the service and that the requestor is who they say they are. While authentication is the act of verifying a requestor is who they say they are, authorization is verifying the requestor has permission to perform the requested operation.

Essentially, the process goes something like this:

1. Client makes a request, including authentication token in X-Authorization header or token query-string parameter in the request.
2. Service verifies presence of the authorization token, validates it (that it’s valid and not expired) and parses or loads the authentication principal based on the token contents.
3. Service makes a call to the authorization service providing authentication principal, requested resource and required permission for operation.
4. If authorized, service continues with normal processing.

The above third could be expensive, but assuming a cacheable access-control list (ACL), it is conceivable to create an authorization client that caches the most-recent ACLs to validate locally before making remote calls.

Authentication

Current best practice is to use OAuth for authentication. OAuth2 is highly recommended, but is still in draft state. OAuth1 is definitely an acceptable alternative. 3-Legged OAuth is also an option for certain cases. Read more about the OAuth specification at http://oauth.net/documentation/spec/.

OpenID is an additional option. However, it is recommended that OpenID be used as an additional authentication option, leveraging OAuth as primary. Read more about the OpenID specification at http://openid.net/developers/specs/.

Transport Security

All authentication should use SSL. OAuth2 requires the authorization server and access token credentials to use TLS.

Switching between HTTP and HTTPS introduces security weaknesses and best practice is to use TLS by default for all communication.

Authorization

Authorization for services is not really any different than authorization for any application. It’s based on the question, “Does this principal have the requested permission on the given resource?” Given that simple trifecta of data (principal, resource, and permission), it’s fairly easy to construct an authorization service that supports the concepts. Where Principal is the person or system who is granted a permission on a resource. Using those generic concepts, it is possible to have a cacheable access control list (ACL) for each principal.

Application Security

The same principles in developing a secure web application holds true for RESTful services.

• Validate all input on the server. Accept “known” good input and reject bad input.
• Protect against SQL and NoSQL injection.
• Output encode data using known libraries such as Microsoft’s Anti-XSS or OWASP’s AntiSammy.
• Restrict the message size to the exact length of the field.
• Services should only display generic error messages.
• Consider business logic attacks. For example could an attacker skip through a multi-step ordering process and order a product without having to enter credit card information?
• Log suspicious activity.

RESTful Security Considerations:

• Validate JSON and XML for malformed data.
• Verbs should be restricted to the allowable method. For example, a GET request should not be able to delete an entity. A GET would read the entity while a DELETE would remove the entity.
• Be aware of race conditions.

API gateways can be used to monitor, throttle, and control access to the API. The following can be done by a gateway or by the RESTful service.

• Monitor usage of the API and know what activity is good and what falls out of normal usage patterns.
• Throttle API usage so that a malicious user cannot take down an API endpoint (DOS attack) and have the ability to block a malicious IP address.
• Store API keys in a cryptographically secure keystore.