bash - 从 bash 中不受信任的输入构建命令行时，有没有办法防止注入(inject)攻击？

Question

我有一个 Bash 脚本运行并使用 jq 解析用户提供的 JSON 文件的情况。 .由于它是由用户提供的，因此他们可以在 JSON 中包含值以执行注入(inject)攻击。

我想知道是否有办法克服这个问题。请注意，无法更改“我的脚本解析用户提供的 JSON 文件”的设置，因为它不在我的控制范围内。我唯一能控制的就是 Bash 脚本。

我试过使用 jq有和没有 -r标志，但在每种情况下，我都能够成功注入(inject)。

这是 Bash 脚本目前的样子:

#!/bin/bash

set -e

eval "INCLUDES=($(cat user-supplied.json | jq '.Include[]'))"
CMD="echo Includes are: "
for e in "${INCLUDES[@]}"; do
    CMD="$CMD\\\"$e\\\" "
done

eval "$CMD"

这是一个示例 user-supplied.json演示注入(inject)攻击的文件:

{
  "Include": [
    "\\\";ls -al;echo\\\""
  ]
}

上面的 JSON 文件导致输出:
Includes are: ""
，后跟目录列表(实际攻击可能会更加恶意)。

我想要的是输出如下内容:
Includes are: "\\\";ls -al;echo\\\""

编辑 1

我用了echo作为脚本中的示例命令，这可能不是最好的示例，因为解决方案根本不使用 eval .

然而，实际需要的命令是 dotnet test ，以及来自 Includes 的每个数组项需要使用 /p:<Includes item> 作为选项传递.我所希望的是一种无论命令如何都能全局中和注入(inject)的方法，但也许这是不可能的，即你所采用的技术在很大程度上依赖于实际命令。

Answer 1

您不需要使用 eval对于 dotnet test任何一个。 POSIX sh 中不存在的许多 bash 扩展专门用于制作 eval不需要使用；如果你认为你需要eval对于某些内容，您应该提供足够的详细信息，让我们解释为什么实际上不需要它。 :)

#!/usr/bin/env bash
#              ^^^^- Syntax below is bash-only; the shell *must* be bash, not /bin/sh

include_args=( )
IFS=$'\n' read -r -d '' -a includes < <(jq -r '.Include[]' user-supplied.json && printf '\0')
for include in "${includes[@]}"; do
  include_args+=( "/p:$include" )
done

dotnet test "${include_args[@]}"

稍微谈谈正在发生的事情:

• IFS=$'\n' read -r -d '' -a arrayname读取标准输入中的下一个 NUL 字符(-d 指定要停止的单个字符；由于 C 字符串以 NUL 结尾，空字符串中的第一个字符是 NUL 字节)，在换行符处拆分，并将结果放入进入arrayname .

  在 bash 4.0 或更高版本中写这个的更短的方法是 readarray -t arrayname ，但这并没有让您检测生成输入的程序是否失败的优势:因为我们有 && printf '\0'附于jq代码，NUL 终止符 this read expects 仅在 jq 时出现成功，从而导致 read的退出状态仅在 jq 时反射(reflect)成功也报告成功。

• < <(...)正在从 process substitution 重定向标准输入，它被一个文件名替换，当从中读取时，返回运行代码 ... 的输出.
• 我们可以设置include_args+=( "/p:$include" )的原因并使其与 include_args+=( /p:"$include" ) 完全相同是引号由 shell 本身读取并用于确定在何处执行字符串拆分和通配符；它们不会保留在生成的内容中(因此后来传递给 dotnet test )。

一些其他有用的引用:

• BashFAQ #50 : 我试图将命令放入变量中，但复杂的情况总是失败! -- 深入解释了为什么你不能将命令存储在字符串中而不使用eval ，并描述了可以改用的更好做法(将命令存储在函数中；将命令存储在数组中；等等)。
• BashFAQ #48 : Eval 命令和安全问题 -- 详细说明为什么 eval受到广泛反对。