API 服务器_api服务器攻击

交易所api绑定所有白名单还安全么

因为很多的攻击是要基于有连接的情况下，才能有攻击的可能的。

既然是固定的服务器，它的IP地址一般也是固定的，否则题主怎么配置IP白名单？所以那些说DHCP的恐怕没好好理解题目里的信息吧？

还有那些说NAT的，如果两个服务器之间的通讯过了NAT，A服务器知道的就不是B服务器的真实IP了，那这个IP白名单也就没啥意义了呀！所以可以假设题主说的应该不是那种过NAT的 *** 。估计要么是两台公网上的主机，要么是2台机房里内网的两台主机之间吧。

当然。ARP欺骗是要考虑的，如果是机房里在同一网段的，要做好ARP欺骗的防御。公网上要做ARP欺骗好像比较困难吧？

如果再结合端口白名单，我感觉会更加安全些。

安全从来没有绝对的，我想题主想问的是能否用IP白名单这种简单的技术，在特定服务需求的场景下，可以实现更大化的安全吧

服务器安全应该注意哪些方面

技术在近年来获得前所未有的增长。云技术如今已被运用到银行、学校、 *** 以及大量的商业组织。但是云计算也并非万能的，和其他IT部署架构一样存在某些难以弥补的缺陷。例如公有云典型代表：服务器，用户数据存储在云计算基础平台的存储系统中，但敏感的信息和应用程序同样面临着 *** 攻击和黑客入侵的威胁。以下就是壹基比小喻要讲的服务器面临的九大安全威胁。

哪些因素会对服务器安全有危害？

一、数据漏洞

云环境面临着许多和传统企业 *** 相同的安全威胁，但由于极大量的数据被储存在服务器上，服务器供应商则很可能成为盗取数据的目标。供应商通常会部署安全控件来保护其环境，但最终还需要企业自己来负责保护云中的数据。公司可能会面临：诉讼、犯罪指控、调查和商业损失。

二、密码和证书

数据漏洞和其他攻击通常来源于不严格的认证、较弱的口令和密钥或者证书管理。企业应当权衡集中身份的便利性和使储存地点变成攻击者首要目标的风险性。使用服务器，建议采用多种形式的认证，例如：一次性密码、手机认证和智能卡保护。

三、界面和API的入侵

IT团队使用界面和API来管理和与服务器互动，包括云的供应、管理、编制和监管。API和界面是系统中最暴露在外的一部分，因为它们通常可以通过开放的互联网进入。服务器供应商，应做好安全方面的编码检查和严格的进入检测。运用API安全成分，例如：认证、进入控制和活动监管。

四、已开发的系统的脆弱性

企业和其他企业之间共享经验、数据库和其他一些资源，形成了新的攻击对象。幸运的是，对系统脆弱性的攻击可以通过使用“基本IT过程”来减轻。尽快添加补丁——进行紧急补丁的变化控制过程保证了补救措施可以被正确记录，并被技术团队复查。容易被攻击的目标：可开发的bug和系统脆弱性。

五、账户劫持

钓鱼网站、诈骗和软件开发仍旧在肆虐，服务器又使威胁上升了新的层次，因为攻击者一旦成功**、操控业务以及篡改数据，将造成严重后果。因此所有云服务器的管理账户，甚至是服务账户，都应该形成严格监管，这样每一笔交易都可以追踪到一个所有者。关键点在于保护账户绑定的安全认证不被窃取。有效的攻击载体：钓鱼网站、诈骗、软件开发。

六、居心叵测的内部人员

内部人员的威胁来自诸多方面：现任或前员工、系统管理者、承包商或者是商业伙伴。恶意的来源十分广泛，包括窃取数据和报复。单一的依靠服务器供应商来保证安全的系统，例如加密，是最为危险的。有效的日志、监管和审查管理者的活动十分重要。企业必须最小化暴露在外的访问：加密过程和密钥、最小化访问。

七、APT病毒

APT通过渗透服务器中的系统来建立立足点，然后在很长的一段时间内悄悄地窃取数据和知识产权。IT部门必须及时了解最新的高级攻击，针对服务器部署相关保护策略（ID:ydotpub）。此外，经常地强化通知程序来警示用户，可以减少被APT的迷惑使之进入。进入的常见方式：鱼叉式 *** 钓鱼、直接攻击、USB驱动。

八、永久性的数据丢失

关于供应商出错导致的永久性数据丢失的报告已经鲜少出现。但居心叵测的黑客仍会采用永久删除云数据的方式来伤害企业和云数据中心。遵循政策中通常规定了企必须保留多久的审计记录及其他文件。丢失这些数据会导致严重的监管后果。建议云服务器供应商分散数据和应用程序来加强保护：每日备份、线下储存。

九、共享引发潜在危机

共享技术的脆弱性为服务器带来了很大的威胁。服务器供应商共享基础设施、平台以及应用程序，如果脆弱性出现在任何一层内，就会影响所有。如果一个整体的部分被损坏——例如管理程序、共享的平台部分或者应用程序——就会将整个环境暴露在潜在的威胁和漏洞下

JWT-token—前后端分离架构的api安全问题

前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。

前后端分离架构现状：

这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。

1.接口公开，谁都可以访问

2.数据请求的参数在传输过程被篡改

3.接口被重复调用

...

session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了

JWT标准的token包含三部分：

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等

将上面的 *** ON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header

