浅谈SQL注入

SQL注入带来的风险有哪些？

SQL注入上得了机器权限，下得了数据库数据。攻击者利用SQL注入漏洞，带来的风险有很多，例如数据库被拖库，管理员和重要人员信息泄露，甚至还有可能通过SQL注入漏洞直接获取webshell或者服务器系统权限等等。

SQL注入有哪些分类呢？

比如按照利用方式分类。常见的注入类型有：盲注，报错注入，time盲注，union注入，内联查询注入，拼接（堆）查询注入。
按照攻击入口分类，可以有get型的SQL注入，post型的注入，cookie型注入，header型SQL注入等。
按照注入点来分，可以分为整型注入，字符型注入。

目前所掌握的注入漏洞种类，出现频率较高有哪些？

盲注、time盲注、报错注入、union注入。

危害最大的呢？

在不影响正常服务的情况下，拼接查询算最高危害的，接下来就是union。

比较易被检测出来的有哪些？

盲注，time盲注，报错注入等

能分享下SQL注入漏洞的挖掘思路么~~例如SQL注入漏洞经常出现的位置，如何去判 断这类漏洞易出现的位置等。

我喜欢白盒（结合黑盒）的方式，能发现很多有意思的产品实现和有意思的点。 挖掘 思路上，大的方面是： 爬虫+规则。
关于注入的位置：常发生于用户和服务交互处（增删改查操作），ajax，接口等等， 用这个检测报错注入，比较方便。
举个栗子。👇 PHP+MYSQL扩展默认字符编码为GBK，且代码并未在real_escape_string前强制调 用set_charset（real_escape_string是官方推荐的标准安全转义方法），然后研发在 代码中使用query(‘set names utf8’)设置连接字符编码 ，我们就可以通过info? name=d4rkwind%df’ or sleep(3)-- -&other=xxx方式来注入成功（打破了只要 不是“set names gbk”就不会存在半个双字节编码SQL漏洞的误区）。原理很有意思 的，这个tips估计外界都没公布过。PHP mysql_real_escape_string 对SQL语句中 用户可控的name变量进行了GBK编码下的转义，即d4rkwind%bf’ or sleep(3)- - - 转 义 成 了 d4rkwind%bf\’ or sleep(3)-- -, 总 的 SQL 语 句 成 为 select xxx from yyy where name=‘d4rkwind%bf\’ or sleep(3)-- -’ 但 这 个“select xxx from yyy where name=‘d4rkwind%bf\’ or sleep(3)— -’” 实际上 是utf-8的了。所以，成功闭合了。

SQL注入带来的风险有哪些？