剛畢業時進了一家技術團隊有200多人的公司,第一周熟悉代碼時,順便做了下審計,然后發現了4個高危漏洞,說一說當時的一些經驗

前期準備(踩點)

看文檔

要審計一個應用,起碼要熟悉這個應用的功能模塊以及底層實現,有現成文檔的話是最快的,作為開發人員,應該第一時間把項目文檔和依賴的框架文檔都過一遍,這個對審計帶來的收益是持續的

看提交歷史

提交歷史直接反映了項目近期的狀況,根據近期代碼提交來觀察是否每一個開發都遵循了編碼規范,編碼規范不好的人,寫出來的代碼bug數也會很高

還可以搜索,比如按fix/修復/修正/解決等關鍵字搜索commit message,看下都修復過那些問題,以及修復的手法,可以對該項目的健康程度以及開發人員水平有一個了解

搭建項目并用掃描器掃一遍

這樣可以對這個項目的目錄結構和安全性等有一個大致的了解,該花精力著重審計的功能模塊和優先級心里也有數了

開始審計

搜索原始而落后的代碼

我對原始而落后的代碼的定義,就是明明框架都封裝好的函數不去用,非要自己用最原始的方式去調用,或者造了個渣輪子

比如一個PHP框架,如CodeIgniter,已經對獲取GET或者POST過來的變量有封裝如:

$this->input->post()

$this->input->get()

如果仍然出現直接取_POST,$_REQUEST這幾個全局變量的代碼,就證明開發人員不講規范,不講規范的原因是開發水平低,水平低就容易寫出漏洞,可以從這些位置開始分析

像CodeIgniter這個框架的

$this->input->post()

$this->input->get()

函數,

第二個參數是可選的,用于過濾xss,但是默認是false,也就是不過濾...所以寫個正則去找一下這些代碼的第二個參數不填或者是 false 的,然后去追蹤看后續有沒有進行防御過濾,以此類推

搜索sql語句

當一個項目用了框架之后,一般都會用框架提供的api去操作數據庫,不會直接拼接sql語句,如果代碼里有sql語句,那么很可能是不講規范的人員寫出來的,同理,不講規范的人員水平通常不行,當然很容易忘記過濾

而且大部分開發人員如果要手工拼接sql語句了,變量名通常會叫sql,或者XXXsql

所以搜索的區域是業務代碼里包含sql字樣的代碼,去回溯這些sql拼接的部分是不是用參數化查詢,如果不是的話是不是用戶可控的,有沒有進行防御過濾

尋找富文本輸入框

富文本過濾,無論是經驗多豐富的程序員,總會百密一疏,從富文本中可以挖掘的漏洞太多了,如界面劫持

針對富文本的過濾,PHP里做得屌的是HTML Purifier,其它語言的富文本過濾,可以看本站提交漏洞時勾選XSS漏洞類型時的修復建議

如果一個PHP程序,有富文本輸入框,而且是提供給前臺用戶的,又沒有引入HTML Purifier進行過濾,而是選擇自己寫一套,或者從其它安全性不高的框架里抄一份過來,那么出漏洞的概率非常高

檢查api語義和規范

根據語義以及約定俗成的規范,讀操作的接口都是用GET請求的,寫操作都是用POST請求的

而市面上成熟的框架,都會帶有全局的csrf防御,不過一般只針對POST操作

如果分析出有寫操作的接口,但是對應的是POST請求,肯定是不看規范的人寫的,這類接口通常就會有csrf以及其它的問題

復雜的功能先無腦改http數據包,再看代碼 業務復雜的功能,通常交互步驟也多,代碼也很復雜,直接看的話很容易頭暈,還不如把所有提交的參數和返回值都改一編,看看有無報錯等信息,一切正常的話再去看代碼

其實這類功能,邏輯問題是最多的,比如越權

危險函數

這個先要看自身對項目所用語言的了解程度,項目的整體架構,項目的規模,危險函數出現的位置。函數放在那里就是讓人用的,但是你用的位置不對,還是用戶輸入可控,那就是問題了

就拿系統命令執行來說,不是不能用,但是如果一個電商的搶購功能,用的又是傳統的Web框架,你跟我說在里面加個exec開定時任務之類的,不說別的,我肯定讓你滾回去重做

要知道開啟新進程的開銷很大,并發一上來cpu占用就夠你喝一壺.而且能用這種方案的,連阻塞是什么都不懂,而且執行系統命令默認在很多語言環境下都是阻塞的,影響系統性能,如果開多線程去處理,又要涉及到線程池,因為線程不是你想開多少就能開多少的

一般危險函數是針對PHP而言的,因為PHP的函數行為太豐富,特性太多,但是現在PHP的份額在減少,就不多說了

檢查依賴的組件是否已經升級到最新版 沒什么好說的,最怕是線上依賴的版本和測試環境的不一致,或者線上不是所有的服務器依賴的都一致,但是你只是審計而已,已經盡力了...

與開發人員進行交流,看看深淺

其實這不在代碼審計的范圍,但是如果你知道了開發人員的深淺,那么根據他的弱點去審計他負責的代碼,也算是一個精準打擊

比如

并下并發場景下,如何保證商品庫存的一致性

Mysql的鎖機制是怎么樣的

Redis你都用了哪些特性

項目用了哪些隊列組件,在什么場景下用的

一個不懂鎖機制,不知道隊列的人,寫出來的代碼的并發性肯定有問題,如果讓他開發什么[搶][領][限]這種有次數限制的寫操作場景功能,絕逼會有臟讀或者臟寫的漏洞,導致一個人可以[領多次][搶多次]的漏洞

新開的交流群，歡迎大家加入，本群旨在交流解決問題，招聘和閑聊的請勿進

轉載于:https://juejin.im/post/5ad078e051882548fe4a8a65

總結

以上是生活随笔為你收集整理的代码审计——你是如何发现那些有缺陷的代码的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。