【问题标题】:Are there evil globs?有邪恶的球吗?
【发布时间】:2016-11-18 12:03:00
【问题描述】:

我已经阅读过 Evil RegExp 的相关信息,并且在处理有关 RegExp 的用户输入时,通常会确保基本的安全水平。

我不确定 Glob 中是否也存在此问题。我想这将归结为 Glob'ing' 的各个实现,在我的特定实例中,我使用的是 https://github.com/gobwas/glob/

对于如何测试此问题以及可能如何减轻该问题的任何建议,我将不胜感激。

【问题讨论】:

  • 确保限制 glob 的大小,应该没问题。
  • 仅供参考,如果“邪恶的正则表达式”是指一个可能导致无限递归回溯的表达式,那么在 Go 中您不必担心这一点。标准库中的 regexp 包使用有限状态自动机正确实现正则表达式,因此它永远不必回溯(以不支持您可能实际上并不需要的某些功能为代价)。欲了解更多信息,请参阅:swtch.com/~rsc/regexp/regexp1.html

标签: regex security go glob


【解决方案1】:

“邪恶的正则表达式”我假设你的意思是一个成为灾难性回溯受害者的正则表达式。

根据您的描述,您似乎正在使用 glob 库来避免这些“邪恶的正则表达式”。 Glob 本质上是正则表达式的弱版本。

您在这里缺少的是正则表达式不一定是邪恶的事实。这可以在没有外部库的普通 Go 中得到证明。

尝试运行这个 Go 程序:

package main

import (
    "fmt"; "regexp"
)

func main() {
    reg := regexp.MustCompile(`^([^z]*?,){11}P`)

    txt := `1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18zP`

    fmt.Println(reg.ReplaceAllString(txt, ""))
}

您可能想知道为什么这段代码没有测量执行所花费的时间。这是因为不需要它(也因为我不太懂 Go)。

正则表达式几乎适用于所有正则表达式风格。您可以尝试在 Java、Perl 或其他类似风格中运行它(我喜欢在 https://regex101.com/#pcre 上使用 PCRE),但结果将是以下两种情况之一:

  • 超时
  • 您厌倦了需要多长时间并停止程序

是的,这种组合在大多数正则表达式风格中都会导致灾难性的回溯。但是去。为什么?

Go 的正则表达式完全不使用回溯,所以这甚至是不可能的。根据this site

在 Go 中,我们找到了一个优化的正则表达式引擎。这以线性时间运行,使复杂的模式更快。它位于 regexp 包中。

详细了解回溯引擎和非回溯引擎之间的区别here


考虑到 glob 库(根据那个 GitHub 链接)看起来比 Go 的正则表达式更快,性能应该不是问题。

【讨论】:

  • 你确定没有办法用难以转化为状态机的大型正则表达式来攻击优化器吗?
  • @Bergi 我不确定你在问什么。如果正则表达式的大小是可变的(通常不是),则为 O(m*n),其中一个是正则表达式长度,另一个是输入长度。如果您询问正则表达式编译器是否在编译正则表达式时遇到问题,我对此表示怀疑(这将是 Go 的一个错误)。只要正则表达式有效,引擎就应该没问题。
  • @Laurel 这是个好消息,又是 GoLang 框中的一个勾号。我实际上是出于 UX 原因使用 Glob,该模式需要由非技术人员添加。让我阅读参考资料,我会接受答案。谢谢!!
猜你喜欢
  • 2011-01-02
  • 1970-01-01
  • 2011-12-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-11-26
  • 2020-08-10
  • 2010-12-23
相关资源
最近更新 更多