Lua CSRF 保护指南：示例以及如何启用

很难想象没有网络的世界会是什么样子。在那个世界，我们必须亲自处理大部分业务！在那个世界，我们必须邮寄支票来支付账单，并前往银行存取款。现在，我们几乎可以在网上做所有事情，当我们只需点击屏幕或单击鼠标即可支付账单或完成购买时，寄送支票似乎是不可想象的。

但这种便利并非没有重大风险。用户必须询问是否应该点击该按钮，而您作为开发人员必须确保您的按钮是安全的。您是否保护用户免受跨站点请求伪造 (CSRF) 的攻击？

CSRF 是一种攻击，黑客会想方设法让用户执行危险的 Web 查询。这种攻击也被称为 XSRF、Session Riding、Hostile Linking 和其他一些名称。

让我们讨论一下 CSRF 攻击以及如何保护您的 Lua Web 应用程序免受此类攻击。

什么是 CSRF？

攻击者利用跨站请求伪造，利用网络会话中的用户权限提交恶意请求。攻击者可以绕过常见的安全限制，诱骗用户发送伪造的查询（如 POST、PUT 或 GET），从而删除或窃取数据，甚至提交危险的资金转账。

与许多最有效的攻击一样，CSRF 通常依赖于社交工程。这些黑客攻击只有在用户点击危险链接时才会起作用。实现这一点的一种有效方法是诱骗用户点击电子邮件或聊天中的链接。

如果用户打开了会话，这些链接就会在易受攻击的网站上触发破坏性交易。因此，例如，如果电子邮件中的链接指向用户已登录的网站，攻击将利用有效的会话 cookie。

这些攻击非常普遍，令人沮丧。网站无法保护自己免受社会工程攻击，因此开发人员只能想办法在不牺牲用户便利性和满意度的情况下阻止 CSRF 攻击。

因此，确保保护您的 Web 应用程序免受 CSRF 攻击至关重要。

CSRF 攻击

让我们看两个 CSRF 攻击的例子。然后我们将了解如何保护您的 Lua Web 代码免受这些攻击。

请求确认

这是 HTML 电子邮件的示例。

这是一个最基本的例子，但想象一下，一个黑客发送这封电子邮件，其中的品牌是从知名支付服务中窃取的。（出于显而易见的原因，我们不想在这里这样做。）攻击者购买了一个电子邮件列表，并为每封电子邮件生成并发送一条消息。他们赌至少有几个目标会与该服务进行公开会话，并且没有密切关注。

我们看一下链接。

此链接并非确认交易，而是向其他人发起转账！该链接发送带有参数的 GET 请求，向名为 techbro 的用户发送大量资金。

用户如何保护自己免受这种攻击？他们可以关注银行和支付服务发送电子邮件的时间和原因，以及电子邮件的外观。他们可以仔细阅读电子邮件，查找错误的品牌标识和不恰当的语法。如果他们真的精明的话，他们可能会在点击链接之前先查看一下。

但大多数用户不会做这些事情，攻击只需一次即可成功。

开发人员有责任确保此类攻击不会得逞。在讨论解决方案之前，我们先来看一个例子。

不良形式

上例需要用户点击链接才能运行。点击后，系统会向银行发送恶意 GET 请求。如果电子邮件中嵌入了表单，情况会怎样？

这是新版本电子邮件攻击的来源。

<center>

<b>Congratulation!</b></br>

<p>$500.00 has been sent to yourname@youremail.com

<p>Click <a href="https://www.example.com/xfer?target=techbro&amount=25000">here</a> to confirm and get your cash!

<form method="post" action="https://www.example.com/xfer">

  <input name="amount" type="hidden" value="25000" />

  <input name="target" type="hidden" value="techbro" />

</form>

<script>document.forms[0].submit();</script>

</center>

电子邮件看起来完全一样，但它不是等待用户点击链接，而是在 HTML 呈现后立即发送 POST 请求！此外，该链接也存在攻击。类似的威胁可能会将确认链接附加到具有隐藏值的表单上，而不是隐藏它。使用 HTML 邮件和 HTML 聊天消息进行攻击的方法有很多种。

这些例子很初级，而且如上所述，其格式不像更复杂的网络钓鱼攻击。但不难想象，攻击会使用从热门银行和购物网站窃取的“商业外观”。

那么，我们如何保护我们的用户？

Lua CSRF 保护

保护 Web 应用程序免受 CSRF 攻击的最常见方法是生成令牌并在页面响应中将其返回给用户。如果后续请求不包含该令牌，则应用程序知道该请求不安全。

您可以使用三种方法处理 CSRF 令牌。

同步令牌对于每个客户端会话都是唯一的。这意味着服务器必须维护每个会话的状态信息，将 CSRF 令牌与它们进行核对，并在会话被销毁或过期时处置令牌。
加密令牌在所有客户端之间共享。这些令牌包含应用程序使用私钥加密的值，因此只有它们才能验证令牌是否合法。
Origin 标头将 CSRF 令牌放在服务器期望在请求中看到回显的标头中。

那么如何在 Lua 应用程序中使用这些技术呢？

编写自己的令牌

您可以编写代码来生成令牌，将其嵌入到页面中，并确保在需要时将其回显到您的应用程序。这需要额外的工作和大量测试，但它可以让您完全控制解决方案。Lua 有用于将令牌添加到网页或编写标头的工具，因此您可以选择自己的方法。

这个GitHub Gist包含在 Nginx 的 Lua 模块中运行的解决方案的示例代码。

Nginx Lua

如果您正在运行 Nginx 的Lua 模块或OpenResty Web 平台，则可以使用 Nginx 的Web 应用程序防火墙。它具有许多功能来保护您的应用程序免受攻击，包括 CSRF。Nginx 生成一个充当 CSRF 令牌的源标头。您可以将 Nginx 配置为要求特定 URL（例如 POST、PUT 和 DELETE 操作）使用此标头。

或者，您可以使用上面链接的要点。

Apache Lua

Apache 没有内置任何 CSRF 保护功能。有一些第三方模块，但它们比较老，而且似乎没有得到积极支持。如果您使用 Apache，则需要编写自己的代码。

青金石

Lapis 具有内置的 CSRF保护功能。它将生成一个共享的加密令牌并在 Web 请求中检查它。

保护您的 Web 应用程序

这篇文章探讨了什么是 CSRF 攻击以及它们对您和您的 Web 用户造成的危险。我们研究了两个示例。这两个示例都说明了欺诈性电子邮件的危险性以及对未受保护的应用程序发动 CSRF 攻击是多么容易。然后，我们研究了针对 CSRF 攻击的典型保护措施，以及如何编写自己的保护措施或利用 Nginx 和 Lapis 的 CSRF 保护。不幸的是，Apache 应用程序必须冒着第三方模块的风险或编写自己的 CSRF 令牌。

跨站点请求伪造是一种危险的攻击，但您可以使用记录良好的工具和流程保护您的应用程序免受此类攻击。

文章来源：Lua CSRF Protection Guide: Examples and How to Enable