Payload也是一个 *** ON对象。包含了一些其他的信息

这里面的前五个字段都是由JWT的标准所定义的。

将上面的 *** ON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload

将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了

最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容

这一部分叫做 签名

最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT

签名解决了数据传输过程中参数被篡改的风险

一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。

解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击

比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。

可以在Payload里增加时间戳并且前后端都参与来解决：

「微服务架构」部署NGINX Plus作为API网关，第1部分 - NGINX

了解着名的Nginx服务器（微服务必不可少的东西）如何用作API网关。

现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。

有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API网关。

作为领先的高性能，轻量级反向 *** 和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。

注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。

API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。

在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用 *** ON请求并生成 *** ON响应。但是，当部署为API网关时，使用 *** ON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。

Warehouse API实现为离散微服务的 *** ，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：

例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。

使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向 *** ，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。

为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。

所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。

所有NGINX配置都以主配置文件nginx.conf开头。要读入API网关配置，我们在nginx.conf的http块中添加一个指令，该指令引用包含网关配置的文件api_gateway.conf（下面的第28行）。请注意，默认的nginx.conf文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置（第29行）。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。

api_gateway.conf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点（第13行）发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。

此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。

一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。

API网关发布的所有API的所有后端API服务都在api_backends.conf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。

配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。

Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由更具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。

此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。

使用重写指令将处理移至API策略部分

重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。

在这个阶段，我们的政策部分非常简单。位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。最后，请求被 *** 到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。

API定义有两种 *** - 广泛而精确。每种API最合适的 *** 取决于API的安全要求以及后端服务是否需要处理无效的URI。

在warehouse_api_simple.conf中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛 *** 。这意味着以任一前缀开头的任何URI都 *** 到相应的后端服务。使用基于前缀的位置匹配，对以下URI的API请求都是有效的：

如果唯一的考虑是将每个请求 *** 到正确的后端服务，则广泛的 *** 提供最快的处理和最紧凑的配置。另一方面，精确的 *** 使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。采用精确的 *** ，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。

此配置更详细，但更准确地描述了后端服务实现的资源。这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：

使用精确的API定义，现有的API文档格式可以驱动API网关的配置。可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。此博客文章的Gists中提供了用于此目的的示例脚本。

随着API的发展，有时会发生需要更新客户端的重大更改。一个这样的示例是重命名或移动API资源。与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。

在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。

动态重写URI意味着当我们最终在第26行 *** 请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_simple.conf的第21行所做的那样）。这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。

HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。

顶级API网关配置包括一个定义如何处理错误响应的部分。

第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。

第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。

完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。

有了这种配置，客户端对无效URI的请求就会收到以下响应。

在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的 *** 。有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证 *** 。

API密钥身份验证

API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。

在顶级API网关配置文件api_gateway.conf的第6行，我们包含一个名为api_keys.conf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。

API密钥在块中定义。 map指令有两个参数。之一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量（$ api_client_name）并将其设置为之一个参数与键匹配的行上的第二个参数的值。

例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。

地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_keys.conf文件。 API密钥身份验证由每个API的策略部分强制执行。

客户端应在apikey HTTP头中显示其API密钥。如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_keys.conf第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。

有了这个配置，Warehouse API现在可以实现API密钥身份验证。

JWT身份验证

*** ON Web令牌（JWT）越来越多地用于API身份验证。原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。

本系列的之一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。

原文：

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

api服务器简介

了解规则

人们创造了社交礼仪来指引他们的交流。一个例子就是我们如何用 *** 和其他人交流。假设你正和朋友通话。当他们说话的时候，你知道自己应该保持安静。你知道应该允许他们有短暂的停顿。如果他们问了一个问题，然后保持沉默，你知道他们希望得到回应，现在该你说话了。

计算机有相似的礼仪，虽然它们使用的术语是“协议”。计算机协议就是一组已经被接受的规则，这些规则约束计算机如何交谈。然而，和我们的标准相比，计算机协议是非常死板的。花点时间想想这两个句子“我最喜欢的颜色是蓝色”和“蓝色是我最喜欢的颜色”。虽然它们使用的词的顺序是不同的，但是我们可以分解这两个句子并且知道它们的意思是一样的。很不幸，计算机没那么聪明。

为了让两台计算机有效的交流，服务器必须准确的知道客户端会如何排列它的信息。你可以类比一个人询问一个邮件地址。当你询问一个地址的位置时，你假设首先被告知的是街道地址，随后是城市，州，最后是邮政编码。对于地址的每一部分，你也许会有特定的期望，比如邮政编码应该只包含数字。计算机协议要想工作也需要类似的细节。

Web协议

有一个协议是几乎针对一切的：每一个协议完成不同的工作。你可能听说过一些协议：通信设备上用的蓝牙，收邮件的POP或者IMAP。

在Web上，最主要的协议是超文本传输协议，它的缩写更知名一些，HTTP。当你在浏览器中输入 这样的地址的时候，“http”告诉浏览器使用HTTP的规则和服务器通信。

由于HTTP在web上无处不在，因此很多公司选择它作为自己的API的底层协议。使用熟悉的协议的一个好处就是可以降低开发者的学习曲线，鼓励他们使用API。另一个好处是HTTP有几个特性对于构建一个好的API非常有用，随后我们会看到。现在让我们擦去迷雾，看一看HTTP是如何工作的吧。