web代碼審計與滲透測試(文件)
【正文】 ?功能越強大說明漏洞幾率越大。如： $headers{XForwardedFor} = Test31425926。如： 數(shù)據(jù)庫操作容易忘記‘的地方 in()/limit/order by/group by if與變量初始問題等 ?通過 fuzz或者閱讀 php手冊、 php源代碼，發(fā)現(xiàn)新的漏洞函數(shù)或“特性” ?腳踏實地的變量跟蹤 ?像程序員一樣思考 ?…… 一次解放思想的滲透 [純屬虛構 ] 。 ? 那么不是所有的文件都這樣的問題，我們可以先通過白盒找到這些可能出現(xiàn)問題的變量名，然后可以寫個 fuzz的腳本，列表程序目錄一個一個提交探測 如果通過上述一些辦法都沒有效果的話，那就開始正規(guī)的代碼審計流程把。 C 相似性漏洞挖掘 ?天下武學同出少林 [天大代碼一把抄 ] 最經典的故事屬于 asp：動網的上傳漏洞 ?每個程序員都有自己的代碼風格習慣 不好的風格習慣，可能代碼致命的安全漏洞，而且習慣很難改變！ ?相同的功能帶來同樣的漏洞 如后臺的功能和 api接口實現(xiàn)相同的功能 ?尋找相似性漏洞 *通過補丁對比技術 *通過漏洞分析、總結漏洞類型 D 基于白盒的 fuzz 由于變量在傳遞的過程里千變萬化，跟蹤來很費事費力，為了快速找到漏洞 我們可以在白盒的基礎上通用一些 fuzz的方法，開始找到漏洞。等 變量過濾： intval/int()、 addslashes()、正則等 *對比的版本選擇：選取臨近的版本 [避免一些非安全補丁的干擾 ] 一個實例 B 業(yè)務功能與漏洞 ?實現(xiàn)業(yè)務功能的同時引入安全風險。 滲透測試中的代碼審計 代碼審計前的準備 ：得到程序的版本信息，越詳細越好。 閉合 define(?UC_API?, 來注射我們的 webshell代碼 二次漏洞的啟示 ?漏洞的類型是可以轉換的 :最終的目的是攻擊效果最大化！ ?一切進入函數(shù)的變量是有害的：變量在傳遞過程任意個環(huán)節(jié)可控就可能導致漏洞！ ?變量傳遞的途徑是多樣的：我們的攻擊思路多元化！ 如對于 dz，去尋找可以找到 uc_key的途徑： sql注射、文件讀取 [ uc_key]、控制 mysql的管理權限 [phpmyadmin]等等 二次漏洞的其他應用 ?應用級別的“ rootkit” 其他的因素與代碼審計 ?php版本與代碼審計 [變量與函數(shù) ] php本身函數(shù)的漏洞 [php缺少自動升級的機制 ] ?系統(tǒng)特性與 代碼審計
研究報告相關推薦
鄂ICP備17016276號-1