共计 1426 个字符，预计需要花费 4 分钟才能阅读完成。
本篇内容主要讲解“Oracle 数据库实现 SQL 注入模拟与恢复”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“Oracle 数据库实现 SQL 注入模拟与恢复”吧!
1. Oracle SQL 注入过程 1.1.SQL 注入方式
从网上下载感染病毒的介质，在数据库实例创建时 SQL 注入脚本被执行并创建了相应的触发器和加密存储过程。这种注入方式由于在数据库实例创建时用 SYS 账号运行了被感染的脚本文件因此不需要依赖数据库中的 DBA 权限的用户。这种注入方式通过在 $ORACLE_HOME/rdbms/admin 下的 prvtsupp.plb 文件中添加一个加密的过程和一个触发器的创建脚本，在用户创建实例时会执行 prvtsupp.plb 该文件从而达到入侵的目的。通过对 prvtsupp.plb 文件中的过程进行解密后的内容如下：
另外一种注入方式就是网上下载了被病毒感染的 PL/SQL 或 Toad 客户端工具，如果用户登陆这些工具时使用具有 dba 权限的用户，则工具会在后台执行执行相应的病毒脚本并创建上面的过程和触发器。
1.1.SQL 注入行为
该触发器在每次数据库重启后执行存储过程，而存储过程执行时会判断当前时间距数据库创建时间是否大于指定的天数 (我这次遇到的是 300 天)，如果大于指定的天数则在数据库重启后将数据库字典基表 TAB$ 备份后并清空。
在 TAB$ 表被清空后如果数据库不再重启的话，数据库后台 alert 日志在报一系列 ORA-00600 后会一直会报错 ORA-00604 和 ORA-00957
2. Oracle SQL 注入过程模拟
模拟直接执行原加密的存储过程，如下：
执行存储过程后关闭数据库再次启动发现报错 ORA-00600 提示 bootstrap 核心对象损坏。
3. 应急修复过程测试
本次模拟修复采用 shell 脚本调用 bbed 批量修改 tab$ 表对应的块，来恢复 tab$ 表删除的记录。由于只修改了 tab$ 对应的簇表块并没有修复索引 (索引可以禁用，不建议修复)。所以在修复后只能通过 exp 将用户数据导出后进行重建数据库来恢复数据。
将受损的基表对应的 SYSTEM 表空间数据文件上传到 linux 平台执行相应的恢复脚本进行恢复如下：
修复完成后将文件拷贝回 windows 平台，然后启动数据库 (建议以 read only 方式打开数据库，我这里是测试环境懒的执行了)
导出对应的用户数据
4. 日常预检查、处理
对于生产库建议定期进行病毒特征排查，如何及时发现并且数据库没有重启且 select * form tab$ 查询不为空，则可以通过手动 drop 对应的存储过程和触发器 (通过以下语句来检查数据库是否已感染相应的 SQL 注入病毒)。
select drop || object_type || || owner || . || object_name ||
from dba_objects
where object_name in (DBMS_SUPPORT_DBMONITOR , DBMS_SUPPORT_DBMONITORP
其次可以对用同版本数据库正常的 prvtsupp.plb 文件来替换 $ORACLE_HOME/rdbms/admin/prvtsupp.plb 感染病毒的文件，防止后续数据库新建议实例时再次感染病毒。
到此，相信大家对“Oracle 数据库实现 SQL 注入模拟与恢复”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
