你在使用哪种编程语言?快来投票,亲手选出你心目中的编程语言之王 了解详情
写点什么

REST API 面临的 7 大安全威胁

2019 年 12 月 10 日

REST API面临的7大安全威胁


互联网安全是技术博客和论坛讨论得越来越频繁的一个话题,并且理由充分:近年来,众多引人注目的安全漏洞显著增多。安全性非常重要,特别是在 REST API 领域。


API 安全性是组织希望在未来几年内解决的最大挑战,而安全性挑战的解决很有可能会成为 API 领域增长的催化剂。


根据Jitterbit发布的2018年API集成状况报告


API 正在改变业务


今天,令人印象深刻的是有 64%的组织正在创建用于内部或外部用例的 API。虽然有四分之一的受访者现在根本没有创建 API,但 40%的受访者都利用了内部和外部用例中的 API。


API 的创建和管理由开发人员负责


如今,大多数利用 API 的组织都依赖他们的开发人员来编写和管理这些 API。尽管 33%的受访者使用专门的技术来管理他们的 API,但 90%的受访者依靠他们的开发团队或外部资源从零开始编写 API。


组织已经被越来越多新的云应用程序之间的代码集成压得喘不过气来,它们对开发人员提出更多要求,要求他们为业务创建和管理API


REST API 的安全性

在设计、测试及部署 REST API 时,安全性问题是一个必须要考虑的重要方面。随着 REST API 的飞速发展,在大多数情况下,安全级别在 API 的设计和开发中被低估。目前敏感数据(无论是组织信息还是个人信息)的安全性是困扰开发人员的一个重要因素。REST API 也不例外,它是需要防范安全威胁和漏洞的重要系统的一部分。


据 2018 年Postman社区报告(调查)显示,越来越多的开发者开始关注 REST API 的安全性,并且对 REST API 的信任度也比前一年有所提高:



在本文中,我将介绍当今 IT 界的 7 大 REST API 安全威胁,以引起大家的关注,并帮助大家了解那些能够反映 REST API 性能的安全威胁。


REST 的安全性问题。


REST 通常使用 HTTP 作为其底层协议,这带来了一系列常见的安全性问题:


  • 潜在的攻击者可以完全控制 HTTP 请求或 HTTP 响应的每个字节。由于 REST API 通常用于交换在许多服务器中保存执行的信息,因此它可能会导致一些未经发现的漏洞和信息泄漏。

  • 攻击者可能在客户端(REST API 的消费者,而受害者是 REST API 服务器)也可能在服务端(攻击者获得了对 REST API 服务器的控制权)创建一个恶意的流氓应用程序。在这种情况下,使用远程 REST API 服务消费资源的应用程序是受害者。

  • 对使用 REST 作为客户端或服务端的应用程序,另一方通常完全控制资源,并可以注入任何负载来攻击资源处理(例如,获取任意 Java 代码或系统命令执行)。


在 REST 架构中,端到端的处理意味着包含一系列潜在的易受攻击的操作:


  • 在往返于 HTTP 消息和资源 URL 的映射过程中(控制器映射)。

  • 当实例化表示目标资源的对象并调用请求操作(从控制器中调用服务)时。

  • 为目标资源(特定于服务的函数)生成状态表示时。

  • 访问/修改托管资源状态的后端系统中的数据时(保存到数据库或存储中)。


REST 框架中的分层转换序列意味着链中的一个薄弱环节就可能会使我们的应用程序变脆弱。


7 大 REST API 安全威胁

1. 注入攻击

在注入攻击中,危险代码被嵌入到一个不安全的软件程序中,以发起攻击,其中最著名的是 SQL 注入和跨站点脚本攻击。实际上,这种暴露可以通过将不受信任的数据作为查询或命令的一部分传输到 API 中来操作。该输入随后由解释器实现,这可能会导致攻击者获取未经授权的信息访问权限或造成其他损害。


阻止或拒绝注入攻击最有效方法是添加输入验证,以下是几个最重要的准则:


  • 验证输入:长度、范围、格式及类型

  • 通过在 API 参数中使用强类型(如数字、布尔值、日期、时间或固定数据范围)来实现隐式输入参数校验

  • 用正则表达式约束字符串的输入

  • 定义适当的请求大小限制并使用 HTTP 响应状态 413(请求实体太大)来拒绝超过该限制的请求


2. DoS 攻击

