如何防止SQL注入攻击

让我看一下第一种方法的代码... $sql="select password from users where username='$name'";这样写的话，其实如果用户名不存在，比如攻击者输入admin'或者'1 '='1 ，查询结果就会为空，而if($arr=mysql_fetch_assoc($res))没有任何数据，会直接输出“用户名不存在”。
但如果用户名存在，比如admin，则查询结果会包含数据，进入if($arr['password']==$pwd)步骤。

当时我就一头雾水，以为这好像是在阻挡注射，后来发现其实是在削弱。
攻击者可以首先使用 ' or '1 '='1 直接使条件为真并绕过用户名检查。
然后，只要输入随机密码，就可以通过$arr['password']==$pwd这一步，因为$arr['password']可能是空字符串，也可能是与随机输入的密码相等的另一个值，登录成功。

也许我有偏见，但这个方法不够强大。
它不对密码进行处理，密码部分仍然是直连的。
如果 magic_quote_gpc=Off，攻击者可以通过类似 ' 或 password='anything' -
的方式输入它。

第二种方法，PDO，看起来要好得多。
$sql="从用户名=?且密码=?的用户中选择";这么写，用吗？作为参数的占位符，则 $pdoStatement=$pdo->prepare($sql);用于预处理，最后是 $pdoStatement->execute([$name, $pwd]);去落实。
这样，用户输入的所有内容都将被 PDO 自动覆盖，以防止 SQL 注入。

2 02 2 年，我在某城市做一个项目，使用了PDO预处理。
例如，当我收到用户名和密码时，我直接使用$pdo->prepare，无需添加引号或自己处理特殊字符。
PDO 将处理此事。
例如，如果用户输入admin'或'1 '='1 ，PDO会将其视为字符串值，而不是一段SQL代码，这样更安全。
而且，这种方法对于密码来说也是安全的，不会让攻击者通过注入的方式修改密码验证逻辑。

无论如何，PDO预处理是现在推荐的方法，并且比旧方法更可靠。

SQL注入的常见攻击方式和案例分析

1 、SQL注入非常危险，很容易导致数据泄露。
2 、直接在输入框中输入恶意代码，小心表单注入。
3 、URL参数篡改，搜索、分页可能受到攻击。
4 、页面响应不同，可能是布尔盲注造成的。
5 .搜索Twitter，2 009 年被黑客攻击，整个数据库被泄露。
6 .雅虎！ Voices于2 01 2 年遭到黑客攻击，4 5 万用户信息被泄露。
7 、参数化查询是防止SQL注入的好帮手。
8 . ORM工具，自动生成SQL，降低注入风险。
9 . 谨慎使用权限，不要乱用root。
1 0.补丁不及时，漏洞广泛存在。
1 1 、输入过滤和黑名单不可靠。
1 2 、WAF，临时保护，必须及时更新。
1 3 . 电商搜索未加密，所有订单均暴露。
参数化保存了它。
1 4 、技术保障与管理并重，安全才可靠。
1 5 、自省，防护要跟上进攻节奏。
你自己掂量一下吧。

sql注入漏洞解决方法 sql注入漏洞修复方案

等等，还有一件事。
上次遇到一个SQL注入案例，很有趣。

这是一家老公司的项目，大概是2 01 9 年夏天的。
系统使用JSP+Servlet，数据库是MySQL。
有一个界面。
当用户上传文件时，文件名直接从请求参数中获取，并链接到 SQL 语句中，无需任何处理。
结果有人用'OR'1 '='1 读取了整个文件表。
查看日志，SQL语句非常长，各种特殊字符满天飞。
幸运的是，后来改成参数化查询后，问题得到了解决。

我突然想到，这个场景如果使用ORM框架是不是会更简单呢？然而，ORM 并不是万能的。
有一次，我在使用Hibernate时，一个复杂的HQL查询写错了，直接导致数据库崩溃。
我花了很长时间才发现查询词不见了。
因此，技术的选择必须根据实际情况来考虑。
控制权限也很有趣。
我记得在另一个系统上，数据库用户权限设置得非常广泛。
结果在提权测试的时候，直接在测试环境中删除了一张表。
当时运维阿姨的脸色很难形容。
因此，最小特权原则不仅仅是说说而已。

等一下，还有一件事。
在安全审计过程中，我使用SQLMap对系统进行了扫描，发现了几个高风险点。
其中一处是之前修复过的地方，只是修复得不够全面。
这意味着什么？说明安全不是完成的问题，而是必须持续监控。

现在回想起来，如果团队成员在开发过程中对SQL注入有更深入的了解，很多问题可能就不会出现。
安全培训不能只是一日会议，必须融入到日常工作中。
不过话说回来，如此多的防御措施就代表完全安全了吗？看来并非如此。
有时，常见的漏洞或供应链攻击可能比简单的 SQL 注入更烦人。
因此，安全方面确实有很多话要说。