安全的RESTful API,可以被Web App(angular),iOS和Android使用

我必须制定一个计划来开发可供我们未来的Web应用程序(Angularjs)和移动应用程序(iOS / Android)使用的RESTful API(Python / Flask)。

我一直在研究三天,并且遇到了几种情况:使用HTTPS是在下面的方法之上的一个方法,以保持它的安全。 但是https速度较慢,这可能意味着我们需要更快,更昂贵的服务器。

  1. 使用Basic-Http-Auth并通过线路发送用户名/密码(通过https),以便向API发送每个请求。
  2. 使用摘要authentication,这是一个哈希的密码和跟踪将是自动的这将工作的networking应用程序,但我不能确认如果iPhone和Android会原生支持。 如果他们这样做,这可能是一个简单的解决scheme!
  3. 使用一个自定义的http头,在成功的身份validation后,我会在http头中发送一个自定义的Authstring。 但是,我必须确保我发送此用户的每个请求的validation码。 这使得它完全像1),不同之处在于不使用简单密码,并且authentication码可以在没有任何风险的情况下过期。 另外问题是跟踪auth代码,这不再是自动化的,如2)
  4. 使用OAuth是一个选项。 但是它很难build立起来。 如果没有更好的办法,也许这是唯一的办法?
  5. 按照这篇伟大的文章所描述的,像Amazon S3那样保护API。 简而言之,他说服务器和客户端都知道一个私钥,他们将使用这个私钥来散列通信。 这就像stream氓握手,如果他知道歹徒握手,你只会信任送货员。 进一步下面的评论有人问:

如何保持私钥“安全”在一个纯粹的HTML5应用程序?

你完全正确; 在纯HTML5(JS / CSS / HTML)应用程序中,没有保护关键字。 您将通过HTTPS进行所有通信,在这种情况下您不需要密钥,因为您可以使用标准API_KEY或其他一些友好标识符安全地标识客户端,而无需HMAC的复杂性。

换句话说,首先使用Web应用程序的方法是没有意义的。 说实话,我不明白这应该如何在移动设备上工作。 用户下载我们的应用程序,我如何将私钥从iPhone发送到服务器? 我转会的那一刻,就会受到损害。

我越是越研究我所得到的越优越。

我希望能问一些以前做过这些的专业人士,并分享他们的经验。 非常感谢

Solutions Collecting From Web of "安全的RESTful API,可以被Web App(angular),iOS和Android使用"

你似乎把两个不同的概念混淆在一起。 我们开始谈论encryptionstream量(HTTPS),然后我们开始讨论pipe理authentication会话的不同方式。 在安全的应用程序中,这些不是相互排斥的任务。 对于会话pipe理如何影响身份validation,似乎也可能存在误解。 基于此,我将提供Web应用程序/ Web API会话pipe理,身份validation和encryption的入门。

介绍

会话pipe理

HTTP事务默认是无状态的。 HTTP没有指定任何方法来让你的应用程序知道一个HTTP请求已经从一个特定的用户(已validation或没有)发送。

对于健壮的Web应用程序,这是不可接受的。 我们需要一种方法来将多个请求中的请求和数据关联起来。 为此,在向服务器的初始请求中,用户需要被分配“会话”。 通常会话有一些独特的ID发送到客户端。 客户端发送每个请求的会话ID,服务器使用每个请求中发送的会话ID来正确地为用户准备一个响应。

记住“会话ID”可以被称为许多其他事情是很重要的。 这些的一些例子是:会话令牌,令牌等。为了一致性,我将使用“会话ID”为这个回应的其余部分。

来自客户端的每个HTTP请求都需要包含会话ID; 这可以通过很多方式来完成。 stream行的例子是:

  1. 它可以存储在一个cookie中 – 当前域的cookie会在每个请求中自动发送。
  2. 它可以在URL上发送 – 每个请求都可以在URL上发送会话ID,不build议,因为会话ID将留在客户端历史logging
  3. 它可以通过HTTP头发送 – 每个请求将需要指定头

大多数Web应用程序框架都使用Cookie。 然而,依赖于JavaScript和单页devise的应用程序可能会select使用HTTP标头/将其存储在服务器可以观察到的其他位置。

