戴上你的黑帽，現(xiàn)在我們來學(xué)習(xí)一些關(guān)于SQL注入真正有趣的東西。請(qǐng)記住，你們都好好地用這些將要看到的東西，好嗎?

SQL注入攻擊因如下幾點(diǎn)而是一種特別有趣的冒險(xiǎn)：

1.因?yàn)槟茏詣?dòng)規(guī)范輸入的框架出現(xiàn)，寫出易受攻擊的代碼變得越來越難——但我們?nèi)匀粫?huì)寫差勁的代碼。

2.因?yàn)槟闶褂昧舜鎯?chǔ)過程或者ORM框架，你不一定很清楚的是(雖然你意識(shí)到SQL注入可能穿透他們，對(duì)嗎) 我們?cè)谶@些保護(hù)措施之下編寫的代碼依然是易受攻擊的。

3.通過精心設(shè)計(jì)的爬取web搜尋易受攻擊站點(diǎn)的自動(dòng)化工具使這類站點(diǎn)更易遠(yuǎn)程檢測(cè)出來。而我們依舊在發(fā)布它們(譯注:指站點(diǎn))。

SQL注入攻擊因一個(gè)非常恰當(dāng)?shù)脑蚨槐Ａ粼贠WASP(Open Web Application Security Project 開放Web應(yīng)用安全項(xiàng)目) 的十大隱患列表中第一位——它特別常見，非常容易利用，而且影響十分劇烈。一個(gè)很微小的注入風(fēng)險(xiǎn)經(jīng)常就能使整個(gè)系統(tǒng)中的所有數(shù)據(jù)都被泄漏——而我將要展示給你如何運(yùn)用大量不同的技術(shù)自己來這樣做。

我?guī)啄昵皩憽秚he OWASP Top 10 for .NET developers》時(shí)展示過如何防范SQL注入攻擊，所以我不會(huì)專注在這些，這都是漏洞利用。受夠了那些無聊的防御工具，讓我們來攻擊別的東西。

如果我們能攻破查詢內(nèi)容，你們的數(shù)據(jù)就都是我們的了

讓我們對(duì)讓SQL注入攻擊成為可能的原因做一個(gè)快速概括。簡而言之，這就是輸入查詢并解密數(shù)據(jù)。讓我把所說的可視化給你：比如說你有一個(gè)包含有類似于“id=1”之類的字符串參數(shù)的URL，容納后那個(gè)參數(shù)通過如下方式構(gòu)造了一個(gè)SQL查詢。

這整個(gè)URL可能和這個(gè)東西看起來很像：

 

這是挺基礎(chǔ)的東西，而當(dāng)你能掌控鏈接中的信息并改變傳遞給查詢的值時(shí)會(huì)變得有趣。好了，把1變成2會(huì)給你另一個(gè)你期待的東西，但是如果你這樣做呢?

http://widgetshop.com/widget/?id=1 or 1=1

那可能在數(shù)據(jù)庫服務(wù)器中存留成這樣的：

SELECT * FROM Widget WHERE ID = 1 OR 1=1 

這告訴我們的是數(shù)據(jù)沒有被凈化——在上例中ID應(yīng)該只是一個(gè)整數(shù)但“1 OR 1=1”的值也被接受。更重要的是，因?yàn)閿?shù)據(jù)只是簡單地被添加到查詢中，它能夠改變語句的功能。這個(gè)查詢將能夠選擇所有的記錄而不是單個(gè)記錄，因?yàn)?rdquo;1=1″語句是恒成立的。

或者，我們可以通過把“or 1=1”改成“and 1=2”來強(qiáng)制頁面不返回任何記錄，因?yàn)樗恢倍疾怀闪⑺詻]有結(jié)果返回。在這兩個(gè)可選的方案中我們能方便地確定程序是否受注入攻擊威脅。

這是SQL注入攻擊的本質(zhì)——通過不被信任的數(shù)據(jù)巧妙地操縱查詢的執(zhí)行——而在開發(fā)者做這樣子事時(shí)發(fā)生。

query = "SELECT * FROM Widget WHERE ID = "+ Request.QueryString["ID"]; 
//Execute the query... 
//執(zhí)行查詢... 

