对于经典的ASP应用程序，有什么强有力的方法可以防止SQL注入？

仅供参考，我将其与访问数据库一起使用。 (我没有写应用程序)

解决方案

存储过程和/或者准备好的语句：

https://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks

我可以通过使用单引号转义单引号和周围的用户输入来防止SQL注入吗？

捕获SQL注入和其他恶意Web请求

使用Access DB，我们仍然可以执行此操作，但是如果我们已经担心SQL注入，那么我认为我们仍然需要退出Access。

这是Access中技术的链接：

http://www.asp101.com/samples/storedqueries.asp

注意，通常防止注入的不是存储过程本身，而是它是参数化的并且不是动态的。请记住，即使构建动态代码的SP如果以某种方式使用参数来构建动态代码，也可能易于注入。总体而言，我更喜欢SP，因为它们形成了应用程序到达数据库的接口层，因此一开始甚至不允许应用程序执行任意代码。

此外，如果我们不使用命令和参数，例如，存储过程的执行点可能很容易受到攻击。这仍然很容易受到攻击，因为它是动态构建的，并且可以成为注入目标：

Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;

请记住，数据库需要捍卫自己的边界，并且如果各种登录都有权访问表中的" INSERT / UPDATE / DELETE"，那么那些应用程序(或者受感染的应用程序)中的任何代码都可能是潜在的问题。如果登录名仅具有执行存储过程的权限，则这将形成一个漏斗，通过该漏斗，我们可以更轻松地确保正确的行为。 (类似于OO概念，其中对象负责其接口并且不公开其所有内部工作。)

使用参数化查询，我们需要创建一个命令对象，为其分配参数名称和值，如果这样做，则无需担心其他任何事情(当然是指sql注入;))

http://prepared-statement.blogspot.com/2006/02/asp-prepared-statements.html

而且不要相信存储过程，如果我们不使用准备好的语句，它们也可能成为攻击的载体。

如果存储过程不是一个选择，即使它们被完全验证了所有输入

至少切换到SQL Express是一个不错的选择。这将使事情变得更加安全。即使使用参数和存储过程也可以有很大帮助。我还建议我们仔细验证输入，以确保它们符合期望。

对于像数字这样的值，提取数字以验证它确实只是一个数字非常容易。转义SQL的所有特殊字符。这样做将阻止尝试进行的攻击。

"保护经典ASP应用程序免受SQL注入的一种有效方法"是无情地验证所有输入。时期。

单独的存储过程和/或者不同的数据库系统不一定等于良好的安全性。

MS最近推出了一种SQL注入检查工具，该工具可以查找查询中使用的未经验证的输入。那是我们应该寻找的。

这是链接：
Microsoft用于SQL注入的源代码分析器可用于在ASP代码中查找SQL注入漏洞。

Microsoft用于SQL注入的源代码分析器可用于在ASP代码中查找SQL注入漏洞。