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