當(dāng)然他們做的是將不被信任的數(shù)據(jù)參數(shù)化，但本文中我不會(huì)過多敘述(如果想要了解防范措施，轉(zhuǎn)回part one of my OWASP series)，而將更多談?wù)撊绾伟l(fā)動(dòng)攻擊。

好了，于是背景部分介紹了如何展示SQL注入風(fēng)險(xiǎn)存在，但你能拿它怎么辦?讓我們開始探尋一些普遍的注入模式。

#p#

抽絲剝繭:合并基于查詢的注入

讓我們舉個(gè)例子，表示我們想要返回一堆記錄的頁面，在這里是一個(gè)有一堆帶有“TypeId”1的小東西的URL。像這樣:

http://widgetshop.com/Widgets/?TypeId=1

頁面上的結(jié)果會(huì)像這樣：

我們會(huì)期待這個(gè)查詢進(jìn)入到數(shù)據(jù)庫時(shí)變成像這樣的東西：

SELECT Name FROM Widget WHERE TypeId = 1 

但是如果我們能應(yīng)用我上述描繪的，也就是說我們可能能夠給查詢字符串中的數(shù)據(jù)添加SQL，我們可能會(huì)做出這樣的東西：

http://widgetshop.com/Widgets/?TypeId=1 union all select name from sysobjects where xtype=’u’ 
 
SELECT Name FROM Widget WHERE TypeId = 1 union all select name from sysobjects where xtype='u' 

現(xiàn)在記好了系統(tǒng)對(duì)象表列舉數(shù)據(jù)庫中所有對(duì)象，而在這個(gè)例子中我們用 xtype “u” 來篩選這個(gè)表，換言之，用戶表。

當(dāng)一個(gè)注入風(fēng)險(xiǎn)存在的時(shí)候?qū)?huì)有如下的輸出：

這就是叫做合并基于查詢的注入攻擊，就像我們剛才簡單地像原始結(jié)果添加一項(xiàng)，它直接到了HTML輸出中——簡單吧!既然我們已經(jīng)知道有一個(gè)數(shù)據(jù)表叫“User”，我們可以做這樣的事：

http://widgetshop.com/Widgets/?TypeId=1 union all select password from [user]

如果數(shù)據(jù)表中“user”不被中括號(hào)括起來，考慮到“user”這個(gè)詞在數(shù)據(jù)庫看來有其他含義，SQL服務(wù)器會(huì)變得不易控制。不管怎樣，這是它返回的：

當(dāng)然，UNION ALL語句只在第一個(gè)SELECT語句和第二個(gè)有相同的字段時(shí)起作用。這很容易被發(fā)現(xiàn)，你只需試試一些“union all select ‘a’”，如果它查詢失敗就試試“union all select ‘a’, ‘b’”之類的，以此類推。根本上你是在不斷猜測(cè)列數(shù)直到你構(gòu)造的查詢發(fā)揮作用。

我們可以繼續(xù)研究這個(gè)方面并揪出各種數(shù)據(jù)，但還是學(xué)習(xí)下一種攻擊方式吧。有時(shí)一個(gè)基于合并查詢的注入不會(huì)發(fā)揮作用，與輸入格式、查詢中添加的數(shù)據(jù)甚至結(jié)果如何顯示都有關(guān)。為了繞開它我們需要變得更有創(chuàng)造性一些。

http://widgetshop.com/widget/?id=1 or x=1

等一下，這不是一個(gè)合法的SQL語句，那個(gè)“x=1”不會(huì)被處理，至少在沒有一個(gè)叫做x的列時(shí)不會(huì)被處理。那么它不會(huì)拋出一個(gè)異常嗎?嚴(yán)格地說，事實(shí)上你將會(huì)看到像這樣的異常：

這是一個(gè)ASP.NET的錯(cuò)誤，而其他的框架也有類似的樣式。但是重要的是這些錯(cuò)誤信息暴露了內(nèi)部的實(shí)現(xiàn)方式，換言之，這告訴我們數(shù)據(jù)庫中沒有叫做“x”的字段。為什么這很重要?從根本上說，這是因?yàn)槟阋坏┐_立了一個(gè)應(yīng)用程序在泄漏SQL異常，你就可以做這樣的事：