记住通知客户端其会话ID和包含会话ID的客户端请求的HTTP响应是完全纯文本并且是100%不安全的,这一点非常重要。 为了对抗,所有的HTTPstream量都需要encryption。 那就是HTTPS进来的地方。

指出我们还没有谈到在我们的系统中将会话链接到特定的用户也很重要。 会话pipe理只是将数据关联到访问我们系统的特定客户端。 客户端可以处于已authentication状态和未authentication状态,但是在两种状态中,他们通常都有一个会话。

authentication

身份validation是我们将会话链接到系统中特定用户的地方。 这通常是由用户提供凭证的login过程处理的,这些凭证是经过validation的,然后我们将会话链接到系统中的特定用户logging。

用户又通过访问控制列表和访问控制条目(ACL和ACE)与细粒度访问控制权限关联。 这通常被称为“授权”。 大多数系统总是有authentication和授权。 在一些简单的系统中,所有经过身份validation的用户都是平等的,在这种情况下,您将不会通过简单身份验 关于这个问题的进一步的信息超出了这个问题的范围,但考虑阅读关于ACE / ACL。

特定的会话可以被标记为以不同的方式表示经过validation的用户。

  1. 他们的会话数据存储在服务器端可以存储他们的用户ID /一些其他标志,表示该用户被authentication为特定用户
  2. 另一个用户令牌可以发送到客户端,就像会话ID一样(对于未encryption的HTTP,它与发送未encryption的会话ID一样不安全)

任何一个选项都可以。 它通常归结于您正在使用的技术以及默认提供的function。

客户端通常启动authentication过程。 这可以通过发送凭据到特定的URL(例如yoursite.com/api/login)来完成。 但是,如果我们想成为“RESTful”,我们通常会引用某个名词的资源,并执行“创build”的操作。 这可以通过向yoursite.com/api/authenticatedSession/请求凭证的POST来完成。 那里的想法是创build一个authentication的会话。 大多数网站只是张贴证书到/ api /login之类的。 这与“真正的”或“纯粹的”RESTful理想背道而驰,但大多数人认为这是一个更简单的概念,而不是将其视为“创buildauthentication会话”。

encryption

HTTPS用于encryption客户端和服务器之间的HTTPstream量。 在依赖经过身份validation和未经身份validation的用户身份的系统上,所有依赖用户身份validation的stream量都需要通过HTTPS进行encryption; 这是没有办法的。

其原因是,如果你authentication一个用户,与他们分享一个秘密(他们的会话ID等),然后开始用简单的HTTP来游览这个秘密,他们的会话可以被中间人攻击劫持。 黑客会等待stream量通过观察的networking,并窃取秘密(因为它的纯文本通过HTTP),然后启动一个假装成为原始客户端的服务器的连接。

人们解决这个问题的一种方法是将请求远程IP地址与经过validation的会话相关联。 这是无效的,因为任何黑客都能伪造他们的请求远程IP地址在他们的假请求,然后观察你的服务器回送的回应。 大多数人会认为,除非您正在追踪历史数据并使用它来识别特定用户的login模式(如Google),否则这个function甚至不值得实施。

如果您需要在HTTP和HTTPS部分之间分割您的站点,则HTTP通信不必发送或接收会话标识或任何用于pipe理用户身份validation状态的标记。 非HTTP请求/响应中不发送敏感应用程序数据也很重要。

在Web应用程序/ API中保护数据的唯一方法是encryption您的stream量。

你的主题一一

基本-HTTP-AUTH

  • validation:是
  • 会话pipe理:否
  • encryption:否

这是一种仅通过networking资源进行身份validation的方法。 基本authentication通过URL标识的资源authentication使用。 这是Apache HTTP Web服务器最常用的基于.htaccess的目录/位置authentication。 凭证必须随每个请求一起发送; 客户端通常为用户透明地处理。

其他系统可以使用基本身份validation作为身份validation模式。 但是,使用Basic-Http-Auth的系统提供身份validation和会话pipe理,而不是Basic-Http-Auth本身。

  • 这不是会话pipe理。
  • 这不是encryption; 内容和凭证几乎是100%纯文本
  • 这不保证应用程序的HTTP请求/响应的内容。

