Q1 什么是API?
API 是 Application Programming Interface(应用程序编程接口)的首字母缩写。API 呢,简单来说就是一组规则和接口,能让不同的软件或者程序相互交流和合作。打个比方,假如有一个手机应用想要获取所在位置信息,它不用自己去收集和处理所有的数据,而是可以通过使用"位置"数据提供商提供的 API ,按照这个 API 规定的方式去请求和获取位置相关的数据。再比如说,您用的某个社交软件想让您能直接分享内容到另一个平台,也是通过调用那个平台开放的 API 来实现的。总之,API 就像是不同软件之间的“桥梁”或者“通道”,让它们能方便地共享信息和实现某些功能。

API安全防护示意-图1
Q2 什么是Web API?
Web API 简单来讲就是通过网络(特别是互联网)来提供的应用程序编程接口。
比如说,您打开一个购物网站,网站上展示商品信息、价格、销量等数据,这些数据不是网站自己凭空生成的,而是通过调用后端的 Web API 从数据库中获取的。又比如您用手机上的地图应用查找附近的餐厅,这个应用也是向服务器发送请求,通过服务器提供的 Web API 获取相关餐厅的位置、评价等信息。
Web API 让不同的网页应用或者移动应用能够与服务器进行交互,获取或提交数据,实现各种各样的功能,就像给这些应用提供了一个获取所需信息和完成特定任务的“快捷通道”。

WebAPI工作示意-图2
Q3 Web API与传统的API区别是?
比如说,一个为移动应用提供位置信息的 Web API ,任何支持网络请求的移动开发语言都能轻松调用获取数据;而传统的某个操作系统内部用于系统组件通信的 API ,则只能在该操作系统特定的开发环境中使用。总的来说,Web API 更适应现代互联网环境下的分布式应用和跨平台需求,而传统 API 则在特定的软件系统内部发挥重要作用。
Web API与传统的API区别示意-图3
Q4 Web API的四种常见类型
目前常见的 Web API 四种主要类型(基于 HTTP 的 API)如下:
- RESTful API——表现层状态转换 (RESTful) 可追溯到Roy Fielding 2000 年的博士论文,是最常见的 Web API 类型,通常使用 JSON(JavaScript 对象表示法)来交换数据。RESTful API 易于供现代前端框架(例如 React 和 React Native)使用,并可促进 Web 应用程序和移动应用程序的开发。这类 API 已成为各种 Web API(包括 B2B API)的实质性标准。
- SOAP API——SOAP使用详细的可扩展标记语言 (XML) 进行远程过程调用 (RPC)。在旧版 API 中仍然可以找到它。
- GraphQL API——Facebook 开发的新标准,通过单个 POST 端点(通常为 /graphql)提供数据库访问功能。GraphQL API 解决了 RESTful API 的一个常见问题(需要多次调用才能填充单个 UI 页面),但引入了其他附加问题。
- gRPC API——Google新开发的 HTTP/2.0 高性能二进制协议,主要用于东西向通信

