简介

在讨论保护公开的HTTP资源的安全时，相对来说，通常会遇到防止跨站点请求伪造（CSRF）攻击的整个概念。

从技术角度来看，该流程规定调用者首先通过发送HEAD或GET请求从资源提供器获取CSRF令牌header X-CSRF-Token=获取并查找来自资源提供者的响应中包含的header X-CSRF-Token的值，该值是CSRF-Token的值，然后将获得的CSRF-Token值传递到随后发出的修改请求的header X-CSRF-Token中，例如那些使用HTTP方法POST、PUT发送的请求，修补和删除。在发出非修改请求（例如使用HTTP方法GET、HEAD和OPTIONS发送的请求）时，通常不需要使用CSRF令牌。

CPI本机支持在集成过程中为入站HTTPS连接启用CSRF保护–这是HTTPS适配器的现成标准功能之一。不过，值得记住的是，在遇到此功能的配置和使用时，特别是在CPI中，可能会有用的注释和备注很少。

基线场景概述

作为起点和基线场景，让我们介绍一个iFlow，它公开一个受CSRF保护的HTTPS端点，并在被调用时生成一个固定的响应消息。请注意，在HTTPS连接中，相应的功能（CSRF保护）已被激活：

为了收集有关已处理请求的所需详细信息（更准确地说，为了能够看到将到达iFlow的消息的内容），我临时增加iFlow的日志级别，以便在部署iFlow后进行跟踪。

我很抱歉将使用邮递员向CPI发送请求并调用此iFlow。遵循使用CSRF保护的HTTP资源时所需的一般原则和请求流，我们将在Postman中需要两个请求：

在实际场景中，可以方便地在Postman中配置环境和使用变量，以便在为第一个请求提供的响应中包含CSRF令牌由脚本自动检索并使用变量插入到第二个请求的相应头中，以及使用变量保存某些特定于环境和场景的信息，例如iFlow端点和用于身份验证的凭据。例如，可以从第一次调用的响应中读取CSRF token，并在Postman:

中的一行脚本中放入变量，然后在用token值填充报头X-CSRF-token时在第二次调用中使用变量。就在前一天，Jerry Wang发表了一篇博客文章"只需点击一下就可以测试需要CSRF令牌验证的SAP OData服务"，其中详细介绍了如何使用此技术来提高邮递员的使用效率。

不过，这里我们需要两个简单的请求，大多数情况下我们只会使用其中一个在测试过程中，我会偏离这些最佳实践，不会使用变量来简化和压缩邮递员发送的请求，免费自助建站软件，这也将帮助我避免使用Postman控制台来访问有效生成的请求和在变量位置发送的实际值的信息。

迭代1：基线场景

让我们测试基线场景。

在开始时，云快卖，我们发送一个修改请求POST request，里面没有CSRF token，检查iFlow是否返回授权错误：

如果发送一个非修改请求，我们也可以检查iFlow是否成功运行，下面用GET request来说明：

下一步，我们遵循上述流程，首先获取一个CSRF令牌，然后使用获得的CSRF令牌发送POST请求。

发送获取CSRF令牌的请求：

使用获得的CSRF令牌发送测试消息：

接收到的已发出请求的响应与邮递员的预期一致。

请注意，正如Yuri Ziryukin所强调的，在呼叫者获取CSRF令牌后，强烈建议保留从CPI收到的cookie，并在同一会话内的后续呼叫中呈现它们–仅有效的CSRF令牌不足以成功完成后续呼叫。特别是，CPI倾向于设置会话管理中使用的几个安全cookie，例如BIGipServer*、JSESSIONID和jtennatsessionid*cookies。在上面的示例中，Postman中cookies管理的默认设置将允许隐式使用这些cookies并将其添加到后续请求中，并且我们不会手动删除这两个cookies。如果您在随后的请求中碰巧未发送这些cookie，您将收到来自CPI的HTTP状态代码403（禁止）的响应，即使请求中存在有效的CSRF令牌。

现在让我们看看CPI消息监视器–有趣的是，最后一次测试有两条消息：

对观察到的消息进行更详细的检查，得出以下结论：

第一条消息对应一个HEAD请求，它是获取一个CSRF令牌的请求：

第二条消息对应一个POST请求，它是一个测试消息。

以上两条消息都在后面iFlow中相同的处理步骤：

这不是我们期望看到的–获取CSRF令牌的请求只能由运行时处理，以生成CSRF令牌并在安全检查成功通过时将其发送回调用方，但不能调用iFlow，因为这意味着iFlow会处理一条意外消息，如果iFlow中没有相关的验证，则可能会在iFlow或后续请求发送到的系统中导致错误。

迭代2：添加请求的特殊处理以获取CSRF令牌