http://widgetshop.com/widget/?id=convert(int,(select top 1 name from sysobjects where id=(select top 1 id from (select top 1 id from sysobjects where xtype=’u’ order by id) sq order by id DESC)))

這有好多需要吸收理解，我等會(huì)將回來詳細(xì)解釋。更重要的是通過那條語句你能夠在瀏覽器中得到這樣的結(jié)果：

現(xiàn)在我們得到了，我們已經(jīng)發(fā)現(xiàn)那數(shù)據(jù)庫里有一個(gè)表單叫做“Widget”。你將經(jīng)常能看到這中注入攻擊因依賴于數(shù)據(jù)庫內(nèi)部的錯(cuò)誤而被稱作“基于錯(cuò)誤信息的注入”。讓我們解構(gòu)URL中的這個(gè)查詢：

convert(int, (
    select top 1 name from sysobjects where id=(
      select top 1 id from (
        select top 1 id from sysobjects where xtype='u' order by id
      ) sq order by id DESC
    )
  )
)

從最深層的開始理解，我們先按照ID的順序從sysobjects表獲取第一個(gè)有記錄的ID。在那里，我們獲取最后一個(gè)ID(這就是為什么它是按降序排列)，并把它傳遞到第一個(gè)select語句。那個(gè)語句接下來只會(huì)將那個(gè)表單名稱轉(zhuǎn)換成一個(gè)整數(shù)。這個(gè)轉(zhuǎn)換將大多數(shù)情況下失敗(各位，不要用“1”或“2”或其他整數(shù)來命名數(shù)據(jù)表就是這個(gè)原因!)，而這個(gè)異常暴露了UI中的表單名稱。

為什么是三個(gè)select語句?因?yàn)檫@意味著我們可以進(jìn)入最深層的那個(gè)并把“top1”改為“top2”，得到如下結(jié)果：

現(xiàn)在我們知道了這個(gè)數(shù)據(jù)庫有一個(gè)數(shù)據(jù)表叫做“User”。利用這種方法我們可以發(fā)現(xiàn)各個(gè)表單的字段名稱(只需向syscolumns表應(yīng)用同樣的思路)。我們可以更進(jìn)一步擴(kuò)展這個(gè)思路

在上一個(gè)截圖中，我已經(jīng)發(fā)現(xiàn)了叫做User的表單和名為Password的列，現(xiàn)在我需要做的就是把那個(gè)表單選出來(當(dāng)然，你可以用嵌套的select語句來一個(gè)一個(gè)枚舉所有的記錄)，并通過將字符串轉(zhuǎn)換成整數(shù)來構(gòu)造異常(你總是能夠在數(shù)據(jù)后面通過加一個(gè)英文字符來看它到底是不是一個(gè)整數(shù)，之后嘗試將整個(gè)字符串轉(zhuǎn)換為整數(shù)時(shí)就會(huì)產(chǎn)生一個(gè)異常)。如果你想要進(jìn)一步理解這可以有多簡單，我去年錄制了一個(gè)我教3歲兒子用Havij來自動(dòng)注入的視頻，那里運(yùn)用了這個(gè)技術(shù)。

但是這里有一個(gè)問題——它唯一能成功的可能是因?yàn)槟莻€(gè)app有些淘氣并將內(nèi)部的錯(cuò)誤信息展示給公眾。事實(shí)上那個(gè)app差不多直接告訴了我們表單和列表的名字并當(dāng)我們做出恰當(dāng)詢問時(shí)返回?cái)?shù)據(jù)，那么如果那個(gè)app不這樣做又會(huì)怎樣呢?我的意思是，如果那個(gè)app設(shè)定恰當(dāng)而沒有泄漏內(nèi)部的錯(cuò)誤信息呢?

這就是我們運(yùn)用“blind”SQL(多譯為盲注)注入的地方，那真的是一個(gè)有趣的東西。

#p#

盲目地嘗試注入

