将用户参数作为服务端Shell命令部分是否危险？Rails应用安全问询

你的代码直接把用户输入的phrase参数拼进了shell命令里（用反引号执行espeak "#{params['phrase']}"），这属于命令注入漏洞，风险极高。

举个直白的例子，如果有人在文本框里输入：

"; rm -rf /; echo "

那实际执行的shell命令会变成：

espeak ""; rm -rf /; echo ""

这会直接删除系统根目录下的所有文件——对于树莓派服务器来说，这几乎是毁灭性的破坏。如果你的Rails进程是以高权限（比如root）运行的，后果不堪设想。

哪怕是给朋友用，也不能低估风险：万一有人手滑输入了恶意内容，或者账号被盗用，都会出大问题。

修复方案，按优先级排序： #

1. 用安全的方式调用系统命令 #

绝对不要用字符串拼接的方式执行shell命令，改用Ruby提供的数组参数形式调用system方法，这样Ruby会直接把参数传递给espeak进程，不会经过shell解析，从根源上避免命令注入：

def speak
  # 数组形式调用，参数会被安全传递，不会被shell解析
  system('espeak', params['phrase'])
end

2. 严格验证和过滤用户输入 #

在执行命令前，先对输入内容做校验，只允许合法的字符（比如字母、数字、常用标点和空格），拒绝不符合规则的输入：

def speak
  phrase = params['phrase']
  # 只允许字母、数字、空格和常用标点，可根据需求调整正则
  if phrase.match?(/\A[\w\s.,!?'-]+\z/)
    system('espeak', phrase)
  else
    # 返回错误提示，比如在JS响应里告诉用户输入不合法
    render json: { error: "输入包含非法字符，请重新输入" }, status: :bad_request
  end
end

3. 限制Rails进程的运行权限 #

不要用root用户启动你的Rails应用，创建一个权限极低的专用用户（比如rails-app）来运行服务。这样就算出现意外，恶意命令能做的破坏也会被限制在该用户的权限范围内。

4. 添加身份验证（针对多人使用场景） #

如果未来要给一群朋友用，一定要加身份验证（比如用Devise、Authlogic这类成熟的gem），只有登录的授权用户才能访问这个朗读功能，避免陌生人随意调用接口。

内容的提问来源于stack exchange，提问作者ivanibash