更多的是风险评估问题而不是技术问题。
所以我一直在阅读很多关于防止 SQL 注入的内容。让我们假设我有一个大型 Web 应用程序，该应用程序大多未受保护，我需要进行一些改进以防止出现此问题。使用动态查询读取大量 SQL 交互，但很少（少于 100 个注册用户）。
我的问题是......如果我已经使用参数化查询保护了主登录脚本（唯一公开可用的用户输入），是否真的有必要为网站的其余部分做同样的工作？我的意思是，如果潜在的攻击者无法登录，他还能造成多少其他损害？
当然，假设我的注册用户都没有恶意。
问问题
63 次
3 回答
0
是什么让您确定没有一个合法用户不会尝试攻击您的系统？
我很高兴我的银行不这么认为。现在有人会清空我的帐户，只需使用 sql 注入攻击。
即使这样，你也应该小心事故。如果您使用参数化查询，'则在值中使用 a 的人不会引起问题。
它允许参数中的类型安全。
它产生了更好的编程习惯。
它允许执行计划缓存。 （没有它，每个具有不同参数的查询看起来都像是一个完全不同的查询。不仅会阻止缓存这些查询的计划，而且会过度填充缓存，因此真正可以重复使用的计划会被丢弃。）
它不仅更安全，而且更可靠。除了实验和一次性代码之外，我想不出任何项目我都不会容忍不使用参数化查询。
于 2012-10-12T10:04:35.277 回答
0
永远不要相信你的用户！
即使你这样做了（也没有人可以注册），例如 CSRF 总是有潜力的；攻击者会将该系统的用户引导至带有图像的看似无害的页面。该图像将具有以下代码：
<img src="http://yourserver.com/profile?user_id='; DROP TABLE users" />
我的黑客技能几乎是 zilch，但你可以想象会发生什么 :)
于 2012-10-12T10:05:54.643 回答
0
当然，假设我的注册用户都没有恶意。
永远不要假设:) 如果您的用户拥有不同的权限，那么几乎没有权限的用户可以找到获得管理员访问权限的方法......等等。
此外，防止 SQL 注入不会使您的登录安全，并且有人可能会通过它进行暴力破解，或者只是从您信任的用户那里嗅探数据包。确保保护您的整个应用程序，不要假设您计划的入口点（登录脚本）是唯一可用的......
如果您的网站包含或需要用户提供任何敏感数据，请使用 SSL。
于 2012-10-12T10:03:02.907 回答