SQL注入实践 --程序猿的安全之路

开篇：SQL注入介绍

“SQL攻击(SQL injection)，是发生于应用程序至数据库层的安全漏洞。简而言之，是在输入的字符串之中注入SQL指令，在设计不良的程序当中忽略了检查，那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行，因此遭到破坏或是入侵。”

——维基百科

SQL注入的危害：

l非法读取、篡改、添加、删除数据库中的数据；

l盗取用户的各类敏感信息，获取利益；

l通过修改数据库来修改网页上的内容；

SQL注入种类：

l布尔注入；

通过判断页面返回情况获得想要的信息。

l报错注入；

如果页面能够输出SQL报错信息，则可以从报错信息中获得想要的信息。

l联合查询注入；

最快捷的方法，通过UNION查询获取到所有想要的数据，前提是请求返回后能输出SQL执行后，查询到的所有内容。

SQL注入已经是老生常谈的话题了，很多框架在设计之初已经考虑到这个问题，像hibernate、mybatis采用预编译机制，有效避免SQL注入。所以是不是就不需要研究SQL注入了呢，答复是否定的。

某前著名漏洞平台网站统计，现实网络中有很多网站存在SQL注入漏洞，笔者通过亲身实践带大家窥视这个行业。扶好把手，开始我们的SQL注入之旅。

正文：尝试攻击

1. 踩点

现在SQL注入的漏洞没那么好找，一般利用浏览器的语法搜索，如"inurl.php?id=",下面三种类型的截图界面就是通过这个方法找到的。

• 布尔型注入

输入and 1=1

输入 and 1=2

可以看到页面不一致了，说明存在漏洞。

• 报错型注入

尝试在id=3后面输入order by 数字试出网页字段数，原理:当order by的数字大于表的字段总数时，会报错.试出的字段是为了方便后续使用union替换出数据库里的其他信息。

order by 36 显示的就是正常页面，说明这张表有36个字段。哇哈哈！！！

• 联合查询注入

尝试用union select1,2,3,4,5,6,7,8,9,10,11,12,13,database(),version(),user()获取数据库,版本及用户的时候，很不幸没能成功，尝试了其他绕过方法均没成功。

2.SQL注入

其实手工注入的效率还是比较低的，网上有很多工具可以大大增加效率，今天要介绍的是kali的sqlmap。sqlmap是一个开放源码的渗透工具,支持现在几乎所有的数据库。

下载安装步骤就不介绍了，此处省略5000字。

找到可疑站点后，sqlmap提供很多命令做进一步分析。

使用--dbs 暴出mysql和database name

通过--dbs命令查到了数据库下面有哪些库，接着通过-D “库名”--tables,暴出库里的表

查到表后，-D “库名” --columns暴出所有表中的列名

接下来就可以为所欲为了，-D “数据库名”–users暴出user，-D “数据库名”--dump –T “表名”暴出表内容。

sqlmap还有一些未使用到的命令，–level,–risk,–string,–not,-string,–regexp,–code,感兴趣的可以网上搜一搜。

结尾：SQL注入防范

sql注入对企业的危害特别大，尤其是对像点融所在的金融行业，作为一名程序猿心中得时刻有安全观念。防范意识不可少。

1.永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度。

2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取(通过预编译把sql注入掐死在摇篮中,java中mybatis主动防御了sql注入,通过#{param},如果使用${param}将有sql注入风险)。

3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。

5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装。