SQL注入仍然是一种威胁吗?

Ale*_*rdi 0 sql asp.net sql-injection cracking

我一直想知道SQL注入是否仍然是日常普通网站的可能威胁,使用参数化SQL.(ASP.NET - '@ 0').

如果它仍然是一个威胁,那么破解者如何覆盖或绕过这些参数呢?

Gre*_*reg 5

根据OWASP的说法,它仍然是2013年的最大威胁(在ASP.NET问世之后很久):https://www.owasp.org/index.php/Top_10_2013-A1-Injection

参数化SQL不会消除担心SQL注入的麻烦.我曾在一家公司工作,以前的开发人员创建了存储过程,该过程将字符串作为参数,创建了一些动态SQL,包括该字符串并执行它.他们声称它是安全的,因为它是参数化的,但我能够证明我可以将SQL代码传递给存储过程并让它执行.

此外,声称您可以安全地使用SQL注入,因为您使用支持参数的语言并不意味着您每次都使用参数.只有一个人可以将一些代码注入您的数据库.

  • 我认为值得注意的是,正确使用参数化可以有效地消除SQL注入的威胁.黑客无法解决某些问题.您描述的情况非常具体,因为程序员或多或少地消除了预编译查询本身的好处.有效,但可能不是OP所询问的. (2认同)
  • 诀窍很简单:不要执行用户给你的任何东西.即使你在它周围加上引号,你仍然在添加用户输入后编译SQL.在Greg的示例中,参数化SQL解释并运行另一个包含用户输入的SQL脚本.在添加用户输入之前,您需要解释参数化点,因此无法注入. (2认同)