在拒绝服务(DoS)攻击中,攻击者在大多数情况下会推送大量消息,请求服务器或网络建立由无效返回地址组成的请求。如果没有采取适当的安全防范措施,这种攻击能够使 RESTful API 处于无法运行的状态。最近,无论 API 是否公开,其他人(包括攻击者)都可以访问它。



随着这些 API DoS 攻击变得变得越来越普遍,并且随着组织越来越多地依赖 API 来满足其业务需求,安全专业人员应该开始积极计划应对此类攻击。即使禁用用于应用程序身份验证的 API 密钥(或访问令牌),也可以通过标准浏览器请求轻松地重新获取密钥。


因此,使当前访问令牌失效不是一个长期的解决方案。如果 DoS 攻击可以追溯到某个特定的 IP 地址,那么将该 IP 地址列入黑名单也不是长久之计,因为攻击者可以很容易地获取一个新的 IP 地址。


这就是为什么需要多种访问控制方法的原因。对于非敏感信息,使用 API 密钥可能就足够了。然而,为更好地防止 DoS 攻击,需要使用 HTTPS 和更健壮的身份验证机制,包括OAuth、相互(双向)TLS(传输层安全性)身份验证或SAML(安全断言标记语言)令牌。


为防止可能会导致 DDoS 攻击或其他 API 服务滥用的大量 API 请求,请在给定时间间隔内对每个 API 的请求数量施加限制(也称为峰值阻止)。当超过此速率时,至少暂时阻止来自该 API 密钥的访问,并返回 429(请求过多)HTTP 错误码。


如果我们开始构建新的REST API了,请先检查下 Web 服务是否具有一些面向安全性的特性。


3. 身份验证失败

这些特殊的问题可能使攻击者绕过或控制 Web 程序使用的身份验证方法。身份验证丢失或不足可能会导致攻击,从而破坏 JSON Web 令牌、API 密钥、密码等。


攻击的目的通常是控制多个帐户,更不用说攻击者获得与被攻击用户同等的权限。只有经过身份验证的用户才可以访问这些 API。


使用 OpenId/OAuth 令牌、PKI 和 API 密钥可以很好地满足 API 授权和身份验证需求。最好不要通过未经绑定的连接发送凭据,也不要在 Web URL 中显示会话 ID。


4. 敏感数据泄露

由于在传输中或静态时缺乏加密而导致的敏感数据暴露可能会导致攻击。当应用程序无法正确保护敏感数据时,就会发生敏感数据泄漏。这些信息可能是私人健康信息、信用卡信息、会话令牌、密码等,而且包含越多的信息越容易受到攻击。敏感数据需要很高的安全性,除了在与浏览器进行交换时采取非常规的安全做法外,还包括静态或传输中的加密。


为了避免敏感数据泄露,必须使用 SSL。


今天,我们可以通过Let’s Encrypt得到一个免费证书。SSL 和 TLS 在消除基本 API 漏洞方面经验丰富,几乎不费吹灰之力。


要想获得一份有关实施效果的出色报告,请使用Qualys SSL服务测试,测试你的 URL。这是我们的测试结果:



5. 访问控制中断

访问控制,在某些情况下称为授权,是一个 Web 软件允许某些人而不是所有人访问它的功能和内容的方式。缺少访问控制或访问控制不足可能会使攻击者可以控制其他用户帐户、变更访问权限、变更数据等。


当开发人员未能正确地配置操作级的可访问性时,公司应用程序访问就容易受到攻击,从而导致访问漏洞。拒绝访问是破坏访问控制的最常见后果,而利用访问控制是攻击者的主要手段。


由于某些框架中缺少访问控制,因此可以通过手动或自动化的方式来检测访问控制。如果在可靠的无服务器或服务器端 API 中实现了访问控制,则访问控制通常是有效的,因为攻击者将无法更改访问控制元数据。


6. 参数篡改

这是一种基于操作客户端和服务器之间交换的参数来修改应用程序数据(例如,用户凭据和权限、产品价格和数量等)的攻击。通常,这些信息存储在 cookie、隐藏表单字段或 URL 查询字符串中,用于增强应用程序的功能和控制。


当有害的网站、程序、即时消息、博客或电子邮件使用户的 Internet 浏览器在授权的网站上执行不必要的操作时,就会发生这种情况。它允许攻击者在被攻击用户不知情的情况下,使用目标的 Web 浏览器使目标系统执行某个功能,直到未经授权的事务被执行为止。


攻击能否成功取决于完整性和逻辑验证机制的错误,利用该机制可能还会导致其他攻击,包括 XSS、SQL 注入、文件包含和路径泄漏等攻击。


