百度安全的 OpenRASP 項目，到底是什麼？

百度安全的 OpenRASP 項目，到底是什麼？

本文做者史中，首發自公衆號【淺黑科技】，歡迎合理轉載共享知識，也請尊重版權標註做者和出處（淺黑科技）。

聊到最後，c0debreak 打開了一個「機密文檔」給我看。這是一個宅男積累多年的祕密，我眯着眼好奇地湊過去，裏面密密麻麻的都是。。。。對最新網絡安全技術的研究筆記。

「我讓你給我展現一下和工做無關的‘業餘愛好’，XX都X了，你就給我看這個？」我怒道。

「對啊，這就是和工做無關的業餘愛好啊。由於這些技術如今都還用不到工做裏。」 c0debreak 一臉呆萌。

瞬間，我特別想見見那個立刻就要和他結婚的妹子，聽說她也是個程序員。我強烈懷疑他們的蜜月旅行會是：在用馬爾代夫海灘作桌面的電腦上敲代碼。

c0debreak，百度安全工程師，一個比百度工程師還像百度工程師的百度安全工程師。其實，c0debreak 還有另外一個身份，那就是 OpenRASP 項目負責人。

OpenRASP，看到這個名字時，估計不少人也像我同樣升騰起不明覺厲的感受。（我以爲凡是名字裏帶有五個大寫字母的項目都挺有前途，例如：CPPCC，不知道的童鞋可自行百度）其實，OpenRASP 是一個百度安全旗下的免費開源安全項目，全稱應該是：Open­source Run­time Ap­pli­ca­tion Self-Pro­tec­tion 開源實時程序自保護系統。它隸屬於百度 OAESE 智能終端安全生態聯盟，是其中五大開放技術之一。

做爲一個把複雜科技講簡單的媒體，我總結這套系統的功能就是——檢測網絡入侵，從而發現漏洞。

在這類功能的系統中，最著名的要數 WAF，也就是 Web 應用防火牆。WAF 被設置在應用的外部邊界上，能夠經過特定的規則和模式識別出惡意請求，而且把它們拒之門外，是一種被普遍應用，連程序員家的貓都知道的網絡安全系統。

咱們就是想顛覆 WAF！

不可思議，一個不愛說話只對你呵呵笑的宅男工程師在沉默了五秒以後忽然認真地看着你，沒有一點過分直接說出這麼一句「豪言壯語」。

1、顛覆 WAF 的 OpenRASP 究竟是神馬？

在 c0debreak 看來，傳統 WAF 存在一個很是大的問題，歸納起來就是：「由於不夠深，因此不夠爽」。爲了對比兩者的技術實現方式，下面咱們以一幢辦公樓的安保來舉個例子：

WAF——門衛模型

WAF表明大樓的門衛，很遺憾這裏的門衛並無朝陽大媽那種柯南般的智慧。每當走進一我的，他只會攔下來問：「來者何人？」而且把這我的的形態樣貌和手裏的冊子（特徵庫）一一覈對。若是不是「在案」的壞蛋，就一概放行。

雖然特徵庫在不停升級，可是從壞人的角度來看，這樣的門衛並不是無懈可擊。若是我是小偷，我今天來的時候能夠戴一頂紅帽子，明天能夠換一頂綠帽子，後天甚至男扮女裝。對於技術水平通常的 WAF 來講，極可能「穿上馬甲你就不認識我了」。而智能程度高一些的 WAF，能夠利用技術識別出一些「變裝」伎倆，但這時對方一樣能夠用「整容」甚至「換人」的方法，加大成本再次騙過門衛的眼睛。

若是想有效地阻止壞人，WAF 必須以很是高的頻率升級特徵庫，但即便是這樣，它仍然沒法擺脫兩個弊端：一、永遠追在敵人後面跑。二、高居不下的誤報率。

OpenRASP——管家模型