WebAPI类型-图4
Q5 B2C API 和 B2B API 有什么区别
企业对消费者(B2C)的 API 呢,就是支持网页应用程序和手机应用程序的一种接口。这些接口常常被现在的前端客户端用到,能让最终用户用上公司开放的业务功能。企业对企业(B2B)的 API 是公司合作伙伴(其他公司)用的,有时给合作伙伴服务(这些公司就是最终客户),有时给共同客户创造价值(就是 B2B2C)。B2B 的 API 是企业数字化转型的基础,因为能让企业和供应商、经销商还有其他伙伴合作更简单,给企业客户体验也更好。比如说开放银行 API 、供应链管理 API 、贸易伙伴之间电子开票和付款,这些都是 B2B API 。因为用 B2C API 的是面对用户的应用程序,用 B2B API 的是合作伙伴的业务应用程序,使用者差别大,所以保护它们的安全控制工具也不一样。在安全上,行业关注点到最近还主要在 B2C 应用场景,但就算在这场景里,重点也不是保护 B2C 的 API ,而是保护网页应用程序。保护 B2C 网页应用程序的安全控制工具,很难用来保护 B2C 的 API (像 WAF/WAAP ),有的甚至根本用不了(像大部分防爬虫程序的解决办法)。保护 B2B 的 API 已经变成个越来越重要的问题。对 B2B API 来说,第一代供应商没有专门针对共享用户批量数据访问的安全监测和保障方案(像开放银行业务里,金融科技公司和金融机构同意共享客户数据,就是这种情况)。Q6 API 和端点有什么区别?
很多时候,人们说“API”,其实说的是单个的 API 端点。API 有时候也被叫做服务或者 API 产品,它实际上是一堆端点凑在一起,为业务功能服务。那什么是端点呢?端点就是资源(或者说是资源的路径,也有人叫它 URI 或者统一资源标识符),还有对这个资源能做的操作,比如创建、读取、更新或者删除。在 RESTful API 里,这些操作一般跟 HTTP 方法是对应的,像创建对应 POST,读取对应 GET,更新对应 PUT,删除对应 DELETE。这些 API 是企业对外面(主要是合作伙伴)开放的。比如说,搞开放银行业务的银行可能通过 API ,让别的金融科技企业或者金融服务企业能使用它的账户。医疗保健企业可能通过 API 把患者记录给保险公司和其他医疗企业用。酒店企业可能通过 API 把预订系统开放给旅行社或者旅游信息采集平台。API 就是企业之间的连接桥梁。
南北向的 API 通常被认为是安全的,因为使用 API 已经得到了允许并且通过了身份验证。但这些 API 往往增长得特别快,数量又特别多,所以对于大多数企业来讲,这是一个很大的容易受到攻击的地方。企业内部使用的 API,它们将内部应用程序或者业务单位(部门)连接起来。只要无法从企业外部访问,就是东西向 API。
API环境示意-图5
Q8 私有 API 和公共 API 有什么区别?
私有 API 也叫内部 API ,是公司内部开发人员和承包商用的。它通常是面向服务架构计划的一部分,能方便不同部门或业务单位获取彼此数据,让内部开发更轻松。
公共 API 又叫外部 API ,对公司外的人开放,极端情况下谁都能用,但需要严格管理和完整文档供外部工程师使用。得注意,能通过互联网访问的私有 API 不是真的私有 API 。
Q9 什么是API漏洞
API 漏洞是一种软件错误或系统配置错误,可能导致攻击者利用这类错误来访问敏感应用程序功能或数据,或者造成 API 滥用。
就好比 API 是房子的门,漏洞就是门没关好或者坏了。比如可能没好好检查用户能不能进来,不该进的人能随便进还能拿数据;或者传输数据时没加密,被人截取就能看到;也可能 API 本身代码有错,处理不了特殊请求,导致系统出问题或者结果不对。反正 API 漏洞会让坏人有办法非法拿到信息、搞坏系统或者影响正常服务。
OWASP TOP 10 API 安全风险清单十分实用,其中概括了一些被广泛滥用的 API 漏洞,企业应该尽力识别和修复这些漏洞。这一块太庞大了,就不说了,细看可前往。
https://owasp.org/www-project-api-security/
Q10 API滥用的方式有?

