我正在扫描我在 Asp.net 中构建的 Web 应用程序。扫描程序正在将垃圾数据注入系统，试图在系统上进行盲注 Sql，但我正在使用带有参数化查询的 Sql 存储过程，它正在逃避盲注 sql，但这些垃圾条目作为普通文本存储到系统中，我正在清理输入不带'和其他sql相关参数。现在我的问题是
1）这些垃圾条目对系统有任何威胁吗？
2）如果我已经在使用带有存储过程的参数化查询，我真的需要清理输入吗？3) 如果您不创建登录序列，扫描仪无法将信息输入系统，这是一件好事吗？
我应该采取的任何其他预防措施请告诉我
谢谢
正如您正确提到的，数据库中的“垃圾”条目是 Acunetix 在测试 SQL 注入、XSS 和其他漏洞时提交的表单提交。
具体回答您的问题：
1) 不，这些垃圾数据只是扫描仪提交表单的产物。不过，您可能需要考虑对这些表单应用更严格的验证——请记住，如果扫描仪可以输入一堆虚假数据，那么自动化脚本（或真正的用户）也可以插入一堆虚假数据。
更好验证的一些想法可能包括根据特定字段中应允许的数据来限制输入类型。例如，如果希望用户输入电话号码，那么允许用户输入字母字符（数字、空格、破折号、括号和加号对于电话号码应该足够了）是没有意义的。
或者，您也可以考虑对某些表格使用 CAPTCHA。过多的验证码可能会对用户体验产生不利影响，因此请谨慎使用它们的地点、时间和频率。
2）如果您在谈论SQL注入，不，您不需要做任何其他事情。参数化查询是避免 SQLi 的正确方法。但是，请注意跨站点脚本 (XSS)。在处理 XSS 时，过滤字符<>'"不是要走的路。
为了处理 XSS，最好的方法（大多数时候）是练习Context-dependent Outbound Encoding，它基本上归结为 - 根据您所在的 XSS 上下文使用正确的编码，并在何时编码数据被打印到页面上（即在将数据保存到数据库时不编码，在将数据写入页面时进行编码）。要了解更多信息，这是我遇到的最简单、最完整的来源——http: //excess-xss.com/#xss-prevention
3) 登录序列是 Acunetix 对您的应用程序进行身份验证的方式。没有它，扫描仪将无法扫描您的应用程序的内部。因此，除非您有表单（可能在您网站的面向客户的部分），否则扫描仪将无法插入任何数据——是的，这通常是一件好事 :)