RASP 技術，乾脆選擇了另外一個思路，它把防禦系統跑在每個應用內部。仍是以大樓做比喻，這至關於在每一個辦公室裏都設置了一位管家（就是上圖這個 Superman）。無事不登三寶殿，壞人進入大樓，確定是要作壞事的。因此 RASP 的思路是：你長了一張什麼臉我並不關心，重要的是你有沒有在房間裏作出「攻擊動做」。

c0debreak 給我看了 OpenRASP 的技術文檔，裏面列舉了25類「攻擊動做」。

這其中包括：數據庫 SQL 注入、數據庫慢查詢、任意文件上傳、敏感文件下載等等。。。

每個攻擊場景，都有具體的代碼描述，而這種描述，相比 WAF 上繁複的規則要簡單許多。正如世界上的騙局有千萬種，但最後無外乎是把你口袋裏的錢掏出來；世界上越獄的方法有千萬種，但最終的動做都是離開牢房；漢子們對姑娘的花言巧語永遠在翻新，但最終目標都是【此處省略三個字】。只要你能站在事件的邏輯中心，分辨出真僞善惡就相對容易不少。

利用對「攻擊動做」的判斷，OpenRASP 能夠比較精準地揪出惡意攻擊行爲，有了惡意行爲，就能夠由此回溯，找到未被發現的漏洞。

2、OpenRASP 厲害在什麼地方？

若是不考慮技術實現的難度和成本，顯然爲每間辦公室單獨設置一個管家比在大門口設置門衛的模式更爲安全，由於管家們能夠看到門衛看不到的「詳情」。類比到 WAF 和 OpenRASP 上，這意味着兩種安全系統可供判斷的信息量是不同的。

WAF 掌握的是軟件的「入口流量」，

而 OpenRASP 卻掌握了內部全部動做的「上下文聯繫」。

這一樣能夠用一個例子來講明：

在 WAF 所表明的「門衛模型」中，若是一我的帶着錘子進入辦公樓，門衛無權攔截他，由於這我的並沒作什麼傷天害理的事情，並且依照規章，帶錘子進入辦公室也何嘗不可。

在 OpenRASP 所表明的「管家模型」中，一樣仍是這我的，進入辦公室以後，卻猛地用錘子砸向文件櫃上面的鎖，那麼毋庸多言，管家上來一個掃堂腿撂倒即是。

你看，之因此門衛不敢攔下這個拿錘子的人，就是由於他不掌握這我的接下來的行動信息。而房間裏的管家，倒是有充足把握作出判斷的。

實際上，OpenRASP 身處應用內部，還有諸多的好處。爲了說明 OpenRASP 技術的優勢，c0debreak 用了四個關鍵詞：

一、誤報

廣義的黑客「攻擊」，應該包含兩個方面：一、掃描；二、實際進攻。這大概對應着竊賊的「踩點」和「盜竊」兩個步驟。

這裏有一個重要的認知：「踩點」自己是不違法的，甚至對你來講是不用在乎的。

爲何這樣說呢？看過阿凡提的叔叔阿姨們應該記得，有一集講的是盜賊挨家挨戶踩點，最終選定了幾家做爲盜竊對象，而且在門口標記了記號準備晚上「光臨」。（固然陰謀被神勇的阿凡提發現了而且把每一家門口都畫上了一樣的記號）

科普一下竊賊在你門口作標記的含義

我想說的是，你家大門被各類人打量，並不意味着你必定會被盜。說回黑客攻擊，藉助自動化工具，黑客進行的掃描行爲多是實際進攻行爲的萬倍或億倍之多。這是一種典型的「廣種薄收」的策略，絕大多數掃描僅僅停留在掃描。若是你的系統沒有攻擊價值，或沒有他掌握的漏洞，黑客根本就不會對你採起下一步動做。

有了這個背景知識，你就能夠進一步感覺 WAF 和 OpenRASP 的區別了。

c0debreak 給我舉了個栗子：