文摘-validation

  • validation:是
  • 会话pipe理:否
  • encryption:否

这与Basic-Http-Auth完全相同,只是增加了一些简单的MD5消化。 这个消化不应该依赖而不是使用encryption。

  • 这不是会话pipe理。
  • 这不是encryption; 文摘很容易被打破
  • 这不保证应用程序的HTTP请求/响应的内容。

OAuth的

  • validation:是
  • 会话pipe理:否
  • encryption:否

OAuth只是让你有一个外部服务validation凭据。 之后,由您来pipe理/处理authentication请求的结果给您的OAuth提供商。

  • 这不是会话pipe理。
  • 这不是encryption; 您的网站stream量仍然是纯文本。 由于HTTPS限制,身份validation过程将是安全的,但您的应用程序仍然是脆弱的。
  • 这不保证应用程序的HTTP请求/响应的内容。

stream氓握手 / 自定义HTTP头

  • 身份validation:是,可能
  • 会话pipe理:是,可能
  • encryption:否

“自定义HTTP标题”是一种“stream氓握手”; 因此我会用同一部分来讨论。 唯一的区别是“自定义HTTP标头”指定了hanshake(会话id,令牌,用户authenticationtoke等)的存储位置(即在HTTP标头中)。

需要注意的是,这些并不指定如何处理authentication,也没有指定如何处理会话pipe理。 它们基本上描述了会话id /authentication令牌如何以及在哪里存储。

身份validation需要由您的应用程序或通过第三方(如OAuth)处理。 会话pipe理仍然需要实施。 有趣的是,如果你愿意,你可以select合并两者。

  • 这不是encryption; 您的网站stream量仍然是纯文本。 如果您使用OAuth,身份validation过程将受到HTTPS限制,但您的应用程序仍然存在漏洞。
  • 这不保证应用程序的HTTP请求/响应的内容。

你需要做什么

…我强烈build议您确保您明白,一个强大的安全Web应用程序需要以下内容:

  1. encryption(HTTPS几乎是你唯一的select)
  2. 会话pipe理
  3. authentication/授权

授权依赖于authentication。 身份validation依赖于会话pipe理和encryption确保会话没有被劫持,并且凭证不被拦截。

烧瓶login

我想你应该看一下烧瓶login作为一种避免重新实施车轮的方式。 我个人从来没有使用它(我使用金字塔的python Web应用程序)。 不过,我曾经在web应用程序/ python板子中看到过它。 它处理authentication和会话pipe理。 通过HTTPS扔你的网页api /应用程序,你有三个(encryption,会话pipe理和用户authentication)。

如果你没有/不能使用flask-login,准备写你自己的,但是首先要研究如何创build安全的authentication机制。

如果可能的话,如果你不懂如何编写authentication程序,请不要在没有先了解黑客如何使用基于模式的攻击,定时攻击等情况下进行尝试。

请encryption您的stream量

…越过这个想法,你可以避免使用一些“聪明”的令牌使用HTTPS。 移过去的理念,你应该避免使用HTTPS /encryption,因为“它的速度慢”,进程密集型等。它是一个过程密集型,因为它是一种encryptionalgorithm。 确保用户数据和应用程序数据安全的需求始终是您的首要任务。 你不想经历通知你的用户他们的数据被入侵的恐惧。

https是慢的,但不是没有。 只有握手较慢。 对于我们来说,最大的问题是维护服务器端的密钥对和权利。 我们也实施了一个消息摘要。 问题是:很难正确设置php-android-ios版本。 这样做之后(一个参数需要改变什么build议谷歌首先结果只在android端)问题将与低端设备:多CPU使用率,解密encryption过程缓慢,比https要慢很多,特别是当你需要转换10kb的string(可能需要几分钟)。

如果我不把Nasa的数据转移到哈马斯,那么我会用简单的HTTP进行简单的encryption:比如反转比特…

去用HTTPS。 它(稍微)慢一些,但是从相对较短的投资时间(购买SSL证书,并将URL从http更改为https)获得的安全性是值得的。 如果没有使用HTTPS,用户的会话就有可能在不安全的公共networking上被劫持,这对于某人来说非常容易 。