出于好奇，我尝试使用
(.+)进行搜索，并惊讶地得到了所有商品的清单。 我已经阅读了一些有关邪恶正则表达式的信息，但似乎只有在攻击者同时控制搜索条目和搜索输入（即正则表达式）。
考虑到攻击者只能控制搜索输入，我们是否可以认为DOS上的商城指示面板安全？ （不考虑商店可能会被称为“ aaaaaaaaaaaaaa”之类的怪异名称。）
#1 楼
我将接受用户提供的正则表达式与解析大多数结构化用户输入（例如日期字符串或减价）进行比较，以考虑代码执行的风险。正则表达式比日期字符串或markdown复杂得多（尽管从不受信任的markdown安全地生成html有其自身的风险），因此代表了更多的利用空间，但基本原理是相同的：利用涉及发现解析/编译/匹配过程。大多数正则表达式库已经成熟并且是许多语言中标准库的一部分，这很好（但不确定）表明它没有导致代码执行的主要问题。它确实会增加您的攻击面，但是做出有针对性的决定来接受相对较小的风险并非没有道理。
拒绝服务攻击有点棘手。我认为大多数正则表达式库在设计时都考虑到了性能，但并未将缓解故意输入缓慢的问题算作其核心设计目标。从DoS角度来看，接受用户提供的正则表达式是否合适取决于库的更多信息。例如，.NET regex库接受可以用于缓解DoS攻击的超时.RE2保证在与输入大小成线性的时间执行如果您知道自己的搜索语料库在合理范围内。
在可用性绝对重要的情况下，或者您试图尽可能减少攻击面的情况下，避免接受用户正则表达式是有意义的，但是我认为这是一种可取的做法。
评论
是的，超时是缓解DoS的第一件事。即使忽略库支持，在大多数语言/框架中，将搜索分离到后台线程并对该线程进行超时也是相当琐碎的。
–鲍勃
18年8月6日在2:48
@Bob是很简单的，但是停止后台任务不是。例如，在Java之类的语言中，无法强制终止线程，因此，即使超时已过期，您也将无法执行任何操作。
–蜘蛛鲍里斯（Boris）
18年8月6日在6:34
几十年前，当我意识到正则表达式并超越了基础知识开始花哨时，我能够创建一些非常令人讨厌的正则表达式模式。这在很大程度上取决于正则表达式引擎，但是如果您使用的是支持反向引用，超前/后退和/或贪婪量词的引擎，那么将事情停顿下来并不难。当然，您要搜索的字符串的长度会有很大的不同。大型文档上的多行正则表达式确实是一条狗。
– JimmyJames
18年8月6日在14:47
@Nat依赖于协作式多任务处理-即它将取消（true）任务，这将中断（）线程-如果任务是可中断的，则它可能会起作用，但是很可能不会。
–蜘蛛鲍里斯（Boris）
18年8月6日在15:26
这是一个正则表达式的示例，该示例在Java上花费指数执行时间：（0 *）* A
– Philipp
18年8月6日15:32
#2 楼
接受正则表达式的主要威胁将在您的regex执行引擎中，而不是接受regex本身。我希望在任何实施良好的引擎中威胁都非常低。引擎不需要访问任何特权系统资源，而只需要在直接提供给引擎的输入上运行逻辑。这意味着，即使有人在解释器中发现了漏洞，也可以将其造成的损害降到最低。总的来说，所有正则表达式都旨在在值内寻找模式。只要您检查的值遵循适当的安全性，引擎就没有理由自己应该有权修改值。我将其归类为总体上非常安全。
这就是说，我也只会在合理的情况下提供它。正则表达式很复杂，运行起来很耗时，并且在错误的地方使用可能会对安全上下文之外的应用程序产生一些不良影响，但是在正确的用例中，它们非常强大并且具有巨大的价值。 （我是一位软件架构师，经常使用regex重构数十万行代码。）
评论
这不包括通过灾难性的回溯进行的DoS攻击。
–蜘蛛鲍里斯（Boris）
18年8月6日在6:36
@boris我认为，即使在正常使用中，也没有必要以无干扰的方式处理昂贵的正则表达式来应对安全威胁。人们将做出过于复杂的正则表达式语句，而不会经常受到攻击。出于性能原因，不仅仅是安全性，合理的超时是必要的设计决策。这有点像说添加复杂报告的安全隐患是人们可能会通过运行报告来使您的站点DOS。这是性能问题，而不是安全问题。
– AJ亨德森
18年8月6日在12:49
人们使用正则表达式使服务器崩溃，而且我个人知道一个站点有成千上万的用户因这种结构而崩溃。无法同意这种最小的损害，因为他们花了一些时间才能将其恢复在线。
–eis
18年8月7日在16:05
@eis他们是否利用了regex引擎，还是没有正确配置性能安全防护措施，而一系列失控的regex却关闭了服务器以试图解决？我说过利用发动机的风险很低。运行缓慢的查询（即使在dos方面）也是性能方面的问题，因为合法查询还会在没有适当的性能安全防护措施的情况下关闭服务器。
– AJ亨德森
18年8月7日在16:52
@AJHenderson是正确的，因为它是后者，而不是关于利用引擎。但是，即使没有任何利用，我认为即使正则表达式不会修改任何值，最终用户的影响也可能是最小的。
–eis
18年8月7日在18:36
#3 楼
正如其他答案所指出的那样，攻击媒介很可能是正则表达式引擎。尽管您认为这些引擎已经相当成熟，强大并且经过了全面测试，但过去确实发生过：
CVE-2010-1792在Apple Safari和iOS中执行任意代码。
引用补丁说明：
存在内存损坏问题WebKit处理正则表达式。访问恶意制作的网站可能
导致应用程序意外终止或任意代码
执行。
但是，当然，可能存在缺陷的库的论点支持一切-甚至是用户提供的JPEG文件。
您提到的
(.+)情况，尽管不是技术上的固有问题，另一方面是：该产品应允许任意数据检索吗？#4 楼
问题是正则表达式引擎“回溯”。当您在正则表达式中执行复制操作（例如+或*）时，正则表达式引擎将尝试使其与尽可能多的输入字符串匹配。如果以后匹配失败，它将回溯并尝试将您的描述与输入字符串的一小部分进行匹配。多次替换操作可能导致嵌套回溯，这可能导致需要花费时间来评估正则表达式大量爆发，特别是如果重复运算符嵌套的话。
https://www.regular-expressions.info/catastrophic.html
评论
并非所有的正则表达式引擎都可以回溯（尽管大多数都可以）。回溯的替代方法是同时考虑所有可能性，直到找到可行的方法。实施起来比较困难，但避免了病理情况。参见swtch.com/~rsc/regexp/regexp1.html
– kbolino
18年8月8日在22:49
#5 楼
不，ReDoS不需要攻击者制作不自然的搜索结果。ReDoS的基本思想是，您有一个子表达式可以以多种方式匹配，并且几乎可以在搜索到的字符串中的任何地方匹配最后，您迭代该子表达式以获得灾难性的回溯。因此，例如，如果您的商店描述为
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.，则可以使用([^q]|[^q][^q])+之类的东西（或更复杂的结构，例如前瞻）。限制正则表达式引擎可用的时间。评论
我要提到的是，有一些regexp实现不回溯-避免了这个问题。
–塔米尔
18年8月8日在10:47
RE2已在另一个答案中提及。不过，它并不是真正的实现，它是语言的安全子集-因此，与PCRE之类的东西相比，您将失去功能（可以说，产品搜索表单中没有人关心的功能）。
– Tgr
18年8月8日在15:11
#6 楼
简短答案...否。不管它是否为正则表达式，它仍然是用户提供的数据，并且永远不要被信任。标准做法是正确验证所有用户提供的数据...总是！如果您希望允许用户使用正则表达式，则应将用户正则表达式与允许的正则表达式白名单进行比较。您希望使该脚本可用。这样，您将永远不会直接使用用户发送的正则表达式，并且如果它与白名单中的正则表达式不匹配，则可以退出脚本。我可以想到的唯一允许正则表达式作为用户输入的安全方法。
评论
不知道为什么这被否决了。小鲍比桌的故事没动过谁？ ;）
–nick012000
18年8月9日在14:01
如果您特别想允许用户输入任意正则表达式（考虑带有正则表达式选项的搜索输入），那么此答案就没有用了。验证正则表达式是什么意思？不这样做的后果是什么？
–巨石
18年8月10日在4:59
我认为对我的答案投反对票，而不显示出一旦服务器端您打算如何处理此正则表达式，这是不公平的，就像上面我给出的答案一样。如果您以某种方式建议您未经验证就将用户正则表达式（带有特殊字符）传递到您的服务器上...祝您好运！
–主显节
18年8月15日在8:10
评论
如果用户可以输入正则表达式，并且使用的是一种解释语言，那么我就不用担心DOS。我会担心代码注入。我不希望将购物中心地图设计为可能使用正则表达式的老练用户。因此，如果正则表达式正常工作，则表明该应用程序有点盲目地将输入字符串传入。这通常是尝试各种形式的代码和SQL注入的地方。那个很小的声音说“我敢打赌他们不是故意这样做的……”使天线振作起来。这是评论，而不是答案，因为（对我来说）这里没有足够的信息可以说比这更准确的信息。
尽管出于安全考虑，我还是希望在大型购物中心的指示面板中执行RegEx过滤！
您是否测试了任何应获取匹配项的正则表达式，以确定其实际使用的正则表达式？如果要设计购物中心搜索，如果搜索结果为空，我会列出所有商店。用户正在尝试娱乐（像您一样），结果并不重要，或者用户不擅长使用搜索功能，因此他们应该会看到可能对他们有用的东西。
搜索字段也可能忽略任何标点符号，并被编程为返回所有商店以进行基本为空的查询。