若是有人掃描了一個根本不存在的路徑，這極可能就是自動化程序進行的掃描，產生威脅的可能性很是小。可是因爲 WAF 不掌握應用內部的信息，它沒辦法判斷掃描的危害性有多大，所以保險起見只能報警。

這時 OpenRASP 的優點就很是明顯，它知道應用內部的路徑，因此就會選擇不報警。

這就是 OpenRASP 誤報率低的原理之一。

二、兼容

若是你看過《唐人街探案2》或者更早的《不見不散》，你可能記得裏面都出現了中國人教美國警察說漢語的細節。爲啥美國的警察要學說漢語？很簡單，由於做爲安全保衛者，須要和你的被管理者有語言交流。

一個正常的應用，在URL裏面用「&」來分割請求參數，可是，在有些語言中，也能夠用「;」來分割。若是你不知道參數還能夠這樣寫，那麼你必定會漏掉一些攻擊的代碼。

c0debreak 說。

仍是以前的原理，WAF 存在於應用以外，它不知道也不關心應用自己是什麼語言寫成的。這就很難徹底兼容後端應用的特性，而 c0debreak 和團隊，根據 Java、PHP 等每一種語言來獨立開發。這雖然會耗費不少時間和精力，可是換來了很是好的兼容性。

三、應用熱補丁

正如以前所說，同一類漏洞，在黑客手裏可能被披上各類假裝來使用。這些類似的攻擊方法，在 WAF 看來卻沒有內在聯繫，對於每一種都要逐一添加規則。其實，這樣作的最大問題並不在於「笨」，而是在於「慢」。

一旦黑客成功突破進入系統，就有可能迅速安插後門。後門設置成功，就至關於多了一條供他來去自由的密道，根本不用再走大門。WAF 再想發現他的難度就大大增長。

而 OpenRASP 在應用內部，把攻擊動做抽象成爲一種「OGNL表達式」，大意就是透過現象看本質，任你千路來，我只一路去。只要是利用原理相同的攻擊手法，不管外表怎麼翻新，均可以被直接識別。

這就是 c0debreak 所說的「應用熱補丁」，從某種程度上說，它能夠防禦「未知攻擊」。

最近三年，Struts 漏洞被爆出三十多個，可是針對這些漏洞的利用方法，其實都收錄在咱們的25條攻擊套路以內。根據咱們的測試數據，是徹底能夠攔截的。

他說。

四、安全編碼

既然把 OpenRASP 比做是「辦公室」裏的管家，那麼除了「抓賊」的做用之外，他必定還有幫你作好內部安全規範的做用，好比機密文件不能隨意放置，不要把鑰匙掛在鎖上等等。。。

在企業服務器裏，這種情形一樣存在：

數據庫查詢的時候，有哪些字符串的拼接是不能出現的；哪些敏感的函數是不能讓數據庫本身使用的，等等這些編碼規範問題形成的漏洞，應該在研發階段就消滅在萌芽裏。若是 OpenRASP 被嵌入在應用裏，隨着系統開發流程，這些錯誤都能被警告和糾正。

c0debreak 說。

另外，OpenRASP 還能夠輔助服務器調整安全基線，例如服務器的某些安全策略是否是被開啓，是否是存在弱密碼等等問題。

從這幾點來看，OpenRASP 確實頗有前途。

3、「OpenRASP」的「Open」

其實，有關 RASP 的理念，早在2014年就已經被提出，而且被世界頂級諮詢公司 Gartner列爲應⽤安全領域的「關鍵趨勢」。

這就讓我想到兩個問題：

一、爲何四年以來，RASP 仍然沒能取代 WAF 的江湖地位？
二、百度安全如今推進這種技術，是否有前途呢？

這兩個問題，還真不太好回答，不如來看三個小故事。

1st

CPU 性能損耗 20%。

「臥槽！」c0debreak 看着這樣的數據，心裏實際上是崩潰的。