在上一個(gè)例子中(事實(shí)上也在很多成功的注入攻擊先例中)，攻擊依賴于受攻擊的app明確地將內(nèi)部的細(xì)節(jié)，要么是合并表單，要么是將數(shù)據(jù)返回，要么將錯(cuò)誤信息傳回瀏覽器。泄漏內(nèi)部的實(shí)現(xiàn)方法一直都是一鍵不好的事，因?yàn)檎缒阒翱吹降哪菢?，像這樣不安全的錯(cuò)誤處理可以促使不僅僅是應(yīng)用程序的架構(gòu)泄漏，更會(huì)使你極易從中獲取數(shù)據(jù)。

一個(gè)恰當(dāng)設(shè)定的app應(yīng)當(dāng)能夠在得到一個(gè)未經(jīng)處理的異常時(shí)返回一個(gè)和下面這個(gè)相似的錯(cuò)誤信息：

這是新ASP.NET的app在處理自定義錯(cuò)誤時(shí)的默認(rèn)錯(cuò)誤頁面，但是類似的樣式也在別的technology stacks中出現(xiàn)?，F(xiàn)在這個(gè)頁面已經(jīng)和之前那個(gè)顯示內(nèi)部SQL異常的頁面一模一樣了，只不過是用一個(gè)有好的錯(cuò)誤信息代替直接展示出來的異常。假如我們同時(shí)也不能實(shí)現(xiàn)一個(gè)基于合并查詢的攻擊，SQl注入風(fēng)險(xiǎn)就完全不存在了嗎?不一定……

盲目地SQl注入攻擊依賴于我們變得能夠得到不言而喻的信息，換言之，我們能夠通過觀察app并沒有直接告訴我們的表單名稱或者在瀏覽器中直接顯示的列表數(shù)據(jù)來下結(jié)論。當(dāng)然問題來了——我們?nèi)绾巫宎pp按照一個(gè)可以觀察到的格式來揭示我們之前有的信息，而并不顯式地告訴我們?

我們將去欣賞兩種嘗試：基于布爾值的和基于時(shí)間的。

#p#

去詢問(APP)，然后你將被回答：基于布爾值的注入

這只有你詢問app正確的問題時(shí)成立。之前，我們能夠明確地詢問這樣的問題，比如“你有什么表單?”或“每個(gè)表單中你有什么數(shù)據(jù)列?”，然后數(shù)據(jù)庫會(huì)明確地告訴我們?，F(xiàn)在我們需要稍微變換一線詢問的方式，比如像這樣：

http://widgetshop.com/widget/?id=1 and 1=2 Clearly this equivalency test can never be true – one will never be equal to two. How an app at risk of injection responds to this request is the cornerstone of blind SQLi and it can happen in one of two different ways. 

顯然這個(gè)相等測(cè)試永遠(yuǎn)不會(huì)成立——1永遠(yuǎn)都不等于2。那么一個(gè)app如何處理這樣的查詢決定了它的SQL注入風(fēng)險(xiǎn)，可能會(huì)有兩種方式。

第一種，如果沒有記錄返回，它可能只拋回一個(gè)異常。通常開發(fā)者會(huì)假設(shè)那里存在一個(gè)與查詢的字符串有關(guān)的記錄，因?yàn)榻?jīng)常會(huì)是app自己產(chǎn)生那個(gè)鏈接并在另一個(gè)頁面中獲取數(shù)據(jù)。而當(dāng)那里沒有數(shù)據(jù)可以返回時(shí)，事情就不一樣了。或者第二種，那個(gè)app可能拋出一個(gè)異常并同時(shí)不會(huì)展示記錄，因?yàn)槟莻€(gè)相等永遠(yuǎn)都是錯(cuò)的。不管怎樣，那個(gè)app都會(huì)隱含地告訴我們數(shù)據(jù)庫中沒有記錄被返回。

現(xiàn)在我們?cè)囋囘@個(gè)：

1 and( 
 select top 1 substring(name, 1, 1) from sysobjects where id=(  
  select top 1 id from (
      select top 1 id from sysobjects where xtype='u' order by id    
) sq order by id desc
 )
) = 'a'

