共計 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 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
