保护 AJAX 使用的 API [英] Securing a API consumed by AJAX

查看:22
本文介绍了保护 AJAX 使用的 API的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 REST JSON API(内置于 .NET),需要由以下客户端(通过 HTTPS)使用:

I have a REST JSON API (built in .NET) that needs to be consumed by the following clients (over HTTPS):

  1. SPA 网站 (AJAX)
  2. 移动应用

一切(API、SPA 网站、移动应用)都在内部.

Everything (API, SPA website, mobile apps) is in-house.

通常对于 API,我会使用基本身份验证,但很明显,一旦您将 API 开放为 AJAX,安全性就会变得棘手.

Usually for an API, i'd go with Basic authentication, but obviously once you open up your API to AJAX, security gets tricky.

关于保护"API 的说明 - 我主要是想阻止抓取工具对 API 进行黑客攻击/攻击,并且数据并不是完全私密的.

A note on "securing" the API - I mainly want to stop scrapers hacking/hammering the API, and the data isn't exactly ultra-private.

以下是我想到的解决方案:

Here's the solutions i have in mind:

  1. 什么都不做.让它保持打开状态,但使用节流/速率限制来阻止我的 API 被抓取.
  2. 创建 AJAX 调用需要经过的中间人服务器.显然,这意味着存在额外的延迟,在代码等方面加倍.
  3. 在客户端/服务器之间使用带有随机数和商定消息格式的 HMAC 身份验证,并且只允许来自一组允许域的 CORS.(是的,我知道 Origin 标头可以被欺骗).

我倾向于选项 3.由于我们使用的是 HTTPS,因此无法嗅探请求,但显然我可以简单地转到 SPA 应用程序,打开 Fiddler 并查看 HMAC 消息,但随机数会停止重放攻击.显然,如果有人有这种倾向,他们可以为 SPA 应用下载 缩小 JS,找到 AJAX 调用发生的位置,并以某种方式找出 HMAC 格式.这是我能看到的唯一缺点.

I'm leaning towards option 3. Since we are over HTTPS the request can't be sniffed, however obviously i can simply go to the SPA app, pop open Fiddler and see the HMAC message, but the nonces will stop the replay attacks. Obviously if someone was that way inclined, they could download the minified JS for the SPA app, find where the AJAX calls happen and somehow figure out the HMAC format. This is the only downside i can see.

我可以就此提供一些建议吗?

Can i please have some advice on this?

谢谢

推荐答案

我认为您有很好的想法来保护您的 Web API.以下是一些额外的想法:

I think that you have great ideas to secure your Web API. Here are some additional thoughts:

  • You should prefer a token-based authentication instead of basic authentication. This allows to add expirations, refresh, ... I wrote an article on this subject: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
  • You should also be careful about possible XSS for SPA if you store security context in it. If you choose to keep basic authentication, it doesn't really apply since the browser keeps this context for you. Here are some links regarding such aspects: What are (if any) the security drawbacks of REST Basic Authentication with Javascript clients? and Is there any safe way to keep rest auth token on the client side for SPA?. Notice that JS frameworks like Angular provides support to prevent from this.
  • Using rate limitation is also a good thing. It will provide a guard for scrapers hacking. You can have a look at what Restlet at this level for advice: http://restlet.com/technical-resources/restlet-framework/guide/2.3/extensions/apispark/firewall.
  • The option 3 is perhaps a bit strong but you could implement a security mechanism like the one (signature-based) used / provided by AWS. It signs the request using an access key identifier (see this link http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html). This class from Restlet could give you hints about the implementation: https://github.com/restlet/restlet-framework-java/blob/master/modules/org.restlet.ext.crypto/src/org/restlet/ext/crypto/internal/AwsUtils.java.

我认为,如果您使用/考虑/实现某些或所有机制,您的 Web API 将获得非常好的身份验证和安全性 ;-)

I think that if you use / consider / implement some or all mechanisms, you will have a pretty good authentication and security for your Web APIs ;-)

希望对你有帮助蒂埃里

这篇关于保护 AJAX 使用的 API的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