要記住用這整個(gè)語句塊來替換剛才那個(gè)查詢串的“?id=1”，這實(shí)際上是一個(gè)在前一個(gè)詢問上做出的小變化，試圖獲取表單名稱。事實(shí)上主要的區(qū)別在于現(xiàn)在不是試圖通過將字符串轉(zhuǎn)換為整數(shù)來構(gòu)造異常，而是運(yùn)用相等測(cè)試來檢查是否有一個(gè)表單首字母為“a”(假設(shè)這里對(duì)大小寫不敏感)。如果這個(gè)查詢和“?id=1”給我們的信息一樣，那么它就相當(dāng)于向我們證實(shí)相等測(cè)試成立了，sysobjects里確實(shí)有一個(gè)首字母開頭為“a”的表單。如果它給我們之前我們提到過的兩種情景之一，那么我們就知道表單并沒有以“a”開頭，因?yàn)闆]有信息被返回。

現(xiàn)在我們得到的只有sysobjects中表單的第一個(gè)字母，當(dāng)你想要得到第二個(gè)字母是substring語句需要變成現(xiàn)在這樣：

select top 1 substring(name, 2, 1) from sysobjects where id=( 

你能看到它現(xiàn)在從2開始而不是1.當(dāng)然，這很費(fèi)力：你在枚舉sysobjects中所有表單后枚舉了所有字母表中可能組成的詞，直到你最后得到了結(jié)果，然后你又要表單名稱的每一個(gè)字符重復(fù)這個(gè)過程。但是，有一種像這樣的快捷方式：

1 and 
(   
select top 1 ascii(lower(substring(name, 1, 1))) from sysobjects where 
 id=(     
select top 1 id from (  
     select top 1 id from sysobjects where xtype='u' order by id     
) sq order by id desc 
  ) 
) > 109 

這里有一個(gè)微妙但很重要的區(qū)別，它沒有檢查單個(gè)字符匹配，而是查找字符在ASCII表中的位置。事實(shí)上，它先將表單名稱轉(zhuǎn)換為小寫字母，這樣我們只需要處理26個(gè)字符(當(dāng)然，假設(shè)命名中只有字母)，然后它獲取那個(gè)字母的ASCII值。在上一個(gè)例子中，它接著檢查表單中是否有以在“m”(ASCII值為109)之后的字母開頭的，然后相同的潛力成功描述了之前應(yīng)用的(要么一個(gè)記錄被返回要么沒有)。主要的區(qū)別在于，沒有進(jìn)行26次嘗試猜測(cè)字母(并連續(xù)進(jìn)行26次HTTP請(qǐng)求)，它現(xiàn)在將會(huì)在5次嘗試中窮盡所有可能——你只需要不斷將可能的ASCII值區(qū)間減半直到最后只有一種可能剩余。

比如，如果一個(gè)字符ASCII值比109大，那么它一定在“n”和“z”之間所以你分割(大致地)這個(gè)區(qū)間為一半，然后嘗試大于115那個(gè)。如果那是錯(cuò)誤的那么正確的字符就一定在“n”和“s”之間，所以你再將區(qū)間減半，然后嘗試大于112的那個(gè)。那時(shí)正確的所以現(xiàn)在只有三個(gè)字符剩下了，所以你可以在至多兩次嘗試中將區(qū)間減小至長度為1。一句話就是至多26次猜測(cè)(平均起來13次)，現(xiàn)在只需要5次，如果你只是簡單地每次將答案區(qū)間減半。

通過構(gòu)造恰當(dāng)?shù)脑儐朼pp將依舊告訴你之前它通過明確的錯(cuò)誤信息告訴你的東西，只不過它現(xiàn)在有些怕羞，你需要哄它才會(huì)得到答案。這經(jīng)常被叫做“基于布爾值”的SQL注入，而它在之前演示過的“基于合并查詢”的和“基于錯(cuò)誤信息”的方案不好用時(shí)能夠發(fā)揮作用。但這并非萬無一失，讓我們看看另一個(gè)途徑，這回我們將要有一些耐心。

#p#

耐心等待泄漏：基于時(shí)間的盲目注入

