国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

在PHP中全面阻撓SQL注入式進犯

lakeside / 2361人閱讀

摘要：在這種狀況下，雖然也只是規規矩矩地完成其缺省行為，可是的確能夠維護你免于大多數簡略的注入式進犯。年五月號，在登錄代碼中發現了一處注入軟弱性。因而，它很容易遭受咱們前面所評論的注入類型的進犯。

或許存在許多不同類型的進犯動機，可是乍看上去，好像存在更多的類型。這是十分實在的-假如歹意用戶發現了一個能夠履行多個查詢的方法的話。
假如你的腳本正在履行一個SELECT指令，那么，進犯者能夠逼迫顯現一個表格中的每一行記載-經過把一個例如"1=1"這樣的條件注入到WHERE子句中，如下所示(其間，注入部分以粗體顯現)：
SELECT * FROM wines WHERE variety = "lagrein" OR 1=1;"
正如咱們在前面所評論的，這自身或許是很有用的信息，由于它揭示了該表格的一般結構(這是一條一般的記載所不能完成的)，以及潛在地顯現包含秘要信息的記載。
一條更新指令潛在地具有更直接的要挾。經過把其它特點放到SET子句中，一名進犯者能夠修正當時被更新的記載中的任何字段，例如下面的比如（其間，注入部分以粗體顯現）：
UPDATE wines SET type="red"，"vintage"="9999" WHERE variety = "lagrein"
經過把一個例如1=1這樣的恒真條件增加到一條更新指令的WHERE子句中，這種修正規模能夠擴展到每一條記載，例如下面的比如（其間，注入部分以粗體顯現）：
UPDATE wines SET type="red"，"vintage"="9999 WHERE variety = "lagrein" OR 1=1;"
最危險的指令或許是DELETE-這是不難想像的。其注入技能與咱們現已看到的相同-經過修正WHERE子句來擴展受影響的記載的規模，例如下面的比如（其間，注入部分以粗體顯現）：
DELETE FROM wines WHERE variety = "lagrein" OR 1=1;"
二、 多個查詢注入
多個查詢注入將會加重一個進犯者或許引起的潛在的損壞-經過答應多條破壞性指令包含在一個查詢中。在運用MySQL數據庫時，進犯者經過把一個出乎意料之外的停止符刺進到查詢中即可很容易完成這一點-此刻一個注入的引號(單引號或雙引號)符號希望變量的結束；然后運用一個分號停止該指令。現在，一個另外的進犯指令或許被增加到現在停止的原始指令的結束。終究的破壞性查詢或許看起來如下所示：
SELECT FROM wines WHERE variety = "lagrein";GRANT ALL ON .* TO "BadGuy@%" IDENTIFIED BY "gotcha";"
這個注入將創建一個新的用戶BadGuy并賦予其網絡特權（在一切的表格上具有一切的特權）；其間，還有一個"不祥"的口令被加入到這個簡略的 SELECT句子中。假如你遵從咱們在以前文章中的主張－嚴厲限制該進程用戶的特權，那么，這應該無法工作，由于Web服務器看護程序不再具有你撤回的 GRANT特權。可是從理論上講，這樣的一個進犯或許給予BadGuy自在權利來完成他對你的數據庫的任何操作。
至于這樣的一個多查詢是否會被MySQL服務器處理，定論并不唯一。這其間的一些原因或許是由于不同版本的MySQL所形成的，可是大多數狀況卻是由于多查詢存在的方法所形成的。 MySQL的監督程序徹底答應這樣的一個查詢。常用的MySQL GUI-phpMyAdmin，在終究查詢之前會復制出以前一切的內容，并且僅僅這樣做。
可是，大多數的在一個注入上下文中的多查詢都是由PHP的mysql擴展擔任管理的。幸虧，默許狀況下，它是不答應在一個查詢中履行多個指令的；企圖履行兩個指令(例如上面所示的注入)將會簡略地導致失利-不設置任何錯誤，并且沒有生成任何輸出信息。在這種狀況下，雖然PHP也只是"規規矩矩"地完成其缺省行為，可是的確能夠維護你免于大多數簡略的注入式進犯。
PHP5中的新的mysqli擴展(參閱http://php.net/mysqli)，就象mysql相同，內在地也不支撐多個查詢，不過卻供給了一個mysqli_multi_query()函數以支撐你完成多查詢-假如你的確想這樣做的話。
可是，關于SQLite-與PHP5綁定到一同的可嵌入的SQL數據庫引擎(參閱http://sqlite.org/和http: //php.net/sqlite)狀況更為可怕，由于其易于運用而招引了很多用戶的重視。在有些狀況下，SQLite缺省地答應這樣的多指令查詢，由于該數據庫能夠優化批查詢，特別是十分有用的批INSERT句子處理。可是，假如查詢的成果為你的腳本所運用的話（例如在運用一個SELECT句子檢索記載的狀況下），sqlite_query()函數卻不會答應履行多個查詢。
三、 INVISION Power BOARD SQL注入軟弱性
Invision Power Board是一個聞名的論壇體系。2005年五月6號，在登錄代碼中發現了一處SQL注入軟弱性。其發現者為GulfTech Security Research的James Bercegay。
這個登錄查詢如下所示：
$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password="$pid"");
其間，成員ID變量$mid和口令ID變量$pid被運用下面兩行代碼從my_cookie()函數中檢索出：
$mid = intval($std->my_getcookie("member_id"));$pid = $std->my_getcookie("pass_hash");
　　在此，my_cookie()函數運用下列句子從cookie中檢索要求的變量：
return urldecode($_cookie[$ibforums->vars["cookie_id"].$name]);
【留意】從該cookie回來的值底子沒有被處理。雖然$mid在運用于查詢之前被強制轉換成一個整數，可是$pid卻保持不變。因而，它很容易遭受咱們前面所評論的注入類型的進犯。
　　因而，經過以如下方法修正my_cookie()函數，這種軟弱性就會露出出來：
if ( ! in_array( $name，array("topicsread"， "forum_read"，"collapseprefs") ) )
{
return $this->
clean_value(urldecode($_cookie[$ibforums->vars["cookie_id"].$name]));
}
else
{
return urldecode($_cookie[$ibforums->vars["cookie_id"].$name]);
}

經過這樣的改正之后，其間的要害變量在"經過"全局clean_value()函數后被回來，而其它變量卻未進行檢查。
現在，已然咱們大致了解了什么是SQL注入，它的注入原理以及這種注入的軟弱程度，那么接下來，讓咱們探討如何有用地防備它。幸虧，PHP為咱們供給了豐厚的資源，因而咱們有充沛的信心預言，一個經細心地徹底地運用咱們所引薦的技能構建的應用程序將會從你的腳本中底子上消除任何或許性的SQL注入-經過在它或許形成任何損壞之前"整理"你的用戶的數據來完成。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/29683.html

相關文章

  • 在PHP中全面阻撓SQL注入式進犯

    摘要：在這種狀況下，雖然也只是規規矩矩地完成其缺省行為，可是的確能夠維護你免于大多數簡略的注入式進犯。年五月號，在登錄代碼中發現了一處注入軟弱性。因而，它很容易遭受咱們前面所評論的注入類型的進犯。 或許存在許多不同類型的進犯動機，可是乍看上去，好像存在更多的類型。這是十分實在的-假如歹意用戶發現了一個能夠履行多個查詢的方法的話。假如你的腳本正在履行一個SELECT指令，那么，進犯者能夠逼迫顯...

    zhkai 評論0 收藏0

  • PHP網站常見一些安全漏洞及防御方法

    摘要：一常見網站安全漏洞對于的漏洞，目前常見的漏洞有五種。分別是文件漏洞注入漏洞腳本命令執行漏洞全局變量漏洞和文件漏洞。這就是月行胃的注入漏洞。 一、常見PHP網站安全漏洞 對于PHP的漏洞，目前常見的漏洞有五種。分別是Session文件漏洞、SQL注入漏洞、腳本命令執行漏洞、全局變量漏洞和文件漏洞。這里分別對這些漏洞進行簡要的介紹。 1、session文件漏洞 Session攻擊是黑客最常...

    lavor 評論0 收藏0

  • php操作mysql防止sql注入(合集)

    摘要：參考中如何防止注入參數化查詢為什么能夠防止注入上面提供的資料比較多，下面根據自己的理解整理出來。使用的預處理參數化查詢可以有效防止注入。我們在上面預處理參數化查詢是在中進行防注入操作的，其實也內置了一個預處理的模擬器，叫做。 由于segmentfault在處理特殊字符時也并非完美，所以下面文章中有些符號被轉換了，請到本人博客下載原文txt http://www.yunxi365.cn/...

    kviccn 評論0 收藏0

  • Java代碼審計連載之—添油加醋

    摘要：在代碼審計中，按業務流程審計當然是必須的，人工的流程審計的優點是能夠更加全面的發現漏洞，但是缺點是查找漏洞效率低下。代碼審計學習之旅總有人問我代碼審計該怎么學習，該從哪學習，現在統一回復，表示我也不知道。。。 在代碼審計中，按業務流程審計當然是必須的，人工的流程審計的優點是能夠更加全面的發現漏洞，但是缺點是查找漏洞效率低下。如果要定向的查找漏洞，逆向跟蹤變量技術就顯得更加突出，如查找X...

    dunizb 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<