具有查询字符串篡改的 XSS 攻击生成异常
XSS attack with querystring tampering generates exception
我在 asp.net 4.5 中托管了一个站点。我收到了一些来自特定 URL.
的异常
异常：
"Could not load file or assembly 'http' or one of its dependencies. The system cannot find the file specified."
URL
"default.aspx?_TSM_CombinedScripts_=http://some-inexistent-website.acu/some_inexistent_file_with_long_name?.123,%20Culture=neutral,%20PublicKeyToken=28f01b0e84b6d53e:en-US:e669ce41-1aa1-4541-aae9-fa5dc37e70db:475a4ef5:effe2a26:7e63a579&_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField"
我认为有人在我的网站上尝试了带有恶意 link 的 XSS。
我检查了页面的查看源代码，发现 AjaxToolKit 创建了与下面类似的 src link，它在浏览器中完美加载，没有错误。
default.aspx?_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField&_TSM_CombinedScripts_=%3B%3BAjaxControlToolkit%2C%20Version%3D4.5.7.123%2C %20Culture%3Dneutral%2C%20PublicKeyToken%3D28f01b0e84b6d53e%3Aen-US%3Ae669ce41-1aa1-4541-aae9-fa5dc37e70db%3A475a4ef5%3Aeffe2a26%3A7e63a579
区别在于 "some-inexistent-website.acu/some_inexistent_file_with_long_name?.123," 和 "AjaxControlToolkit" URL。
在以前的 URL 中，如果我将“some-inexistent-website.acu/some_inexistent_file_with_long_name?.123”替换为“AjaxControlToolkit" 然后它工作正常。
如何处理这种类型的恶意link以免产生异常？
我想 return 在 URL 中有“_TSM_CombinedScripts”部分但没有“[=37=” ]AjaxControlToolkit”在其中。
这是最好的解决方法吗？
我可以通过其他方式防止此类 URL 产生异常吗？
看起来攻击者正在寻找某种远程文件包含攻击，但这看起来不像是非常复杂的攻击，可能是一些自动脚本试图在任何地方注入他能注入的一切.
但无论如何，我想知道 - 为什么您要如此努力地防止错误输入导致的错误？防止这个特定错误不会有任何好处，可能有成千上万种其他方法会导致您的应用程序出错，只要您不透露详细的错误消息并将用户重定向到一般错误页面，这就完全没问题这不会揭示错误的原因（您可以显示与日志记录相对应的自动递增代码以提供支持）。
在最极端的情况下，如果有人生成异常来轰炸您的日志，您可以尝试使用抗 DDoS 和节流解决方案来防止泛洪。
我已将 ToolScriptManager 替换为 ScriptManager，因为最新的 scriptmanager 已得到增强以合并 ToolScriptManager 的功能。
这对我来说解决了这个问题。
我在 asp.net 4.5 中托管了一个站点。我收到了一些来自特定 URL.
的异常异常： "Could not load file or assembly 'http' or one of its dependencies. The system cannot find the file specified."
URL "default.aspx?_TSM_CombinedScripts_=http://some-inexistent-website.acu/some_inexistent_file_with_long_name?.123,%20Culture=neutral,%20PublicKeyToken=28f01b0e84b6d53e:en-US:e669ce41-1aa1-4541-aae9-fa5dc37e70db:475a4ef5:effe2a26:7e63a579&_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField"
我认为有人在我的网站上尝试了带有恶意 link 的 XSS。
我检查了页面的查看源代码，发现 AjaxToolKit 创建了与下面类似的 src link，它在浏览器中完美加载，没有错误。
default.aspx?_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField&_TSM_CombinedScripts_=%3B%3BAjaxControlToolkit%2C%20Version%3D4.5.7.123%2C %20Culture%3Dneutral%2C%20PublicKeyToken%3D28f01b0e84b6d53e%3Aen-US%3Ae669ce41-1aa1-4541-aae9-fa5dc37e70db%3A475a4ef5%3Aeffe2a26%3A7e63a579
区别在于 "some-inexistent-website.acu/some_inexistent_file_with_long_name?.123," 和 "AjaxControlToolkit" URL。
在以前的 URL 中，如果我将“some-inexistent-website.acu/some_inexistent_file_with_long_name?.123”替换为“AjaxControlToolkit" 然后它工作正常。
如何处理这种类型的恶意link以免产生异常？
我想 return 在 URL 中有“_TSM_CombinedScripts”部分但没有“[=37=” ]AjaxControlToolkit”在其中。
这是最好的解决方法吗？
我可以通过其他方式防止此类 URL 产生异常吗？
看起来攻击者正在寻找某种远程文件包含攻击，但这看起来不像是非常复杂的攻击，可能是一些自动脚本试图在任何地方注入他能注入的一切.
但无论如何，我想知道 - 为什么您要如此努力地防止错误输入导致的错误？防止这个特定错误不会有任何好处，可能有成千上万种其他方法会导致您的应用程序出错，只要您不透露详细的错误消息并将用户重定向到一般错误页面，这就完全没问题这不会揭示错误的原因（您可以显示与日志记录相对应的自动递增代码以提供支持）。
在最极端的情况下，如果有人生成异常来轰炸您的日志，您可以尝试使用抗 DDoS 和节流解决方案来防止泛洪。
我已将 ToolScriptManager 替换为 ScriptManager，因为最新的 scriptmanager 已得到增强以合并 ToolScriptManager 的功能。
这对我来说解决了这个问题。