所有實(shí)時(shí)的方案成功發(fā)揮作用都是基于一個(gè)假設(shè)：app會(huì)通過HTML輸出來泄漏信息。在之前的例子中基于合并查詢的和基于錯(cuò)誤信息的嘗試是在瀏覽器中給我們數(shù)據(jù)來明確地告訴我們對(duì)象名稱和泄漏的內(nèi)部數(shù)據(jù)。在盲目的基于布爾值的例子中，我們被隱含地告知同一份信息借助于HTML和基于真假相等測(cè)試得到的結(jié)果不同。那么當(dāng)這份信息不能通過HTML泄漏時(shí)，不論是明確地還是隱含地，怎么辦?

讓我們想像有另一個(gè)攻擊媒介是這個(gè)URl：

http://widgetshop.com/Widgets/?OrderBy=Name 

在這個(gè)例子中很正常假設(shè)查詢會(huì)被翻譯成像這樣的東西：

1 
     
SELECT * FROM Widget ORDER BY Name 

顯然我們不能直接開始向ORDER BY語句直接加?xùn)|西(盡管那里已經(jīng)有其他角度你可以掛載一個(gè)基于布爾值的攻擊)，所以我們需要嘗試另一種途徑。一個(gè)很常見的SQL注入技巧是終止一個(gè)語句并隨后附加一個(gè)語句，比如像這樣：

http://widgetshop.com/Widgets/?OrderBy=Name;SELECT DB_NAME 

這是一個(gè)無害的語句(盡管在查找數(shù)據(jù)庫的名字是可能會(huì)有用)，一個(gè)更有害的途徑可能會(huì)是類似于“DROP TABLE Widget”的東西。當(dāng)然web app連接數(shù)據(jù)庫所調(diào)用的帳號(hào)需要有這樣的權(quán)限，問題在于一旦你開始將鏈接連接起來，它的潛力就開始發(fā)揮。

回到那個(gè)盲目的SQL注入攻擊，現(xiàn)在我們需要做的是找到一個(gè)在附加語句中運(yùn)用之前討論到的基于布爾值的測(cè)試。要做到這點(diǎn)我們需要用WAITFOR DELAY語句來產(chǎn)生延時(shí)。試試這個(gè)，看看尺寸：

這和之前的例子只有一個(gè)微小的變化，之前是通過操縱WHERE語句改變返回的記錄的書目，而現(xiàn)在只是用一個(gè)新的語句來查找sysobjects中是否存在一個(gè)表單以一個(gè)比“m”大的字母開頭，并且如果存在，查詢將稍微等待5秒鐘。我們?nèi)耘f需要縮小表單名稱的范圍而且需要嘗試表單名中的每一個(gè)字符而我們?nèi)耘f需要查詢sysobjects中的其他表單(當(dāng)然還要看看syscolumns并將數(shù)據(jù)提取出來)，但所有這一切完全可以用一點(diǎn)時(shí)間。5秒鐘可能比需要的有些長了或者它可能不夠長，這一切都?xì)w結(jié)于應(yīng)用程序的響應(yīng)時(shí)間如何保持一致，因?yàn)樽罱K這都被設(shè)計(jì)來操作一個(gè)能被觀察到的行為——從開始查詢到最后得到結(jié)果要經(jīng)過多長時(shí)間。

這個(gè)攻擊——還有之前那些——當(dāng)然被可以完全地自動(dòng)化，因?yàn)槌撕唵蚊杜e和條件邏輯之外不剩別的了。當(dāng)然它可能會(huì)占用一些時(shí)間，但那是一個(gè)相對(duì)的概念：如果一個(gè)正常的查詢需要1秒鐘，而5次嘗試只有一半需要完成的話，你應(yīng)該期待每17.5秒得到一個(gè)字符，比如有數(shù)據(jù)庫中平均有10個(gè)字符的話，就是需要大概3分鐘得到一個(gè)表單，而可能一個(gè)數(shù)據(jù)庫中有20個(gè)表單，我們就認(rèn)為大概一小時(shí)你就能得到系統(tǒng)中的每一個(gè)表單名稱。而這是你用單線程方式做這些的情況。

#p#

