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