4

Groovy 中的 GString 概念非常强大（参见http://groovy.codehaus.org/Strings+and+GString）。

GStrings 让您可以执行以下操作：

world = "World"
println "Hello ${world}"
# Output: Hello World
println "1+2 = ${1+2}"
# Output: 1+2 = 3
println "${System.exit(-1)}"
# Program terminated

我试图弄清楚使用 Groovy GString:s 是否会在代码中引入类似于 SQL 注入攻击的安全问题。

在上面的示例中，代码是由程序的作者编写的，因此 System.exit(-1) 命令的执行不能被视为安全漏洞，因为它是作者声明的意图。

假设我正在编写一个 Grails Web 应用程序，其中用户输入来自表单字段（读取 POST/GET 参数）和数据库表（使用 GORM）。让我们假设攻击者控制了作为 POST/GET 请求发送到服务器的内容和数据库中的内容。

我的应用程序中的代码如下所示：

def str1 = params.someParameterControlledByTheAttacker
def str2 = SomeGORMPersistedObject.get(1).somePropertyFieldControlledByTheAttacker
render "Hello! Here is some text: ${str1} and ${str2}"

攻击者有什么办法可以在上述情况下执行代码？为什么？为什么不？我最初的假设是 GString 的使用总是安全的。请随时证明我错了。请尽可能具体。

更新#1：为了保持讨论的重点，请忽略代码中的任何 HTML-XSS 问题，因为这个问题是关于服务器端的代码执行，而不是客户端。

更新#2：有人指出“过滤掉不需要的字符串通常是个好主意”。虽然过滤掉“潜在的坏字符”肯定可以让您避免某些类别的安全问题，但编写即使没有过滤也安全的代码会更好。您可以将其与 Java JDBC API 中 PreparedStatements 的用法进行比较——正确使用 PreparedStatements 可以保证您免受某些类型的注入攻击。过滤您的 SQL 输入可能会给您相同的结果，但使用 PreparedStatements 严格控制过滤方法恕我直言。

4

5 回答 5

3

No, you won't have any new problems introduced by the GString mechanism, because the formation of GStrings is a "compile time" phenomenon. While their value may be determined (and changed) at run time their form is not.

Another way of looking at it: anything you can do with GStrings could be done with a closure and string concatenation, with exactly the same semantics; GStrings are just syntactic sugar. Unless you are worried about closures (or, heaven forbid, string concatenation) you shouldn't worry about GStrings.

于 2009-04-07T05:17:35.317 回答
0

使用给定的代码示例，不存在安全问题。str1 和 str2 只是调用了它们的 toString 方法，并且 GString 上的默认 toString 方法没有安全漏洞。

除非您（程序作者）为“somePropertyFieldControlledByTheAttacker”定义了 getter 以实际对值的内容进行评估，否则它是安全的。

发生安全漏洞的唯一方法是程序作者添加一个。

于 2009-03-22T20:27:15.597 回答
0

再想一想，看起来你的使用很好，因为你只是评估你定义为变量的局部变量，但字符串仍然必须清除特殊字符，但不是像“System.exit(-1)”这样的东西，因为除非 ${} 在字符串中围绕它，否则它将一直将其视为字符串。

最佳实践似乎是从字符串中删除所有特殊字符，例如“${}”，因为您不必在代码中使用它们就容易受到它们的攻击。

但是，如果它从不以嵌套方式评估字符串，那你很好，所以我不能 100% 确定。

于 2009-03-31T18:23:38.143 回答
0

我相当确定作为参数（在控制器中）传入的对象是纯字符串，因此它们不会在运行时被评估（就像 GStrings 那样）。此外，我做了一些实验，似乎要将这些转换为 GStrings，您需要做一些非常粗糙的工作。这是可行的，但需要很多杂耍。

简而言之，它可能不是安全漏洞。

It's still a really, really, really good idea to strip out special characters, at least in strings where they aren't needed... although determining this is 'left as an exercise to the reader'. But as long as you're conscious that all user-generated data (data pulled from the web or from the DB) is suspect, you'll be a lot safer.

于 2009-04-01T01:57:35.230 回答
0

you may have a cross-site scripting vulnerability in the above code- make sure you call .encodeAsHTML(), or a bad guy can mess with ya.

于 2009-04-01T02:11:41.623 回答