国产成人毛片毛片久久网_国产午夜激无码av毛片不_国产乱对白精彩在线播放_av资源站中文字幕_亚洲男人的天堂网站_国产成 人 综合 亚洲网_中国国产激情一区_少妇一级淫片免费放_亚洲一本大道av久在线播放_免费观看美女裸体网站

一、代碼掃描的目標

網(wǎng)上關于代碼掃描的介紹無一不是在推薦基于語法語義分析的代碼掃描工具，典型的代表就是fortify、Checkmarx�？偨Y起來觀點無非是, 目前市面上有基于正則表達式和基于語義分析的兩種檢測方式，基于正則表達式的傳統(tǒng)代碼安全掃描方案的缺陷在于其無法很好的“理解”代碼的語義，而是僅僅把代碼文件當作純字符串處理。靜態(tài)掃描商用產(chǎn)品都運用了語義分析、語法分析等程序分析技術靜態(tài)分析層負責對代碼文件進行“理解”，完成語義、語法層面的分析。能進行完整數(shù)據(jù)流分析，通過分析污點傳播進行漏洞判定。

之前也使用過fortify進行自動化代碼掃描，由于誤報率太高導致推送給業(yè)務方的漏洞代碼不被重視，也使安全部門的權威性受損。業(yè)務方不可能從眾多的代碼結果中排查出漏洞代碼，所以不得不放棄fortify(fotify做代碼審計輔助工具還是不錯的)。另外一個原因是，fortify沒法自定義掃描規(guī)則，當有內部特定代碼風險的時候無法編寫規(guī)則掃描，帶來了一定的不便利性。

基于以上兩點問題，對于代碼掃描有了新目標。首先掃描準確性要高，其次要能靈活的自定義規(guī)則。經(jīng)過分析發(fā)現(xiàn)，再厲害的語法語義掃描器也避免不了誤報，最大難點在于掃描器根本無法識別過濾函數(shù)的有效性。靜態(tài)代碼掃描要解決這個問題除非用AI來解決，這是云舒的觀點我非常贊同，等有一天AI能向人一樣閱讀代碼的時候這個問題可能會解決吧。所以決定采用基于正則表達式的代碼掃描器，我們可以掃一些代碼規(guī)范類的問題。例如：不規(guī)范函數(shù)、SQL語句拼接、redis和MongoDB未授權訪問、數(shù)據(jù)庫連接信息硬編碼、DEBUG 模式未關閉、fastjson遠程代碼執(zhí)行漏洞的特定代碼等等。雖然掃描來的這些問題不一定是漏洞但一定是代碼風險也是不規(guī)范的寫法，這樣業(yè)務方也更容易接受。對于漏洞類型的代碼可以交給運行態(tài)代碼檢測工具iast去發(fā)現(xiàn)，iast的缺點就是需要依靠第三方測試流量可能面臨覆蓋面不全的尷尬境地，所以需要結合靜態(tài)代碼使用。

不管怎么說能發(fā)現(xiàn)潛在風險并且業(yè)務方能接受整改，那么我們的目的就達到了。

二、為什么不選fortify

代碼掃描器一般的掃描邏輯是圍繞尋找Source和Sink展開。Source 是污染源，有害數(shù)據(jù)的入口點。Sink 是程序執(zhí)行造成危害的部分。接下來追蹤污染路徑，確定Source–Path–Sink重點看下傳進來的參數(shù)有沒有做有效過濾，邏輯再現(xiàn)攻擊，如果入?yún)⒌阶罱K執(zhí)行函數(shù)都是可通行的那么一般都是有漏洞的。

Fortify會產(chǎn)生誤報的原因，對于Source函數(shù)和Sink這些都是系統(tǒng)自定義函數(shù)，fortify有足夠的實力可以整理出來各個語言的入口函數(shù)和執(zhí)行函數(shù)列表并形成規(guī)則。但是對于過濾函數(shù)卻顯得無能為力了，主要原因是過濾規(guī)則千奇百怪通過靜態(tài)代碼的語義分析根本無法識別是否做了有效過濾。

例如，對于xss漏洞在不同場景就有不同的過濾方法，輸出到html、js、css、富文本等這些過濾規(guī)則就各式各樣，如果不是人為去審計代碼靠程序很難分析出來是否做了有效過濾。

這里通過一個掃描案例來分析fortify誤報的原因。

這里選取WebGoat的代碼作為測試代碼。

(1)這里掃描識別出來是xss漏洞代碼，并且數(shù)據(jù)流向也畫出來了。咋一看fortify還挺強大的。

(2)增加過濾函數(shù)，并對惡意參數(shù)進行過濾

(3)再次使用fortify掃描，對惡意參數(shù)已經(jīng)做了有效過濾仍然報出xss漏洞，顯然這是誤報。

