sql注入的简单思考

    最近接了一个活是用php+smarty开发的，开发完了要送去软测，在写软测报告的时候突然想到会不会存在sql注入的问题，自己试了一下还真的是有这样的情况存在。详细信息还有表结构我会给出模拟数据。

    这是admin表，就用这张表来模拟最基本的数据以及操作吧。

   

    业务逻辑是要根据id去查询数据库，得到相应的数据后返回给界面进行修改，无疑就是select * from admin where id=xxx;这样的语句，平时我们在用框架的时候可能框架里边就已经做了一部分防sql注入的问题，比如mybatis，顺带说一句我主要是搞java的，但是这次接触到php在数据库操作层用的是朋友给的简单的sql语句封装，只是简化了写sql的过程，那么问题就来了，在原始的sql语句下肯定是存在sql注入的风险的，那么我们怎么避免sql注入？要想避免就该先知道sql注入的工作原理。

   sql注入原理 ，百度百科是这样说的所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。  比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击。

    我想看到这个很多人都是晕晕的，说简单点就是往你sql语句里边加了不该加的东西了，现在我们来模仿下，比如你的表结构已经暴露给了黑客，知道了表名要如何sql注入获取表中数据。以admin表为例，通常我们获取一条目标记录是这样的 select * from admin where id = 1; 但是sql注入的关键就是改变了where后边的查询条件，比如这里改成select * from admin where id =(select count(*) from admin),运行结果如下

只是改变了where后边的值就能获取到表中其他数据信息，这是一种sql'注入

还有一种是让where条件恒为真 ，如select * from admin where id = 1 or 1=1;运行结果如下

这样就拿到了数据里边所有的信息，当然了知道原理我们才能更好的防御。

如何防止SQL注入攻击？

以下建议可以帮助防止SQL注入攻击成功：

不要使用动态SQL

避免将用户提供的输入直接放入SQL语句中；最好使用准备好的语句和参数化查询，这样更安全。

不要将敏感数据保留在纯文本中

加密存储在数据库中的私有/机密数据；这样可以提供了另一级保护，以防攻击者成功地排出敏感数据。

限制数据库权限和特权

将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作。

避免直接向用户显示数据库错误

攻击者可以使用这些错误消息来获取有关数据库的信息。

对访问数据库的Web应用程序使用Web应用程序防火墙（WAF）

这为面向Web的应用程序提供了保护，它可以帮助识别SQL注入尝试；根据设置，它还可以帮助防止SQL注入尝试到达应用程序（以及数据库）。

定期测试与数据库交互的Web应用程序

这样做可以帮助捕获可能允许SQL注入的新错误或回归。

将数据库更新为最新的可用修补程序

这可以防止攻击者利用旧版本中存在的已知弱点/错误。