通过任意文件上传在 ASP.NET 后端 (IIS) 进行服务器端注入
Server side injection on ASP.NET backend (IIS) by arbitrary file upload
我不是网络安全和漏洞利用方面的专家。我需要帮助来确定我的应用程序是否易受攻击以及以何种方式存在。
假设我是个白痴（我还没有到这种程度），我让客户端用户可以上传（利用我的前端）他们想要在我的服务器上的子文件夹中的任何文件（我们称它为我的 ASP.NET 应用程序的 'danger')，托管在 IIS 上。
这样一来，任何人都可以上传通用 example.hml 文件并在 url mydomain.com/danger/example.html 中访问它。他们还可以上传 JS 文件和任何他们想要的东西。
让我们暂时忘记它们可以填满我的磁盘这一事实。
如果我阻止 ASP 从该文件夹中的文件执行，我会受到什么样的损害？
提前致谢。
嗯，是的，如果您允许任何类型的预览，或者说允许该人下载文件，那么您必须小心，但是当您下载时，您也会尝试在服务器上进行某种预览。
事实上，这与将一个简单的文本框放入表单中，然后让用户在该文本框中输入信息，然后点击提交按钮，然后重新显示包含他们刚刚输入内容的页面。
如果他们开始在该文本框中输入 javascript 文本会怎样？
说一个多行文本框，您可以在其中输入一段评论或文本。
所以，你输入这个：
Hellow how are you
<script>
JavaScript code here
</script>
现在，当您重新绘制页面时 - 不仅会重新显示输入的内容，而且输入的那些脚本代码也会 运行!
事实上，如果您在网页上放置一个文本框，然后执行以下操作：
Hello, how <script> are you
您注意到页面执行错误。 （因为 asp.net 内置了不允许这样做的保护）。但是，如果您采用某些 html 编辑器文本框（ckEdit 或 ajaxtoolkit 编辑器），此类控件将具有额外的安全代码以防止最终用户键入脚本代码。
因此，您需要注意以下几点：
如果您允许上传文件，请确保您没有尝试 load/execute 该文件的代码。因此，您可能允许用户上传 pdf 文件，然后可能是尝试“打开”或使用该文件的例程。但是如果他们代替 pdf 文件上传 MyTest.exe 会发生什么。换句话说，他们上传了一个可执行程序来代替 pdf？好吧，那么你基本上没问题，但你最好不要尝试加载此类文件的代码 - 特别是背后的代码可能会使用一些库或代码，这些库或代码实际上会启动该 pdf 或 word 或 exec 文件。由于该代码可能会尝试加载或 运行 现在是 .exe 程序。
所以，这意味着一些事情：
You want to limit the file extensions allowed
You need to ensure that your code does not "execute" that up-load file
If you allow download of that file, then careful how you do this
(again, ensure that you don't open up possibiity to execute that file).
因此，在大多数情况下您应该没问题，但如果上传的文件由您的服务器端代码进一步处理，那么请注意您如何打开或处理此类上传的文件。
如前所述，假设用户上传一个简单的文本文件，上传后您从该文件中获取文本，然后将其显示在网页的某种备忘录或文本框中。但是，你确定它只是那个文件中的文本吗？如果您从该文件中提取内容，然后将其呈现在您的浏览器中（因为您假定为文本），但它现在可能会将浏览器代码注入到该文本文件中。
因此，服务器端代码中打开上传文件、提取内容然后吐出该内容以显示数据的任何点都是一个警告区域。
那么，第一道简单的防线呢？
限制文件类型。如果希望用户只上传 PDF 文件，则只允许说 PDF 和 .zip 文件扩展名 - 拒绝任何其他文件。
如前所述，请记住上传该文件后 运行s 的任何类型的 post 处理代码。如果您的站点正在使用此类上传的文件，并且要打开文件，然后将该内容显示给最终用户，那么再次需要谨慎，因为当您在浏览器中显示此类内容时，理论上的内容可以有脚本代码——就像你的代码向浏览器吐出的任何其他东西一样（比如带有 HTML 等的网页）也意味着浏览器将 运行 该脚本代码。
我的意思是，浏览器简单地接收服务器发送给该浏览器的任何内容，并呈现 HTML。然而，如今，浏览器在该浏览器中也有更多 运行 编码的能力。所以，这就是为什么现在你可以说 运行 酷游戏 100% 在浏览器中，因为浏览器已经成为非常强大的系统，并且几乎拥有自己的计算机系统。因此，浏览器能够 运行 编码并提供在速度和响应（甚至互动游戏）方面与桌面相媲美的体验是浏览器现在能够 运行 编码并执行的结果更多然后只显示一些简单的 HTML.
因此，在任何情况下，您都不应允许上传文件，然后使用一些软件可以“运行”甚至提取该文件的内容并将其返回给用户浏览器显示形式。原因是文件内容很可能在该文件内容中包含可执行代码。
就在我的脑海里：
攻击者可能会上传损坏的文件，这会触发防病毒软件中的远程代码执行漏洞，可能会在 local system 帐户下执行代码。 （我在 Windows Defender 中看到过这种情况，我在其他 AV 产品中也看到过类似漏洞的报告。）
他们可以上传一个名称被破坏的文件，该文件利用 IIS 中的错误来绕过您的文件类型检查和文件夹上的“不执行”标志。 （我看到过这个报道，尽管是在非常旧的 IIS 版本中。）
如果可以公开访问这些文件，它们可能会在您的网站上托管自己的内容，其中可能包括非法或恶意内容。这可能会损害您网站的声誉，并可能使您受到起诉。
我不是网络安全和漏洞利用方面的专家。我需要帮助来确定我的应用程序是否易受攻击以及以何种方式存在。
假设我是个白痴（我还没有到这种程度），我让客户端用户可以上传（利用我的前端）他们想要在我的服务器上的子文件夹中的任何文件（我们称它为我的 ASP.NET 应用程序的 'danger')，托管在 IIS 上。 这样一来，任何人都可以上传通用 example.hml 文件并在 url mydomain.com/danger/example.html 中访问它。他们还可以上传 JS 文件和任何他们想要的东西。
让我们暂时忘记它们可以填满我的磁盘这一事实。
如果我阻止 ASP 从该文件夹中的文件执行，我会受到什么样的损害？
提前致谢。
嗯，是的，如果您允许任何类型的预览，或者说允许该人下载文件，那么您必须小心，但是当您下载时，您也会尝试在服务器上进行某种预览。
事实上，这与将一个简单的文本框放入表单中，然后让用户在该文本框中输入信息，然后点击提交按钮，然后重新显示包含他们刚刚输入内容的页面。
如果他们开始在该文本框中输入 javascript 文本会怎样？
说一个多行文本框，您可以在其中输入一段评论或文本。
所以，你输入这个：
Hellow how are you
<script>
JavaScript code here
</script>
现在，当您重新绘制页面时 - 不仅会重新显示输入的内容，而且输入的那些脚本代码也会 运行!
事实上，如果您在网页上放置一个文本框，然后执行以下操作：
Hello, how <script> are you
您注意到页面执行错误。 （因为 asp.net 内置了不允许这样做的保护）。但是，如果您采用某些 html 编辑器文本框（ckEdit 或 ajaxtoolkit 编辑器），此类控件将具有额外的安全代码以防止最终用户键入脚本代码。
因此，您需要注意以下几点：
如果您允许上传文件，请确保您没有尝试 load/execute 该文件的代码。因此，您可能允许用户上传 pdf 文件，然后可能是尝试“打开”或使用该文件的例程。但是如果他们代替 pdf 文件上传 MyTest.exe 会发生什么。换句话说，他们上传了一个可执行程序来代替 pdf？好吧，那么你基本上没问题，但你最好不要尝试加载此类文件的代码 - 特别是背后的代码可能会使用一些库或代码，这些库或代码实际上会启动该 pdf 或 word 或 exec 文件。由于该代码可能会尝试加载或 运行 现在是 .exe 程序。
所以，这意味着一些事情：
You want to limit the file extensions allowed
You need to ensure that your code does not "execute" that up-load file
If you allow download of that file, then careful how you do this
(again, ensure that you don't open up possibiity to execute that file).
因此，在大多数情况下您应该没问题，但如果上传的文件由您的服务器端代码进一步处理，那么请注意您如何打开或处理此类上传的文件。
如前所述，假设用户上传一个简单的文本文件，上传后您从该文件中获取文本，然后将其显示在网页的某种备忘录或文本框中。但是，你确定它只是那个文件中的文本吗？如果您从该文件中提取内容，然后将其呈现在您的浏览器中（因为您假定为文本），但它现在可能会将浏览器代码注入到该文本文件中。
因此，服务器端代码中打开上传文件、提取内容然后吐出该内容以显示数据的任何点都是一个警告区域。
那么，第一道简单的防线呢？
限制文件类型。如果希望用户只上传 PDF 文件，则只允许说 PDF 和 .zip 文件扩展名 - 拒绝任何其他文件。
如前所述，请记住上传该文件后 运行s 的任何类型的 post 处理代码。如果您的站点正在使用此类上传的文件，并且要打开文件，然后将该内容显示给最终用户，那么再次需要谨慎，因为当您在浏览器中显示此类内容时，理论上的内容可以有脚本代码——就像你的代码向浏览器吐出的任何其他东西一样（比如带有 HTML 等的网页）也意味着浏览器将 运行 该脚本代码。
我的意思是，浏览器简单地接收服务器发送给该浏览器的任何内容，并呈现 HTML。然而，如今，浏览器在该浏览器中也有更多 运行 编码的能力。所以，这就是为什么现在你可以说 运行 酷游戏 100% 在浏览器中，因为浏览器已经成为非常强大的系统，并且几乎拥有自己的计算机系统。因此，浏览器能够 运行 编码并提供在速度和响应（甚至互动游戏）方面与桌面相媲美的体验是浏览器现在能够 运行 编码并执行的结果更多然后只显示一些简单的 HTML.
因此，在任何情况下，您都不应允许上传文件，然后使用一些软件可以“运行”甚至提取该文件的内容并将其返回给用户浏览器显示形式。原因是文件内容很可能在该文件内容中包含可执行代码。
就在我的脑海里：
攻击者可能会上传损坏的文件，这会触发防病毒软件中的远程代码执行漏洞，可能会在 local system 帐户下执行代码。 （我在 Windows Defender 中看到过这种情况，我在其他 AV 产品中也看到过类似漏洞的报告。）
他们可以上传一个名称被破坏的文件，该文件利用 IIS 中的错误来绕过您的文件类型检查和文件夹上的“不执行”标志。 （我看到过这个报道，尽管是在非常旧的 IIS 版本中。）
如果可以公开访问这些文件，它们可能会在您的网站上托管自己的内容，其中可能包括非法或恶意内容。这可能会损害您网站的声誉，并可能使您受到起诉。