我有一个powershell脚本(但我认为这些考虑因素可以扩展到任何需要运行时来解释和执行它的脚本)，它做我还需要作为要调用的REST API向web应用程序前端公开的事情，并且我被要求从web方法直接调用脚本本身，在我看来，使用一个启动shell/进程来执行脚本并重定向stdin/stdout/stderr的webapi方法是一种非常糟糕的做法。这样做会有任何特定的安全风险吗？
阅读这个问题会让人想起它会使您的网站暴露在OWASP十大安全漏洞中的多少。
-
注射缺陷-这绝对是一个高风险。当然，有一些方法可以补救。用强类型的日期和数字而不是字符串参数化所有输入是一种可以使用的方法，但它可能不适合您的业务案例。您永远不应该允许执行用户提供的代码，但如果您接受字符串作为输入并根据该输入运行脚本，则很难阻止任意代码的执行。
-
身份验证已损坏-可能存在漏洞。如果您强制用户在访问脚本之前进行身份验证(您可能应该这样做)，则用户可能会在其他地方重复使用他们的凭据，并将这些凭据暴露给暴力攻击。尝试太多次后，你会锁定帐户吗？您有双因素身份验证吗？你允许弱密码吗？在引入新的身份验证机制时，这些都是需要考虑的因素。
-
敏感数据暴露-可能存在漏洞，具体取决于您的脚本。脚本是否允许读取文件并返回其内容？如果不是现在，将来会这样做吗？即使它从未被设计成这样做，结合其他漏洞，该脚本也可能能够从web目录之外的路径读取文件。很难防止目录遍历漏洞，因为它会允许恶意用户访问您的服务器，甚至整个网络。编译后的代码和web服务器在许多情况下都可以防止这种情况的发生。
-
XML外部实体-可能存在漏洞，具体取决于您的需求。如果允许用户提供的XML，坏人可能会注入其他文件并造成严重破坏。当您使用标准web工具时，这更容易陷入陷阱。
-
访问控制中断-绝对易受攻击。Web API应用程序可以强制执行用户控制，并在C#控制器中设置权限级别。异常使用HTTP状态代码进行处理，这些代码表示不允许该请求。相比之下，Powershell在登录用户的安全上下文中执行，即使没有升级运行，也允许系统级别的更改。如果利用注入漏洞，代码将在web服务器的安全上下文中执行，而不是在用户的上下文中执行。你可能会惊讶于IIS_USER(或其他应用程序池服务帐户)能做这么多。首先，如果坏人是在服务帐户的上下文中执行的，他们可能会通过锁定该帐户或更改密码来通过一个请求关闭整个网站-使用Powershell脚本比使用编译的C#代码更容易完成这项任务。
-
安全配置错误-可能存在漏洞。一个正在运行的脚本将需要它自己的安全配置，在您为Web API使用的任何框架之外。您准备好重新实现OAuth声明或ACL之类的东西了吗？
-
跨站点脚本-可能存在漏洞。您是否在回显脚本输出？如果你不清理输入和输出，脚本可能会回显一些Javascript，它会将用户的cookie内容发送到恶意服务器，让他们可以访问用户的所有资源。如果输入未经验证，跨站点请求伪造也是一种风险。
-
不安全的反序列化-可能不易受攻击。
-
使用具有已知漏洞的组件-与编译的相比，漏洞大大增加。Powershell授予对一整套库的访问权限，否则这些库在编译的应用程序中需要显式引用。
-
日志记录不足&监控-可能很脆弱。默认情况下，IIS会记录请求，但Powershell不会记录任何内容，除非您明确写入文件或启动脚本。这两种方法都不是为并发而设计的，可能会给共享文件带来性能或功能问题。
简而言之，前10个漏洞中有9个可能会影响此实现。我希望这至少足以阻止你公开你的剧本。基本上，问题是你使用该工具(Powershell)的目的不是为了实现它。