问题描述
任何建议??
推荐答案
评级为高的ASP.NET填充攻击向量。根据您的WAF，这可能是阻止应用程序的预构建签名，并且可能与Ajax控件没有直接关系。
It's referencing an ASP.NET padding attack vector that is rated "HIGH". Depending on your WAF this is probably a prebuilt signature blocking your application and may not be directly related to the Ajax controls.
有几种路线可供选择：
- 确定您是否实际上在解密期间公开了敏感的IIS错误代码并以代码解析。由于它是旧的CVE，因此最新的ASP.NET会尽力而为。其余的取决于开发人员。
- 验证您的系统是否是最新的补丁程序（ASP更新，Windows Updates或任何更新）。 Microsoft漏洞已在补丁MS10-070中修复。
- 如果实际上这是一个真实的误报，则需要训练WAF将此代码和应用程序行为视为可接受。如果您已经用尽了代码和修补程序，并且确定不是导致签名块的CVE，这是最后的选择。
Web应用程序防火墙与传统防火墙（或NG）有很大的不同，它们需要针对特定的应用程序进行定制才能正常工作。这很痛苦，但是需要适当地保护单个应用程序。
Web application firewalls are very different from traditional firewall's (or NG) in that they need to be tailored to a specific application to work properly. It's a pain but it's needed to properly protect an individual application.
您的WAF应该能够以透明的学习模式运行，以理解可接受的行为并围绕默认行为创建策略应用行为。学习过程完成后，您便可以开启强制行为并警告错误。然后修复WAF或应用程序中的错误。完成此操作后，您就可以执行并阻止错误了。如何完成此操作取决于WAF供应商。
Your WAF should be able to run in a a learning transparent mode to understand acceptable behaviors and create a policy around default application behavior. Once the learning process is complete, you can then turn on an enforcing behavior and alert on errors. Then fix the errors in the WAF or in the application. Once that's complete you can then you can enforce and block on error. How this is accomplished is dependent on the WAF vendor.
由于这是CVE签名块，因此您可能需要更深入地研究.Net如何处理URL。
Since this is a CVE signature block, you may need to dig deeper into how .Net is processing the URL.
这篇关于由于Scriptresource.axd，WAF阻止了ASP.NET网站的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！