有邪恶的球体吗? [英] Are there evil globs?

查看:144
本文介绍了有邪恶的球体吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已阅读过有关EvEx RegExp的内容,通常可以确保在处理与RegExp相关的用户输入时具有基本的安全性。



我不确定关于这个问题是否也出现在Glob中。我想它会归结为Glob'ing的各个实现,并且在我使用的 https:/ /github.com/gobwas/glob/



我很感激任何有关如何测试此问题的建议,以及可能如何减轻此问题的建议。

解决方案

通过邪恶的正则表达式,我认为你的意思是一个正则表达式成为灾难性回溯的牺牲品。 b

从你所描述的看来,你似乎在使用glob库来避免这些邪恶的正则表达式。 Globs本质上是一个较弱版本的正则表达式。



这里缺少的东西是正则表达式不一定是邪恶的。这可以在普通的Go中证明,没有外部库。



尝试运行这个Go程序:

<$ p $ (
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上使用PCRE ://regex101.com/#pcre ),但结果将是以下两件事之一:


  • 超时

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



是的,该组合在大多数正则表达式中引起灾难性的回溯。但不是 Go。为什么?



Go没有为其正则表达式使用回溯,所以它甚至不可能。根据本网站


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


详细了解回溯引擎和非回溯引擎之间的差异这里






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


I've read about Evil RegExp and usually ensure a basic level of safety is in place when dealing with user input with regards to RegExp.

What I am unsure about is whether this issue is also present in Glob. I imagine it will come down to the individual implementations of Glob'ing' and in my particular instance I am using https://github.com/gobwas/glob/

I'd appreciate any advice available for how to test for this issue and potentially how to mitigate against it.

解决方案

By "evil regex" I assume you mean a regex that falls victim to catastrophic backtracking.

From what you're describing, it seems like you're using a glob library to avoid these "evil regexes". Globs are essentially a weaker version of regex.

The thing that you're missing here is the fact that regexes don't have to be evil. This can be proven in plain Go, with no external libraries.

Try running this Go program:

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, ""))
}

You might wonder why this code doesn't measure how much time execution took. It's because it's not needed (and also because I don't know much Go).

The regex will work in almost all regex flavors. You can try running it in Java, Perl or another similar flavor (I like using PCRE on https://regex101.com/#pcre), but the outcome will be one of two things:

  • A timeout
  • You get fed up with how long it's taking and stop the program

Yes, that combination causes catastrophic backtracking in most regex flavors. But not Go. Why?

Go doesn't use backtracking at all for its regexes, so it's not even a possibility. According to this site:

In Go, we find an optimized regular expression engine. This runs in linear time, making complex patterns faster. It is located in the regexp package.

Read more about the differences between backtracking and non-backtracking engines here.


Considering the glob library (according to that GitHub link) appears faster than Go's regexps, performance shouldn't be a problem.

这篇关于有邪恶的球体吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