Lua XSS：示例及预防

Lua是一种流行的脚本语言，在经验丰富的开发人员手中非常强大。但对于新手程序员来说，学习 Lua 并掌握强大的功能非常容易。不幸的是，这种组合可能会导致严重的问题，例如 Web 应用程序中存在跨站点脚本攻击 (XSS) 漏洞。

让我们看看 Lua XSS 攻击是如何工作的以及如何检测和预防它们。

什么是跨站点脚本 (XSS)？

跨站点脚本攻击会诱使 Web 应用程序向其 Web 客户端发送有害脚本。攻击者使用 XSS 劫持用户会话、在 Web 服务器或用户的 Web 浏览器中执行恶意代码、发起网络钓鱼攻击、传播恶意软件等。

攻击者通过将恶意脚本以表单或 API 请求输入的形式提供给应用程序来实现此目的。应用程序需要有关用户的信息，但却收到可执行指令或故意格式错误的 URL。攻击者通常在 Javascript 代码片段中编写 XSS 漏洞，但熟练的攻击者可以在 URL 请求中破坏易受攻击的应用程序。

Lua 与 XSS 有什么关系？

Lua 是一种易于学习并可嵌入到主机应用程序中的脚本语言。同时，它可以访问底层操作系统的系统接口。它具有垃圾收集功能，具有基于关联数组的强大构造，并且使用字节码运行，从而提高运行速度。

不过，您可能不认为 Lua 是前端应用程序的代码。许多人将它与Minecraft和Roblox等游戏联系起来。您还会发现 Lua 用于Redis等服务器端应用程序或Pandoc等可扩展实用程序。但在 Web 应用程序中呢？

开发人员在许多不同类型的应用程序中使用 Lua，包括 Web。Apache 和 Nginx 是两种最广泛使用的网络服务器，它们分别提供mod_lua和lua-nginx-module 。此外，尽管自 2015 年以来CGILua一直没有更新，但它仍可在现代 Linux 发行版上安装和运行。

假设您想超越 CGI 和 Web 服务器的嵌入式功能？可以使用OpenResty，这是一个使用 Lua 和 Nginx 的 Web 平台。Kepler 项目提供了Orbit（一个 MVC 工具包）和WSAPI（Lua 的抽象层）。

因此，XSS 攻击利用 Lua 有很多机会。让我们看看如何进行。

Lua XSS 攻击

反射型 XSS 攻击

反射攻击是最直接、最常见的XSS 攻击形式。

当恶意脚本从 Web 应用程序“反射”到用户的 Web 浏览器时，就会发生这种情况。用户会点击链接，期望发布回复、查看图片或视频，或访问友好网站。

但他们的浏览器却执行了破坏性脚本。该脚本经常将用户的个人数据发送给攻击者，因此有“跨站点脚本”一词。被入侵的网站会将您引导到另一个网站。这种攻击很容易发起，这就是它如此流行和有效的原因。

反射型 XSS 攻击的另一个名称是非持久性攻击，因为它们不会危害底层应用程序。犯罪分子将它们嵌入用户定义的内容中，例如论坛帖子和评论。因此，它们通常只对一小部分受众可见，而攻击者必须广撒网，希望少数受害者会点击恶意链接。

Lua 和反射攻击

Lua 的简单语法使得新手 Web 程序员很容易使他们的应用程序遭受反射型 XSS 攻击。

Apache 的mod_lua有两种方法可以将传递给处理程序的参数回显给请求者。

Mod_lua 应用程序实现了一个 handler(r)函数，其中 r是 Apache 传递给该函数的请求对象。

function handle(r) local danger = r:parseargs().user_name or "" r:puts(danger) end

处理程序函数使用r:parseargs()提取传递给 Web 调用的参数。它使用r.puts()处理字符串，使用r.write()处理未缓冲的字节，将内容作为 HTML 响应写回请求者。在这两种情况下，字符串都不会被清理或检查。如果攻击者传入 Javascript 或 HTML 内容，处理程序会逐字返回。

