validation - 这些 tcl 错误是否表示代码不安全？

Question

我正在对具有嵌入式 TCL 解释器的系统进行安全测试。系统从 Internet (HTTP) 接收输入，对其进行解析并传递给可定制的 TCL 脚本。在模糊测试(在 HTTP header 中发送二进制垃圾)期间，我注意到日志中存在以下错误:

TCL error: list element in quotes followed by "{}x" instead of space while executing "foreach header [ XXXXX ] { }"

或

TCL error: unmatched open quote in list while executing "foreach header [ XXXXX ] {}"

这里的 XXXXX 是一个返回 HTTP header 数组的命令，由系统解析。很抱歉混淆了真正的命令，我希望你明白我不想在供应商被告知这个问题之前公开太多细节(如果结果证明这是一个问题)。

产生错误的 TCL 代码非常简单:

foreach header [ XXXXX ] { }

据我所知，HTTP 解析是在 TCL 之外完成的，并且 TCL 可以通过自定义命令访问解析后的值(可能作为 TCL 扩展实现)。

所以我的问题是:

1. 这些错误是否表明系统存在安全问题，例如用户输入验证不足？

2. 如果是，是否可以利用此条件通过发送系统特制请求(一种 code injection attack)来执行任意 TCL 语句?

3. 是否有任何“安全 TCL 编码实践”文档？我找不到。

Answer 1

你在 comp.lang.tcl 上问过这个问题我在那里回答:

1) Are these error tell-tale signs of security problems with the system, such as insufficient user input validation?

它们表明解析代码存在问题。我猜该代码假设它可以假设标题是格式正确的Tcl 列表，您发现它完全不安全。 sanitizer 是为了使用这样的东西:

set listOfWords [regexp -all -inline {\S+} $someString] 

生成的单词集合保证是格式正确的列表，用于任意输入字符串。

2) If yes, can this condition be exploited to execute arbitrary TCL statements by sending the system specially crafted request, a kind of http://en.wikipedia.org/wiki/Code_injection attack?

可能不会，除非您随后将该列表视为代码。

3) Are there any "Secure TCL coding practices" document? Any other source of information on how to safely handle untrusted data?

最简单的方法是在安全解释器中进行解析:

interp create -safe parsingInterp 
parsingInterp eval { make the procedures } 
parsingInterp eval [list doTheParse $stringToParse] 

请注意，我们还保证构建的列表(例如，那些来自list，以及除此之外的许多其他命令)都是 eval 安全的。即:

eval [list $a $b $c] 

完全相同于:

$a $b $c 

无论这些变量是什么，这都是真的。