此刻是2017年9月，這就是 OpenRASP 最第一版本的性能。

其實他心裏比誰都清楚，性能原本就是 RASP 技術相比傳統 WAF 的最大劣勢。畢竟在每一個應用內部都強勢安插了那麼多「內線」，這些進程人吃馬喂，哪一個不向 CPU 要糧餉？

一個安全進程消耗了 CPU 20% 的性能，就比如你請的管家要花掉全家五分之一的收入，不用說，連我都知道不會有人買單。（不過 OpenRASP 是開源項目，原本就不須要花錢。即便這樣，這種指標仍是意味着幫倒忙。）

他知道，本身和團隊掉進了一個全部 RASP 技術開發者都曾經掉進的坑。這樣的性能指標拿出去，百度丟人，百度安全也丟人。更可怕的是，爲了下降社區參與的門檻，團隊採用了以前沒人在這類產品上使用的 JavaScript（JS）語言編寫了全部的檢測邏輯。以致於連可參考的前人經驗教訓都沒有。

項目上線的幾個月的時間裏，團隊都在爲解決這個問題發愁。走投無路的時候，他們甚至都已經決定放棄以前的全部代碼，把編程語言換成 Lua 從新開發。實際上，他們已經着手開始作新的 Demo 了。

很巧，某日一位團隊小夥伴突然擡起頭，用百度程序員特有的冷靜語氣對 c0debreak 說：那個，我好像找到了解決的辦法。。。

他的辦法就是，用火狐最新版的 Rhino 引擎替代以前的谷歌 V8 引擎來編寫代碼。
就是這個歷來沒有人嘗試過用的 JS+Rhino 組合，把 CPU 的性能損耗迅速降到了1%-5% 的可用水平，做爲 RASP 產品中惟一開源的一個，OpenRASP 的性能開始超越市面上大多數的商業產品。這讓 c0debreak 和團隊大鬆一口氣。由於就在幾個月之前，項目仍是「生死未卜」的狀態。

2nd

時間倒回2017年8月。

此時的 c0debreak 還在焦灼地等待一個「判決」。

一個月之前，他就把 OpenRASP 的項目計劃書遞交領導審覈了，百度安全實驗室的負責人韋韜從技術角度很快開了綠燈，如今項目就放在百度安全總經理馬傑的桌面上，等待他最後拍板。

可是一個月的時間過去了，沒有音信，c0debreak 慌了：「我感受當時這個項目要被砍了，以爲蠻惋惜的。」

而另外一邊，馬傑面對 OpenRASP 的計劃確實有些猶豫。但讓他拿不定注意的最主要緣由，不是「RASP」，而是「Open」。

久經沙場的安全「老炮兒」馬傑很是明白，要運營一個開源項目，靠的可不是頭腦一熱。

首先，開源項目須要投入很大精力來宣傳和經營，若是發出去就無論了，那麼命運確定是死路一條，這些年輕人是否能堅持下去是個未知數。

其次，開源項目是免費的，須要經過建設生態來實現效益，而 OpenRASP 團隊沒人有開源項目的經驗，將來要面對的挑戰確實不小。

可是，沉默寡言的 c0debreak 在這件事上表現出少見的堅持，他三天一個表決心，五天一個問進度，一副赴湯蹈火永不言敗的姿態。

縱然有所推遲，但馬傑最終給這個年輕人投出信任票；c0debreak 拿到批覆，沒有多說一個字，火速開工。這是一個典型的屬於百度的溫情故事。

3rd

其實「開源」兩個字，很能表明最近兩年百度身上發生的變化。

從開源深度學習平臺 PaddlePaddle 到開源自動駕駛平臺 Apollo，看上去百度要在開源這條路上越走越遠了。

OpenRASP 也是這條路上的一份子。

某種程度上說，一個開源項目的運營，靠的不只僅是核心技術團隊，而是認同這個項目的社區中的每一個人。