Nginx 容易受到类似攻击。其 Lua 代码可以动态加载或包含在 OpenResty 安装中。但是，它不会清理输入。

local danger = ngx.req.get_uri_args().user_name or "" ngx.header.content_type = "text/html" ngx.say(danger)

Say()将字符串作为 HTML 响应返回给请求者。

CGILua 看起来也很相似。

local danger = cgilua.QUERY.user_name or "" cgilua.htmlheader() cgilua.put(danger)

在所有这些情况下，都应在使用前验证输入。

存储型 XSS 攻击

在存储攻击中，黑客将恶意代码嵌入用户论坛或社交媒体的评论中。这些攻击具有持久性，因为 Web 应用程序将它们存储在数据库或其他永久存储中。它们更危险，因为许多用户可能会在应用程序所有者发现攻击之前查看破坏性内容。

应用程序不会（或除了）将恶意请求回显给请求者，而是会将其存储起来。后续访问该内容的访问者会请求同一页面，看到恶意数据并点击它。

下面是一个精心设计的代码片段，它将评论存储在 MySQL 中，然后回显给定帖子 ID 的完整评论集。

function handle(r) 



   -- connect to mysql

   driver = require "luasql.mysql"

   create environment object

   env = assert (driver.mysql())

   connect to data source

   con = assert (env:connect("mywebapp","root","123456"))



   -- grab post id, user, text

   local post_id = r:parseargs().comment_id or ""

   local user_name = r:parseargs().user_name or ""

   local comment_text = r:parseargs().comment_text or ""



   -- insert into the comments table

   res = assert (con:execute(string.format([[

      INSERT INTO comments

      VALUES ('%s', '%s', '%s)]], post_id, user_name, comment_text)

   ))



   -- probably do some more html things



   -- now pull all fothe comments out of the table and display

   -- cursor needs an order by 

   cur = assert (con:executestring.format([[SELECT user_name, comment_text from post_id = %s"]], post_id))

   row = cur:fetch ({}, "a")

   while row do

      r:puts(string.format("<p> User: %s<br> %s", row.user_name, row.comment_text))

      -- reusing the table of results

      row = cur:fetch (row, "a")

   end



   cur:close()

   con:close()

   env:close()

end

在此示例中，用户名、评论正文或两者都可能包含恶意代码。它会回显给用户，但它也会存储在 MySQL 中！因此，查看评论的任何其他用户都会看到危险的脚本。

预防 LUA XSS

在 Lua Web 应用程序中防止这些攻击相对简单，并且已经有工具可以帮助您。

不要相信用户输入

在上述所有情况下，Lua 脚本都会使用请求数据而不验证其内容。这是第一个也是最大的错误。至少，您必须在存储或将收到的任何数据传回给 Web 用户之前对其进行“转义”。Lua 没有内置的方法来清理 Web 输入，因此您必须自己动手或依靠用户社区。

Web_sanitize 是Lua 的 HTML 过滤器。您可以从 GitHub 下载它或使用luarocks安装它。代码太长，无法在此处嵌入，但如果您查看它（在将其添加到您的应用程序之前您应该查看它），您会看到它如何清理和转义用户输入，以便恶意脚本不再在客户端浏览器中执行。您可以转义 HTML 和 CSS 或从请求中提取文本，从而删除任何嵌入的代码。

这是 Apache Lua 处理程序的安全版本。

function handle(r) local web_sanitize = require "web_sanitize" local safe = web_santize.extract-text(r:parseargs().user_name) or "" r:puts(safe) end

验证用户输入

另一种方法是在使用输入之前对其进行验证，但这并不是净化输入的替代方法。这是一个额外的步骤。在删除任何潜在的脚本代码后，您可以确保输入在上下文中有意义。因此，在存储信用卡的校验和或用户地址之前对其进行验证。这不一定能防止 XSS，而且在不产生新问题的情况下验证输入可能很有挑战性，尤其是在涉及国际名称时。不过，在处理用户指定的代码和格式化数据时，这是一个好主意。