07_《计算机安全原理与实践》数据库随笔
1.数据库安全面临的挑战
对于一个群体而言(可以是任意的组织、机构),数据库是用于存储敏感数据的媒介。实际运用中,这些数据的访问对于业务开展至关重要。因此,这些敏感信息就成为了敌手(可能来自内部,也可能来自外部)的目标,稍有不慎,针对这些敏感信息的恶意攻击就会造成无法挽回的损失。可见,数据库安全至关重要。
信息安全的发展是一个攻防相互促进,在竞争中发展的过程。作为信息安全的重要组成部分,数据安全与数据运用发展也是不匹配的,具体如下:
- DBMS的复杂程度不断增加,配套的安全措施落后于新模块开发速度。
- 数据库系统的交互协议复杂程度高,如果想要匹配相应的措施,必须对相关内容非常熟悉
- 大多组织机构中,没有技能与岗位相匹配的数据库管理人员
- 许多企业对于数据的管理可能采用了不同的数据平台(Mysql,oracle,MongoDB等),这些不同的数据平台构成了一个异构环境,对于这样的数据存储环境的管理难度非常高
- 云技术的发展让不少组织选择将数据上云,对相关安全技术和管理人员的要求提高。
2.数据库管理系统DBMS
- 数据库是一个同于存储应用数据的机构化数据集合,除去数据项,数据库中还存储了数据项间的关系。
- 数据库管理系统(DBMS)是创建和维护数据库并为用户和应用提供特定查询服务的套件。
- 查询语言为用户提供了访问数据库的唯一接口。
DBMS的结构图如下所示:
- 开发者使用DDL来定义数据库的逻辑结构和过程属性,将其简化成一组数据库描述表。
- DML为应用开发者提供了一组强大的工具。
- 查询语言是为终端用户涉及的说明性语言。
- DBMS利用数据库描述表来管理物理数据库。
- 访问数据库的接口是文件管理模块和事物管理模块。
- 授权表作为支持DBMS的模块,用于确保用户对于数据拥有何种访问权。
- 并发访问表作为支持DBMS的模块,用于在命令冲突时避免冲突。
3.关系数据库
3.1 认识关系数据库
关系数据库的基本构件是数据表,而数据表由行和列组成:
- 每一列都代表了一种特定类型的数据
- 每一行记录着某一列对应的值
- 理想情况下,表中至少存在一列,其对应值是唯一的,用来唯一标识某行:主键
- 关系数据库允许数据表间通过每张表都出现的一个特殊标识符关联在一起:即主键和外键
关系数据库允许用户通过关系型查询语句访问数据库。需要注意,这里的关系型查询语句是说明性语言,而并非是编程性语言。常用的关系数据库如Mysql,Mssql,oralce。至于MongoDB,其并非为关系数据库,本质上Mongo是文件数据库,只是“像”关系数据库罢了。
3.1 关系数据库系统要素
【关系、元组、属性】
正式名称 | 常用名 | 其他名字 |
---|---|---|
关系 | 表 | 文件 |
元组 | 行 | 记录 |
属性 | 列 | 字段 |
【主键、外键、视图】
主键用于唯一标识某一行,考虑如下教师表
t_id | name | gender |
---|---|---|
01 | Alice | female |
02 | Bob | male |
03 | Eve | male |
t_id用于唯一标识每位教师,实际中可以理解成学号,这里t_id就是主键
考虑如下课程表
c_id | t_id | c_name |
---|---|---|
c01 | 01 | java |
c02 | 01 | python |
c03 | 03 | computer security |
c_id唯一标识每门课程,因此c_id就是课程表的主键。此外教师表可以通过t_id和课程表联系在一起表示教师与课程之间的任课关系,对于教师表而言t_id是主键,而课程表中的t_id就是其对应的外键。
视图是一张虚表,本质而言其是从一个表或多张表中返回的选定行和列的查询结果。
3.3 结构化查询语言SQL
用户可以通过一系列SQL语句对数据库进行操作,部分类型语句如下
-
数据定义语言:主要针对数据库对象进行创建、修改和删除操作。其主要包括:
create:创建数据库对象
alter:修改数据库对象
drop:删除数据库对象 -
数据操作语言:主要用于对数据库中的数据进行增加、修改和删除的操作。其主要包括:
insert:增加数据
update:修改数据
delete:删除数据 -
数据控制语言,和数据库的访问控制相关其主要包括:
grant:授予用户某种权限
revoke:回收授予的某种权限 -
数据查询语言:主要用于数据的查询
结构是使用select子句,from子句,where子句的组合来查询一条或多条数据。
4. SQL 注入攻击
【本章具体SQL注入实践可参照实战专栏:点击传送门】🍉
SQL注入利用的是web应用的特性,当数据是用户可控,且与数据库进行交互时,可能出现SQL注入漏洞。敌手利用SQL注入漏洞可以从数据库中提取信息,高权限情况下甚至进行文件读写等高危操作。
SQL注入的成因通俗而言就是用户输入嵌入在程序SQL语句中从而被以外执行。例子如下
$id=$_GET['id'];
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
当用户输入为 1‘ and 1=2 #时,sql语句就会变成如下形式
$sql="SELECT * FROM users WHERE id='1' and 1=2#' LIMIT 0,1";
此时人为创造逻辑错误 1=2 如果页面回显异常,则判断存在注入点,从而可以进行后续操作:如进行堆叠注入
(前提是我们知道存在表:usr)
用户输入:1’; drop table usr #,与sql语句进行拼接后,语句变成如下形式:
$sql="SELECT * FROM users WHERE id='1';drop table usr#' LIMIT 0,1";
这样一来,用户可以通过输入删除数据库中的表,其破坏性可想而知,在CTF比赛中SQL注入的地位也是极高的。
4.1 手法简述
【名称可能不一样,但操作手法都一样,其关系就像是葵花宝典和辟邪剑谱一样,本质上是一个东西】
攻击主要途径
- 用户输入:包括get注入和post注入,get注入往往出现在url中;post注入往往出现在需要提交登录信息的登录界面中,用户可以尝试在登录框中输入payload进行尝试。
- cookie注入:有时网站会根据cookie内容恢复浏览信息,此时cookie处就存在注入的可能性,可以通过burpsuite等工具抓取数据包,修改cookie中的值为payload尝试注入
- 服务器变量:修改协议头进行注入,没有前两种常见。
- 二阶注入:也称二次注入,二次注入属于白盒测试的范畴,需要根据源代码判断其是否存在,其成因可以概述为:入库的数据在调用时和语句进行拼接从而进行一系列自定义操作。
- 物理用户输入:这种注入方式比较新颖,用户输入还可以是图片、二维码、条形码等。可通过这些方式进行注入。
三类攻击方式
带内注入:
- 重言式:将代码注入一个或多个永真表达式,如sqli-labs-less2中,payload这样写:?id=1 and 1=1 order by 4#,页面会报错, Unknown column ‘4’ in ‘order clause’ ,而?id=1 and 1=1 order by 3#页面回显正常。这里就是一个重言判断。之后就能够根据order by 3 写出payload:?id=1 and 1=2 union select 1,2,3 #进行回显
- 行尾注释:结尾加上注释符–+或#,上述例子中都有使用,采用这种方式和闭合符号异曲同工,都是为了不让后续数据干扰操作。
- 捎带查询:在预期之外进行额外查询,常用手法之一。
推理攻击:
- 报错注入:一般出现在页面会提示数据库错误的情况,可以采用特定的函数进行报错:如updatexml()。思路就是在报错信息中,显示出想要的信息
- 盲注:细分为bool盲注和时间盲注,满足条件(比如bool逻辑中为真)页面回显正常,不满足条件时(bool逻辑为假)页面回显异常
带外注入:
- 常用的为DNS_log带外注入,但相比之下,没有前面的实用,在实在没法回显的情况下不失为一种好办法。原理就是通过读取DNS记录进行信息的回显,结果可能通过特定网页应用,或是邮件反馈给测试者。
4.1 防护简述
主要的防护策略分成三类,防护性编码、检测、运行时阻断
防护性编码
- 手动防御性编码检测:编码时对用户的输入进行过滤:如特殊符号,字符等。最大程度上避免异常的输入。
- 参数化查询插入:编码时更准确的指定查询结构,独立的传递参数值,方便杜绝用户改变查询结构
- SQL DOM:SQL DOM是一个特殊的类,通过调用里面的方法可以一定程度上防御SQL注入。
检测
- 基于签名:这种方法试图匹配特定的攻击模式。
- 基于异常:这种方法定义了正常行为,凡是异常行为,系统进行拦截。
- 代码分析:通过大量的代码和SQL注入的案例训练防御模型,以此进行防御
运行时阻断
运行时检测查询是否与期望查询模型一致。
5. 数据库的访问控制
DBMS支持多种访问策略:
集中管理:少量特权用户可以进行授予和回收访问权
基于所有权管理:表的属主可以进行访问权的授予和回收
分散管理:被表的属主授予访问权的用户也可以进行访问权的授予和回收
5.1 基于SQL的访问控制
关于数据库的访问控制,提及数据控制语言,其主要包括:
-
grant:授予用户某种权限;
grant 权限 on 表 to 用户 identified by 密码 with grant option
。
其中identified by 后的密码用于收回权限时实用,with grant option代表被授权的用户能够向其他用户授予和其对等的权力。考虑如下语句:
grant select on c_list to Bob
其表示向Bob授予对c_list表的查询权
-
revoke:回收授予的某种权限,语法格式如下:
revoke 权限 on 表 from 用户
考虑如下语句revoke select on c_list from Bob
表示从Bob收回对c_list的查询权
5.2 级联授权
DBMS中支持的管理策略之一为分散管理:被表的属主授予访问权的用户也可以进行访问权的授予和回收。这样一来授权就能级联到许多用户。如下图所示(注意时间线),在t=10时刻,Ann向Bob授权;t=20时刻,Ann向Chris授权;t=30时刻Bob向David授权;t=40时刻,David向Ellen授权;t=50时刻,Chris也向David授权;t=60时刻,David向Frank授权:t=70时刻,Ellen向Jim授权。
思考这样一个问题:如果Bob收回David的权限会发生什么?
由于David在t=40时向ellen授权,因此Ellen和jim的权限都将被收回。那么为什么frank的权限不会被收回呢?
因为Chris晚于40时刻向David授权,这时David的访问权来自于Chris,级联的权限:Chris->David->Frank
因此Bob收回权限后,授权链如下所示:
5.3 基于角色的访问控制RBAC
定义与先前介绍过的RBAC策略相同,无非应用范围从计算机系统迁移到了数据库系统。RBAC策略能供减轻管理员的压力,并且提升数据库安全。该策略下需要提供如下的功能:
- 创建和删除角色
- 定义一个角色的许可
- 角色的分发
在这样的策略下,共有三类角色
- 应用属主:拥有数据库对象,并将其作为应用一部分的用户
- 终端用户:不拥有数据库对象,但可以通过应用程序操作数据库的用户
- 管理员:对数据库整体担负管理职责的用户
下表是Mssql管理中的角色表,有了解即可:
6.推理
注意,这里的推理指的并不是前文提到的推理攻击。这里的推理可以字面的理解成根据视图和原表特征,推理出数据项的对应关系。存在一张表
根据该表创建两个独立的视图:
由于创建视图的特性,熟悉原表的人就能够推理出如下信息:
7.数据库加密
对于数据库的加密主要关心的是数据的机密性。但是存在着加密导致的两个经典问题:其一,密钥分发问题,前几篇博文介绍了结合对称加密的密钥分发模型,但从模型来看,这就是一个极其复杂的问题,实际应用中自然更加困难。其二:不灵活,当数据全部被加密时,查询将变得相当不灵活。
下面图简述了一种数据加密的方案,不加赘述:
【对于灵活性的提升】
可以将数据库中的每行进行加密,规定每个数据项的范围和索引,形成如下的映射表,不加赘述:相似思想在密码学章节提到过
【云安全部分略,最后云和lot安全整理更新】