(4)將過濾函數(shù)添加到過濾規(guī)則明白中去，相當于告訴fortify這個函數(shù)做了有效過濾。

右鍵添加規(guī)則

(5)再次使用fortify掃描代碼，誤報解除。上圖掃描出來6個xxs漏洞，下圖掃描出來2個，上圖中過濾函數(shù)添加fotify規(guī)則白名單的代碼不再掃出來xss漏洞。

三、基于正則掃描原理分析

工欲善其事必先利其器，理解好一個器具的使用最好的方式就是理解其代碼運行的原理，這樣才能做到靈活應變。

這里以MongoDB未授權訪問漏洞為例來講解代碼掃描原理。

如果沒有對MongoDB訪問進行認證，或者沒有按照官方標準的寫法來認證的話，我們都認為是有安全風險的。

MongoDB未認證&Java原生API訪問MongoDB:

public void init(){
            client = newMongoClient("192.168.23.24", 27022);
            dataBase =client.getDatabase("duanjt");
            collection =dataBase.getCollection("teacher");
        }
        // 插入一條數(shù)據(jù)
        @Test
        public void insert() {
            Document doc = new Document();
            doc.append("name", "李四");
            doc.append("addr", "重慶");
            doc.append("likes", Arrays.asList("排球", "籃球"));// 數(shù)組
            collection.insertOne(doc);// 插入數(shù)據(jù)時會自動創(chuàng)建數(shù)據(jù)庫和**
           System.out.println("success");
        }
    MongoDB認證&JavaAPI接口調用:
    MongoClient client= null;
try {
    MongoCredentialcredential = MongoCredential.createCredential(“username” , “dbname”, “pwd”);
    ServerAddress addr= new ServerAddress(“ip”, port);
    client = newMongoClient(addr, Arrays.asList(credential));
    DB db =client.getDB(MongoDBCfg.DB_SP2P);
// 以下可以對db進行相關操作
    } catch (Exceptione) {
    } finally {
if (client != null){
    client.close();
    }
    }

這里通過正則的分組表達式將規(guī)則分為定位規(guī)則(定位執(zhí)行函數(shù)),前置規(guī)則(一般是入?yún)⒑瘮?shù)的規(guī)則，如果有寫了前置規(guī)則和定位規(guī)則就必須兩條規(guī)則都匹配到才能說明有代碼風險),防御規(guī)則(防御函數(shù)的規(guī)則，如果能識別出來這條規(guī)則就可以認為不存在代碼風險)

代碼掃描邏輯：

1)  首先下載項目的git倉庫代碼并將其存儲到指定的目錄，便于接下來進行代碼掃描。

2）掃描準備工作獲取代碼基本信息

通過cloc命令將項目的基本代碼信息解析出來。例如統(tǒng)計有多少行代碼，有多少種類型的擴展文件，有多少個文件等。

同時在Dependencies類里面會使用mvn dependency:tree去分析項目的依賴jar包的大版本和小版本從而形成應用資產(chǎn)，便于出現(xiàn)jar依賴漏洞(如fastjson)的時候快速排查哪些應用存在漏洞依賴。

3）遍歷代碼規(guī)則掃描文件，這里使用grep命令進行文件掃描。

首先這里會掃描定位規(guī)則，掃描出來定位規(guī)則后，后面會進一步判斷前置規(guī)則和防御規(guī)則多條件判斷是否存在代碼風險。

4）開始匹配前置規(guī)則或者防御規(guī)則。

如果只寫了定位規(guī)則且匹配到了說明有代碼風險，可以是一些配置類的規(guī)則，比如csrf開關是否關閉、DEBUG模式未關閉等。

如果寫了前置規(guī)則和定位規(guī)則，要兩個規(guī)則都能匹配到才能說明有代碼風險�？梢允且恍┬枰�判斷前置條件的規(guī)則，比如Cookie不安全存儲、HTTP Response Splitting等。

如果寫了防御規(guī)則，只要防御規(guī)則生效說明沒有代碼風險，比如本文分析的MongoDB未授權訪問漏洞就用到了防御規(guī)則。

在前面匹配到了定位規(guī)則(MongoClient(\s*)\((\s*)\”\w*\”)后，這里由匹配到了防御規(guī)則MongoCredential\.createScramSha1Credential\(

由于匹配到了防御規(guī)則所以這里is_vul=False可以判斷沒有代碼風險。

如果采用Java原生API訪問MongoDB沒有認證代碼，那么這里就無法匹配到防御規(guī)則因此is_vul=True，說明業(yè)務方?jīng)]有對MongoDB進行鑒權，因此可以判定為存在代碼風險。

文章轉自FreeBuf.COM