Sql注入理论及应用场景

508 阅读2分钟

本文已参与「新人创作礼」活动,一起开启掘金创作之路。

web程序结构

三层架构(3-tier architecture) 通常意义上就是将整个业务应用划分为:

  • 界面层(User Interface layer)
  • 业务逻辑层(Business Logic Layer)
  • 数据访问层(Data access layer)

image-20211222151642176

用户能够直接使用的都是在表示层,在表示层输入自己要访问的内容,输入的内容传递到业务逻辑层进行处理,并将处理后的数据写入到数据库中。

同理需要请求的内容从数据库中查询出来后在业务逻辑层进行业务逻辑处理,之后呈现在表示层。

以上两步就是一个正常的请求和响应过程。

sql注入就是因为业务逻辑层没有做安全过滤,到时了从表示层传递过来的数据修改了正常的sql语句结构,从而达到了黑客自身的攻击目的。

sql注入漏洞原理及危害:

漏洞原理:

访问动态网页时, Web 服务器会向数据访问层发起 Sql 查询请求,如果权限验证通过就会执行 Sql 语句。实际环境中很多时候需要结合用户的输入数据动态构造 Sql 语句,如果用户输入的数据被构造成恶意 Sql 代码,Web 应用又未对动态构造的 Sql 语句使用的参数进行审查,则会带来意想不到的危险。

靶场:citizenstig/dvwa 用户名密码:admin/passwd

image-20211222165611526

以下网站可以看出,查询1对应的内容

image-20211222165507266

分析在表示层输入的1到了业务逻辑层进行了哪些处理,分析源码:

image-20211222165839384

SELECT first_name, last_name FROM users WHERE user_id = '$id'
1就是获取后直接拼接到了语句中
SELECT first_name, last_name FROM users WHERE user_id = '1'   #查询1对应的first_name及last_name
#上面是正常情况下业务想表达的逻辑但黑客们往往不想这么简单,而是添加自己的语句达到自己的目的
 payload: 111' or '1'='1
 #将上面payload输入的输入框中,到了后台语句结构
 SELECT first_name, last_name FROM users WHERE user_id = '111' or '1'='1'  #where后面的语句无论or前面的内容是否存在,'1'='1'是恒成立的,那么他就可以把数据库中这个表里的缩影内容都查询出来,这就能达到他的目的,当然这只是很简单的or语句验证,还会有更复杂的语句能够把所有数据拿到,甚至利用提权拿到服务器权限
 

image-20211222170515458

危害:

QL注入通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。 造成SQL注入漏洞原因有两个:一个是没有对输入的数据进行过滤(过滤输入),还有一个是没有对发送到数据库的数据进行转义(转义输出)。

看图说话:

image-20211119111617707

汽车上的语句:ZU_006‘,0,0);DROP DATABASE TABLE=’XXX

拼接到监控系统中:select * from car where (carNum=’ZU_006‘,0,0);DROP DATABASE TABLE=’XXX‘#

拼接后的语句,无论车牌号是多少,闭合了前面的select语句,主要目的是为了执行DROP语句,删除掉了数据库中一个表xxx

GET、POST请求方式

在web页面中一般表现形式分为GET型和POST型,GET型是可以直接再浏览器的url处直接看到的,POST型则需要抓包修改里面的参数类型,但总体都是在参数处判断是否存在注入点。

POST请求处,抓包来判断注入点

image-20211223142202256

GET请求是在浏览器中直接可以看到参数

image-20211223142324811

union query类型注入

代码当中的sql语句

query="selectfromnewswhereid="+query = "select * from news where id=" + _GET['$id'];