SQL注入漏洞（原理篇）

errorr0

已于 2022-06-22 14:50:44 修改

阅读量1.2k

点赞数 3

分类专栏： SQL注入文章标签： sql 数据库 database

于 2022-06-22 14:31:39 首次发布

本文链接：https://blog.csdn.net/qq_51295677/article/details/125403438

版权

SQL注入专栏收录该内容

9 篇文章 1 订阅

订阅专栏

SQL注入是我安全入门学的第一个漏洞，这个漏洞怎么说呢，前期的学习单单记住那几个payload知道如何查库、查表、查列、查字段就可以做题目了。没办法，初学者零基础就是这样，从记忆开始再到逐渐理解结束，慢慢的再回看以前做的题，以及对源码的审计，又有很多不一样的感悟，比如开始只知道如何攻击后面就慢慢的学会了审计，学会了分析。

当然之前数据库攻击学习我一直只停留在MySQL的学习上，所以这段时间我会把对MySQL的停留突破到其它关系型数据库如Postgresql、Oracle、MSSQL等，再进阶到非关系型数据库如MongoDB。

什么是sql注入

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
（百度百科）

简单来说就是在sql查询中对用户可控的参数动手脚达到欺骗效果。

sql注入成因

最主要的原因我觉得还是因为开发者在程序开发过程中不注意规范书写 sql 语句和对特殊字符进行严格的过滤，导致客户端可以通过全局变量 POST 和 GET 甚至其他请求头提交一些 sql 语句而达到正常执行。简单来说就是黑白名单的工作没有做的很细导致注入。

当然这只是一方面，而像数据库配置时版本的原因（截断）、对错误的过度回显（报错）、允许多条sql指令的提交（堆叠）等等都有可能会造成注入。

sql注入的原理

字符拼接：

我们可以在注入点以符号结束前一句sql查询，后面再起手一句新的查询语句。

巧妙闭合：

原本的查询语句应为：

但由于id=‘1’中的1是可控变量，当不安好心的人输入一些其他的东西，如1‘ or 1=1# （警号为注释符，将后面的数据直接注释了达到闭合效果）。

除开这种注释的闭合还有一种闭合就是利用另一个参数与其闭合，还是上面那个例子

select * from users where id='1';

我们对这个1参数做手脚即将1改为1' or '1'='1 带入到终端进去看，就清楚了

这种闭合一般用于中间的参数闭合即后面存在有用的数据无法通过注释达到目的。

注入的原理即无论是哪种闭合方式，目的只有一个，就是在原有的基础上我们增加一条自己输入的恶意语句，导致数据库的信息泄露或者生成后门。

sql注入的危害

上面以及提到过两个了信息泄露和后门的生成，这里我系统的总结一下sql注入成功后会对服务端造成的伤害。

信息泄漏：数据库中存放的用户的隐私信息的泄露如网站登录的账号、密码，甚至有用户的名字以及身份证啥的。

挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。

数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被窜改。

服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。

当然这也只是目前我已知和认为存在的危害，还有已存在我不清楚以及未知的危害都有可能。

如何防范sql注入

既让sql注入这么危险，那么该如何有效的减少这种危害呢？当然只能防范和减少，无法阻止和避免，安全真的无孔不入，研究安全的人员脑洞真的还是超级的大。

防御的方式还是得溯源到攻击者的角度，堵住他们的来路即可。

采用过滤方式阻止传入的危险参数值，对传入的值分析后进行再次过滤即二次过滤。

对传入的字符串进行语法词法的检测判断其是否存在注入。

代码层防止sql注入攻击的最佳方案就是sql预编译（用的最多的）。

规定可输入数据的长度，能在一定程度上防止sql注入。

限制数据库的操作权限（防止用户对数据库进行修改）。

限制数据库一次性可执行的查询条数（防止堆叠注入）。

对数据的存储采用加密存储，一旦攻击者进入数据库也能对隐私做二次保护。