到這里沒有結(jié)束……

這是那些有一堆不同角度觀點(diǎn)的話題，不只因?yàn)橛刑嗟臄?shù)據(jù)庫、app框架、服務(wù)器的組成，更不要說一整個(gè)防御體系比如網(wǎng)絡(luò)應(yīng)用的防火墻。一個(gè)事情變得棘手的例子是如果你需要求助于基于時(shí)間的攻擊而數(shù)據(jù)庫還沒有支持延遲功能，比如一個(gè)Access數(shù)據(jù)庫(是的，游戲而事實(shí)上在網(wǎng)站中用這些!)這里的一個(gè)途徑是用叫做heavy queries的方案，查詢由于本身的性質(zhì)會(huì)導(dǎo)致響應(yīng)是緩慢的。

另一件關(guān)于SQL注入攻擊值得一提的是攻擊是否成功有兩個(gè)關(guān)鍵因素：第一個(gè)是app在輸入方面的規(guī)范，這決定了app最終會(huì)接收到什么字符并傳給數(shù)據(jù)庫。通常我們會(huì)看到很零零碎碎的途徑，比如尖括號(hào)和引號(hào)被剝離，但其他一切是允許的。當(dāng)這種情況出現(xiàn)時(shí)，攻擊者需要變得有創(chuàng)意，考慮如何構(gòu)造恰當(dāng)?shù)牟樵兪沟?ldquo;路障”被避免。而這正是第二點(diǎn)——攻擊者的SQl實(shí)力是至關(guān)重要的。這不是指你運(yùn)用TSQL的SELECT FROM的能力，那些優(yōu)秀的SQl注入者掌握大量能夠繞過輸入檢測(cè)的竅門并從系統(tǒng)中選擇數(shù)據(jù)而使它們能通過網(wǎng)頁來檢索。比如說，搜尋一個(gè)列的類型可以通過像這樣的小技巧：

http://widgetshop.com/Widget/?id=1 union select sum(instock) from widget 

在這個(gè)例子中，基于錯(cuò)誤的注入攻擊將在錯(cuò)誤信息返回到UI時(shí)(當(dāng)然，如果沒有報(bào)錯(cuò)就是指它是整型的)會(huì)告訴你“InStock”列是什么類型的

 

或者一旦你完全厭倦了那個(gè)該死的易受攻擊的站點(diǎn)仍然在網(wǎng)絡(luò)上留存，試試這個(gè)：

但是注入攻擊可以通過從HTTP中獲取信息而更進(jìn)一步，比如那里有能給攻擊者機(jī)器腳本的載體或者試試另一個(gè)離題的——為什么不試試直接通過HTML獲取那該死的東西?你就創(chuàng)建一個(gè)本地的SQL服務(wù)器并通過1433端口遠(yuǎn)程連接到SQL Server Management Studio!等一下，你會(huì)需要那個(gè)網(wǎng)頁app用來鏈接數(shù)據(jù)庫來創(chuàng)造用戶的帳號(hào)，是嗎?是的，而且大部分人都需要，事實(shí)上你只需通過Google就能找到它們(譯注：用度娘會(huì)告訴你找不到)(當(dāng)然這種情況下SQL注入攻擊就沒有必要了，因?yàn)閿?shù)據(jù)庫此時(shí)已經(jīng)能公開獲取)

最后，如果關(guān)于SQl注入攻擊及漏洞的流行和在當(dāng)今軟件行業(yè)的影響還有什么疑問，就在上周就有一篇關(guān)于可以說是迄今為止最大的黑客方案之一的新聞，據(jù)稱它造就了3億損失

這起訴書也暗示那些黑客，在大多數(shù)情況下，沒有部署很復(fù)雜的方案來進(jìn)入企業(yè)網(wǎng)絡(luò)。這篇報(bào)道也展示了在大多數(shù)情況下缺口是通過SQL注入漏洞的道德——這一威脅已經(jīng)被徹底證明并領(lǐng)悟遠(yuǎn)超過十年了。

可能SQL注入攻擊沒有像某些人相信的那樣被人理解。

博文出處：http://blog.jobbole.com/85683/