我们应该仔细地校验接收到的 URL 参数,以确保该数据能代表来自用户的有效请求。无效请求可用于直接攻击 API 或攻击 API 背后的应用程序和系统。将校验器放在应用程序上,并尝试对发送到 REST API 的请求使用 API 签名。还可以为API创建自动化安全测试,以确保没有参数篡改来影响我们的 REST API。


7. 中间人攻击(MITM)

它是指攻击者秘密地更改、拦截或中继两个交互系统之间的通信,并拦截它们之间传递的私有和机密数据。MITM 攻击分为两个阶段:拦截和解密。



HTTP 且缺少 TLS

API 中缺少传输层安全性(Transport Layer Security,TLS)实际上等同于向黑客发出公开邀请。传输层加密是安全 API 中最基本的“必备条件”之一。除非使用 TLS,否则遭受普遍存在的“中间人”攻击的风险仍然很高。在 API 中同时使用 SSL 和 TLS 很有必要,尤其是要使用公开 API​​时。


总结

在开发 REST API 时,必须从一开始就注意安全性。可以考虑使用内置了许多安全特性的现有 API 框架。在 RestCase 中,我们使用的是SugoiJS API框架,除测试和安全指导之外,我们还为其代码库做出了贡献。通过这种方式,安全性被统一地内置,并且开发人员可以更专注于应用程序的逻辑。


在这之后,不要忘记分配资源来测试 API 的安全性。一定要测试本文中所提到的所有安全威胁。


原文链接:


Top 7 REST API Security Threats


2019 年 12 月 10 日 11:114123
用户头像
万佳 InfoQ编辑

发布了 608 篇内容, 共 222.6 次阅读, 收获喜欢 1487 次。

关注

评论

发布
暂无评论
发现更多内容

default-servlet-handler不生效原因,springmvc静态资源拦截方案比较

叫练

springmvc 静态资源拦截 default-servlet-handler 资源配置不生效

史上最实用的Android切片应用库XAOP使用指南

android aop 开源项目 框架

《程序员数学:使用Python进行3D图形,机器学习和仿真》PDF免费下载

计算机与AI

Python 学习 数学

计算机网络基础

Minar Kotonoha

node.js 前端 计算机网络 HTTP

Flutter Plugin插件开发填坑指南

flutter 经验分享

Spock单元测试框架实战指南三 - f esle 多分支场景测试

Java老k

单元测试 spock

史上最优美的Android原生UI框架XUI使用指南

android UI 框架开发

Redis 为什么这么快?这才是最完美的回答

Java架构师迁哥

架构师训练营第十一周命题作业

一马行千里

极客大学架构师训练营 命题作业

架构师训练营第十一周学习笔记

一马行千里

学习 极客大学架构师训练营

网络入门模拟器:Cisco Packet Tracer

roblox 杂记

katichar

架构师训练营第12周作业

邓昀垚

二、关于大型复杂系统

数列科技杨德华

架构师视角 | 分布式缓存如何选择 ?

Java架构师迁哥

话题讨论 | 那些年奇葩的面试经历

三号无名指

话题讨论

让战略不再”空虚“的战略描述

Alan

战略思考 战略

移动端技术方案设计的经验总结

张明云

android 架构 移动应用 架构师 技术方案

架构词典:SLA

lidaobing

架构 SLA

LeetCode题解:45. 跳跃游戏 II,贪心正向查找,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

程序员有必要读研吗?

Java架构师迁哥

史上最全的开源项目创作指南

开源 经验分享

史上最好用的Android全量版本更新库XUpdate使用指南

android UI 框架开发 xupdate

面试被问线程安全怎么保障,我的回答让面试官眼前一亮

996小迁

Java 学习 架构 面试 笔记

架构师训练营第 12 周总结

邓昀垚

我是怎么教我6岁女儿编程的

勇往直前的胖子

少儿编程

培训是为了激发学员学习这门课的兴趣

boshi

职业 培训

技术博客,从零到数万访问,这两年我都做了什么

android 博客 经验分享

线上数据被回滚两次我都做了哪些不正确的操作

Gopher指北

MySQL 后端

甲方日常 63

句子

工作 随笔杂谈 日常

传销组织的CTO | 法庭上的CTO(4)

赵新龙

CTO 传销 法庭上的CTO

围绕“三个问题”开展的网易云音乐数据基础建设

围绕“三个问题”开展的网易云音乐数据基础建设

REST API面临的7大安全威胁-InfoQ