sql防注入怎么绕过

说实话，SQL注入是一件很痛苦的事情。
正如你所说，攻击者只是盲目地改变你输入的数据，让数据库做一些不应该做的事情。
以前我不明白，后来慢慢就明白了。

例如，2 01 9 年有消息称某电商网站被黑客攻击，有人利用SQL注入删除用户密码。
所以这真的不是一个笑话。

为了保护自己免受这种情况的影响，您需要做一些事情。
首先，使用参数化查询，这特别有用。
可以想象，当您向数据库发出命令时，人们坚持添加混乱的代码来制造问题。
参数化查询就像一个解释器，直接说普通话一样的乱码，直接忽略。
2 01 8 年 OWASP 报告中称这种方法更为有效。

其次，用户输入必须经过验证。
你不可能偶然收集到所有东西。
比如用户名必须是字母数字，不能包含特殊字符，比如'、"，直接被过滤掉。
正因为如此，我们的系统接受了带单引号的用户名，直接改了数据库命令，是不是很惨？
第三，数据库权限要给足够，但不能太多，就按请求授权人的权限，但改了，只给了最低限度的权限。
第四，开发人员要学会写代码，还要了解这些攻击的原理银行系统发现了SQL注入脆弱性，否则就会将其最小化。

php提供一下哪些函数来避免sql注入

哎兄弟，说起这个PHP防止SQL注入的技巧，我就吃亏了。
记得有一次，刚入行的时候，我正在创建一个用户登录功能，心想如果直接把SQL语句串起来该多方便啊。
结果，当我在用户名输入字段中输入单引号时，我就返回了一个空的用户列表。
我以为服务器坏了。

后来我吸取了教训，开始使用 mysqli_real_escape_string() 来转义用户输入。
这次好多了，至少服务器没有卡住。
但有一天，用户输入了一个很长的名字，系统就死机了。
后来经过排查，发现原因是转义函数无法处理这么长的字符串。

后来我开始使用准备好的语句，这次容易多了。
我记得有一天我向日志系统编写了一个查询并使用了 mysqli_prepare() 和 mysqli_bind_param()。
虽然用户输入的名字里面仍然有单引号，但是系统根本没有任何反应，这样就安全多了。

还有一次用了PDO预处理，功能比较强大，支持命名参数，而且很容易写。
比如我写了一个查询，用冒号指定用户名，绑定时指定类型，运行时直接传递值，简洁又安全。

当然，这条路上也有很多陷阱。
例如，有一天我忘记关闭错误显示。
结果，用户直接看到了数据库错误信息，隐私暴露。
还有一次我直接使用用户输入来动态创建表名。
结果，用户输入了恶意的 SQL 语句，数据库基本上受到了损害。

所以，兄弟，安全问题其实是一个循序渐进的事情。
现在我遵循最小权限原则，只授予数据库用户必要的权限，错误处理也是紧密封闭的。
总之，这种防护防御可以用一句话来概括：预防第一，治疗第二。