API滥用示意-图6
Q11 API安全怎么防护?
- 身份验证和授权: 就是要弄清楚访问 API 的用户是谁,只有被准许的用户才能去操作数据。像多重身份验证、OAuth 、OpenID Connect 以及 API 密钥这些都是身份验证的办法,授权方面有基于角色的和基于属性的访问控制。
- API 网关: 所有 API 请求进来的地方,作用可多啦,能验证身份、限制访问的速度、管理流量和做缓存,还能挡住像分布式拒绝服务(DDoS)这样的攻击。
- 加密: API 安全防护解决方案还涉及加密,用于保护通过 API 传输的数据的安全,确保攻击者无法拦截数据。加密技术包括 SSL、TLS 和 AES 加密,可用于加密 API 请求、响应和静态数据。这个办法能保护通过 API 传输的数据,让别人截获了也看不懂。
- 速率限制:能防止有人在特定时间里发太多请求来捣乱,能按照不同的 IP 地址、用户账号等去设置。
- 审计和日志记录: 盯着 API 的活动,追踪请求和响应,用安全又改不了的方式把 API 的事件和活动都记下来,这样能帮着发现安全威胁。
- API 测试:找出漏洞和可能的安全风险,手动或者用自动化工具都行,能保证 API 是安全的,能正常运行。
- API 监控:盯着 API 的行为,能分清正常的和不正常的滥用,保护 API 不被恶意攻击。
- 漏洞管理: 找出并解决 API 里的安全漏洞,像扫描漏洞、打补丁、修复漏洞,不让攻击者利用已知的漏洞。
总的来说,这些解决方案对保证 API 的安全和完整特别重要。因为 API 对企业越来越不能少了,所以企业得花钱弄可靠的方案来保护敏感数据和知识产权。举个栗子,有一家大型电商企业用了这些安全防护办法,用多重身份验证保证用户登录 API 是安全的;靠 API 网关去管理流量和验证身份;给数据加密传输;设置速率限制,不让人乱发请求;做好审计和日志记录,方便追查问题;做 API 测试,及时找出漏洞;通过监控和运行时保护随时看着 API 的状态;做好漏洞管理,保证 API 没有已知的安全问题,这样就保证了企业的 API 安全,也保护了用户数据和企业的知识产权。
Q12 什么是僵尸 API、影子API?
僵尸 API 指的是那些虽然已经部署了,但很少或者几乎不再被使用的 API 。就好像是一个被遗忘在角落里、无人问津的工具。
影子 API 则是那些在企业的正式记录和监管之外被开发和使用的 API 。比如说,某个开发团队为了快速解决问题,自己私下弄了个 API 来用,但公司并不知道,也没有对其进行管理和监控。简单来说,僵尸 API 是被冷落的,而影子 API 是偷偷存在的。
至于这块怎么去发现并处理僵尸、影子API,这一块有专业的公司,会提供专业的工具发现并处理,僵尸这块更多得跟开发团队去沟通,工具很难梳理出来。
Q13 什么是API攻击、API撞库?
API 攻击就是对应用程序编程接口(API)干的坏事,想破坏 API 正常运行、拿到没授权的数据或者干非法的事。比如说,攻击者可能狂发恶意请求,让 API 服务器累趴下,正常用户就用不了;或者找 API 的安全漏洞,绕过授权拿到敏感信息。
API 撞库是这样的,攻击者有好多用户名和密码的组合,就在某个 API 上一个个试能不能登录。要是登录成功,就能拿到用户信息或者干别的坏事。
总之,API 攻击是各种搞坏 API 的恶意行为,API 撞库是拿大量账号密码尝试登录 API 来谋私利。
Q14 什么是基于签名的 API 安全防护?
基于签名的 API 安全防护,简单来说,就是通过对 API 通信中的特定特征或标识进行识别和验证,来保障 API 安全的一种方式。 就好像每个人都有独特的签名来证明自己的身份一样,API 也有它独特的“签名”。这个“签名”可能包含了一些关键的信息,比如请求的来源、请求的内容特征、特定的加密标识等等。 当有请求访问 API 时,系统会检查这个请求携带的“签名”是否符合预先设定的规则和标准。如果符合,就认为是安全的请求,允许通过;如果不符合,就可能被判定为不安全的请求,从而被拒绝或者触发相应的安全警报。举个栗子,一家电商公司的 API 系统设置了基于签名的安全防护,规定只有来自特定合作伙伴网站的请求,并且请求中包含特定的加密标识,才被认为是合法的。这样,就能有效地防止来自其他不明来源或者恶意的请求访问 API ,保护公司的数据和业务安全。Q15 什么是 API 检测和响应?
API 检测和响应简单来讲,就是对 API 的运行状况和相关活动进行密切监视,并在发现异常或潜在威胁时迅速采取应对措施的过程。
比如说,检测就像是时刻盯着 API 这个“大门”,看谁在进出、进出的频率如何、进出时携带的“东西”是否合规。而响应呢,则是当检测到不对劲的情况时,比如有大量异常的访问请求、数据传输出现异常等,马上采取行动,可能是阻止这些异常访问、发出警报通知相关人员,或者启动应急处理程序来修复问题、保护数据。
打个比方,API 检测和响应就像一个保安系统,检测是负责观察和发现问题的“眼睛”,响应则是负责处理问题的“手脚”。
例如,一家金融公司通过 API 检测和响应系统,发现某个时间段内 API 收到了大量来自陌生 IP 地址的请求,系统立即响应,阻止这些请求并启动调查,以防止可能的金融数据泄露。
Q16 常见的 API 类型和 API 术语有?

API使用意图示意-图7

API使用模式示意-图8
HTTP API:这类 API 使用超文本传输协议作为 API调用的通信协议。
RESTfuI API:表现层状态转换(RESTful) 可追溯到 Roy Fielding 2000 年的博士论文,是最常见的 Web API类型,通常使用 JSON(JavaScript对象表示法)来存储数据。RESTfuIAPI易于供现代前端框架(例如 React 和 React Native)使用,并可促进 Web 应用程序和移动应用程序的开发。这类 API已成为各种 Web API(包括 B2BAPI)的实质性标准。
GraphQL:GraphQL API是 Facebook开发的新标准,通过单个 POST端点(通常为 /graphql)提供数据库访问功能。GraphQL API解决了RESTfuI API的一个常见问题(需要多次调用才能填充单个 U 页面),但引入了其他附加问题。
SOAP:SOAP 使用详细的可扩展标记语言(XML) 进行远程过程调用(RPC)。在旧版 API 中仍然可以找到它。
XML-RPC:XML-RPC 是通过互联网进行过程调用的一种方法,使用XML进行编码并用 HTTP 作为通信协议。
gRPC:gRPC API是 Google 新开发的 HTTP/2.0 高性能二进制协议,主要用于东西向通信。
OpenAPI:OpenAPI是 API的一种描述和文档规范。在旧版本中,0penAPI被称为 Swagger,这两个术语现在仍然经常互换使用(就像 SSL与TLS)。
补充:现在市场上的API安全产品有很多,大致的功能都是资产接口的梳理、打水印溯源、脱敏、审计、权限控制,有时间的话大概可以去了解一下。国外也有做的比较好的就不方便说了。

上图引用自“数说安全”
深圳
注释:如有失误,望批评指正!
后面会写下Windows和liunx的应急响应技巧、容器、还有一些网络安全、数据安全。
后台输入“Windows应急响应手册、liunx应急响应手册、数据安全政策、数据安全治理、电力、工业、金融”有相关资料可供下载!
原文作者:老登的安全观;如有侵权,请联系管理员删除。