除了技術開發自己，讓這個項目得到更多的認同，也是 c0debreak 迫切要作的事情。

他在百度內部各個部門「奔走呼號」，先說服幾個部門灰度測試了 OpenRASP 系統；幾個月來，他還在公衆平臺上不斷髮布 OpenRASP 的技術解析文章，「以死相逼」讓身邊的技術大牛轉發宣傳；他甚至找來一些比較成功的開源項目，從他們的代碼提交記錄裏一點點學習運營開源項目的經驗。

功夫不負有心人，百度安全實驗室老大韋韜轉發的一篇文章引發了OWASP（開放式Web應用程序安全項目組織）的關注，幾天後，OpenRASP 的介紹出如今了OWASP 的網頁上。

也就是在這些日子，OpenRASP 的技術交流 QQ 羣不斷涌進來不少人。c0debreak 立刻帶着三個同事客串客服，忙得不亦樂乎。

一開始人們問的都是怎麼安裝怎麼配置的問題，到後來，問題就變成了支持什麼型號的服務器，支持什麼架構。項目主頁上用於點讚的「Star」按鈕，也開始有人點擊。

OpenRASP 項目在 GitHub 上的主頁

幾個月的時間裏，c0debreak 和同事天天盯着 Star 的個數。每多一個 Star，他們都感受爽爆了。

2018年2月4日，對他和團隊來講是一個值得記念的日子。這一天，OpenRASP 收到了第一份「Pull Request」，也就是代碼合併請求。「社區中有人對項目的代碼進行了升級，而且想合併到主代碼中，這意味着有人開始主動爲社區作貢獻了，開源的意義真正被體現出來了！」他興奮地說。

就在一個星期之後，團隊又收到了一封來自西班牙的郵件，那位程序員用英語詢問 OpenRASP 何時能夠支持 PHP 語言。c0debreak 滿懷激動地認真回覆了郵件，要知道，他們甚至還沒來得及把技術文檔翻譯成英文，目前只有官網上有一些簡單的英文Q&A。

c0debreak 以爲，這個項目的發展甚至超過了本身最好的預期。短短几個月時間裏，惟品會、蘇寧、攜程、科大訊飛、綠盟等等大企業都已經開始內部測試這套系統，而且根據這套開源代碼定製本身須要的版本。

和這些用戶交流，詢問他們的意見和需求，如今成爲了 c0debreak 重要的工做之一。

他盯着屏幕上已經累積到300多的「Star」，嚴肅地說：「看來將來幾年，我都要全心投入在這個項目上了。」

在 Github 頁面上，標註了項目的路線圖和里程碑

三個故事講完了。

可能你心中的疑問被解開了，也可能你有了更多疑問。

c0debreak 和百度安全的同事們創造了 OpenRASP，而且奮力讓它成長至今。他們想要的東西很簡單，那就是讓更多人瞭解 OpenRASP，承認 OpenRASP，願意爲 OpenRASP 作點什麼。

打開網絡空間搜索引擎 Shodan，裏面已經能夠查到不少第三方公司利用 OpenRASP 作的安全項目。至於他們是誰，具體怎樣使用 OpenRASP，c0debreak 並不瞭解，但他感到很幸福。「潤物細無聲」，這正是開源的魅力所在。

在 Shodan 上，搜索到「OpenRASP」的地區，就會被標爲紅色，如今地圖上只有四個國家。我問 c0debreak 將來的計劃，這個技術宅楞了一下，而後把手一揮，說：「全變成紅色。」

我忽然明白，對於開源世界來講，最好的姿態莫過於：

心懷夢想，信馬由繮。

再自我介紹一下吧。我叫史中，是一個傾心故事的科技記者。個人平常是和各路大神聊天。若是想和我作朋友，能夠關注微博：@史中方槍槍，或者搜索微信：shizhongst。

不想走丟的話，你也能夠關注個人自媒體公衆號「淺黑科技」。