大家都來談談安全漏洞等級的評價吧,你認為怎樣的標準合理呢?怎麼讓業務或者是其他安全團隊接受的你判斷。

先聲明,我個人的評價標準是先看漏洞的危害和影響的大小,然後再看漏洞的利用難度。所以基本上涉及特別敏感的信息,並且利用較為簡單,不管是xss還是csrf,異或是jsonp劫持,我都是毫不猶豫給高危,但是沒想到經常否定。談談你遇到的各種奇葩事情吧。


謝邀。

先回答下題主的問題,題主說"基本上涉及特別敏感的信息,並且利用較為簡單,不管是xss還是csrf,異或是jsonp劫持"都是"毫不猶豫"給高危。

涉及敏感信息且利用簡單的xss,評定為高危。那麼,涉及敏感信息且利用簡單的SQL注入,評定為什麼等級?嚴重?

xss和sql注入的漏洞影響、利用難度能一樣么?一個直接就脫褲獲取所有信息了,一個還需要交互才能獲取信息。

如果按照xss都為高危,那麼sql注入就是嚴重了。那這種情況下,漫遊內網的又算什麼級別?

漏洞評級,就是為了區別不同漏洞的級別。

在討論下漏洞評級(以下討論只針對web漏洞的情況)。

對於漏洞(以下均指web漏洞)評級,我認為可以從三個緯度來綜合定級。(這個三個緯度可以在進行擴展出更多更全的緯度)

漏洞影響、可利用性、受影響範圍。

對於每種漏洞可以有個基礎分,在根據這三個維度的綜合評判來得到最後的分數,確定漏洞等級。

基礎分值 + 漏洞影響分值 + 可利用性分值 + 受影響範圍分值 = 最終漏洞等級

1.漏洞影響

對於漏洞影響,很多人都喜歡自己yy漏洞的影響。

比如挖到一個ssrf就認為是高危/嚴重漏洞,就覺得自己可以搞定內網。但你是否了解這個ssrf的影響只是能探測?只允許http協議?在比如,挖到一個支付相關的漏洞,0元購買商品,然後下單成功,在通過退款套現。提交給相關廠商,廠商只是給了中危或者低危。為什麼?因為廠商比你更了解相關業務,你認為這是一個高危或者嚴重的漏洞。但是你是否知道這個訂單已經被風控攔截掉了?立馬削弱了漏洞的影響。對於一個漏洞的影響,我相信廠商比提交者更能準確評估一個漏洞的影響大小。

2.可利用性

對於一個漏洞,很多人都覺得這個漏洞是萬能的。

比如一個xss漏洞,我說我們有http-only防禦,你說xss漏洞不關是用來盜cookie,還可以用來釣魚,探測內網等等.那麼好,你探測給我看,寫出PoC。一個漏洞,可利用性、玩法確實很多,但並不是每一個人都會高難度/猥瑣流的玩法。

3.受影響範圍

對於影響範圍,這個好像並沒有什麼爭議,一個就是一個,兩個就是兩個。對於核心業務和非核心業務,管理員和用戶,在評判的時候是也有不同的分值。

對於一個漏洞,我們可以先給定一個基礎分值,在根據上面的三個緯度確定漏洞的最終等級:

①比如一個反射xss,基礎分值可以給到低危,在從漏洞影響、可利用性、受影響範圍三個角度,往上加分值。最終一個反射xss最高可以上升到中危範圍。

②在比如一個self-xss,基礎分值也是低危,如果你像@Friday表姐那樣,在配合csrf利用,擴大漏洞的影響,那麼最終就可能評定為中危這個範圍(多個漏洞綜合利用)。

③在在比如一個ssrf漏洞,你說"這個可以探測內網,假設你內網有可以匿名訪問的redis,我就可以搞定你的內網,所以你認為這是個高危"。比如像ssrf這種漏洞.我可以先給定級為中危漏洞的分值,如果我是已經對這個ssrf做了限制,只允許http協議,那麼假設我內網有可以匿名訪問的redis,你也無法利用成功。更何況這個"假設你內網有可以匿名訪問的redis"這個是yy出來的。可以具體根據三個維度對漏洞分值進行增加,最終一個ssrf可能評定為嚴重,也可能就只是個低危漏洞。

④你利用成功了的漏洞,並不一定是真的利用成功了。之前就遇到一個漏洞,支付相關的漏洞,白帽子通過漏洞進行退款套現,然後自評為高危。但是我們跟風控團隊溝通後,風控告訴我們這類訂單是會被攔截掉的,也就是說白帽子對這個漏洞並不能利用成功。白帽子只是通過漏洞申請退款成功了,錢這個時候還沒到賬,他就認為是利用成功了。

⑤還有一種情況就是對於多個漏洞的綜合利用,這個情況下漏洞影響分值是會增加,但是同時利用難度分值和影響範圍分值就會隨之減小。最終漏洞等級就會飄忽不定。

不了解具體情況,就不要總想搞出個大新聞。

-------------打波廣告.

美麗聯合集團安全應急響應中心(MLSRC)正式上線.歡迎各位大佬,表哥表姐來提交漏洞。http://security.mogujie.com


佳爺轉發微博讓我漲了一個粉,作為報答來回答寫一下我的愚見。

當然只是個人觀點。

關於漏洞評級一直都很模糊,尤其是 Web 漏洞,花樣太多。

看似很簡單的問題為啥會爭論那麼久,還樂此不疲在撕逼,可能是因為站在不同角度看待問題方式和想法不一樣吧。

提交漏洞者我們稱他們為白帽子

建立接收外部漏洞報告的廠商叫做 SRC

還有一方是介於兩者之間的漏洞報告平台,國內以海淀區最大的烏云為代表,其次還有全球最大的補天響應中心,專業做媒體的 Freebuf 旗下漏洞盒子,軟文寫最好的漏洞銀行等

三方各自都有一套漏洞評級機制,又都想以自己的作為標準去評級,這就會很容易出現撕逼現象。

如果是SRC 自願給高危那自然皆大歡喜,白帽子當然也想漏洞評級越高越好,平台作為第三方也不好干涉(每天幾千待審核漏洞沒空去講那麼多大道理去教育廠商該怎樣)撕逼的很多導火索往往是因為廠商沒有能給白帽子一個滿意的評級。

那回到問題本質,換做第四方的吃瓜群眾怎麼看呢?毫無利益糾紛,作為一個局外人也不會當局者迷。

問題里說到涉及敏感信息都應該給高危,先給廠商態度點贊,不過是不是應該考慮利用條件是否苛刻?

限制一個漏洞完美髮揮的因素有很多,比如問題中提到的 XSS 問題,XSS 也有反射型和存儲型之分。

反射型 XSS 大部分是需要主動訪問而且大部分瀏覽器自帶的 XSS Auditor 也很大程度遏制了危害,如果廠商有加 Http_Only 和 CSP 等防禦機制,評級低危也是合情合理,當然這裡沒考慮企業自身業務邏輯,如果能利用這個 XSS 重置任意用戶密碼或者盜刷餘額,那就又是另外一個漏洞,自然需要按照漏洞危害最大化去評級,最典型的就是我偶像@獃子不開口 老師在烏雲提交的《點我鏈接就能》系列漏洞。

存儲型 XSS 也不見得就得是中危或者高危,我認為也是要結合環境和業務去評,舉個 (知乎不支持emoji ?自行腦補栗子圖片。) ,IE6下有很多特性都是 XSSer 非常喜歡的,如果一個存儲型 XSS 只支持 IE6及以下瀏覽器,其實是可以酌情降低評級的(我知道的大部分廠商是會忽略處理),再或者是像騰訊幾年前的活動業務頁面,本身訪問流量就微乎其微,評級當然不能和 "新浪主頁存儲 XSS" 相同。(個人觀點,並不了解 TSRC 關於類似漏洞的評級)

說說 CSRF,這種漏洞往往是需要交互的(用戶訪問)也太依賴業務環境,可中可低可高,比如放到 Weibo,一個 CSRF 發微博漏洞給到高危沒人有意見吧?

再拿騰訊舉例一個思考題(畢竟國內最良心 SRC),QQ 空間大家都有玩過,圖片上傳到相冊里可以加密,沒有密碼不能訪問。那圖片內容就是敏感信息,但並不是對圖片本身進行鑒權,任何人得知圖片 URL 就可以訪問,但圖片 URL 複雜度不可被預測沒辦法大量獲取,這還是漏洞嗎?

很多情況是白帽子說這裡能怎麼怎麼樣,但又不具體分析體現,臆想出來的危害,操作又太敏感作為外部人員身份不能驗證,有些企業可能會直接就忽略,個別良心企業安全人員會去對接相關人員,討論是否能造成實際影響,對漏洞危害不藏著掖著,解決漏洞的第一步是正視漏洞。(出自美劇《新聞編輯室》,原文:解決問題的第一步是承認問題存在。)

--------

15年作為白帽子向各大廠商報告漏洞,16年上半年跑去第三方平台去審核漏洞,現在又滾到了甲方搬磚,三方角色都體驗過,但還是說不好這個問題。(經驗閱歷不夠)

既然說到在甲方搬磚,事實上在甲方還有一個很尷尬也很蛋疼的事情。

漏洞數量往往和 KPI 掛鉤,這也是很多廠商不承認漏洞或者故意壓低漏洞評級的原因吧。

牽扯到一個擔責問題,發現漏洞,是開發擔責呢?還是安全部背鍋呢?

開發擔責,容易企業內部撕逼

安全部背鍋,日狗啊!哪有 100% 的安全啊,那還做毛的 SRC 啊。

所以安全真是個苦逼行業,又找不到女朋友


說到底就兩點:

1.漏洞危害最大化來評價(畢竟你玩不出花樣不代表HC不能玩出花樣 不要把你的用戶想的太有安全意識)

2.結合業務實際來評 不要眼界狹窄到只看漏洞類型 (叫囂著xss和csrf對我們沒用我們不收不收就不收的小姑娘 建議還是多了解下自家業務or多再學習一下吧 阿 這句跑題)

最後 望不撕逼 解決問題為優先 安全是為用戶為企業而做 而非為了個別人的KPI


前一段時間,又針對這個問題下一些相關內容進行了整理,並發布到freebuf,地址為http://www.freebuf.com/articles/security-management/147394.html

定義漏洞的等級,總的說來,可以認為是看漏洞"帶給業務的影響"。具體操作層面,俺這裡有兩個方式,一個是標準模型,一個是實踐經驗。兩個互補,可以綜合考慮。

1.DREAD模型

1.1什麼是DREAD模型?

DREAD模型,包括5個方面:

a.危害性 (damage):如果被攻擊了,會造成怎樣的危害

b.持續生產 (reproducibility):攻擊後恢復運營的簡易度?

c.難度係數 (exploitability): 實施此項攻擊的難度是如何?

d.受影響用戶數 (affected users): 有多少用戶會受到此項攻擊影響?

e.發現係數 (discoverability): 這項威脅是否容易被發現?

1.2如何評價?

這5個方向根據高中低三個程度,可以劃分如下:

1.3如何計算?

一個漏洞具體的等級,可以按照上面的標準,計算給定威脅的值 (1–3)。結果範圍為 5–15。這樣就可以將總分 12–15 的威脅評價為高度危險,8–11 的威脅評價為中度危險,5–7 的威脅評價為低度危險。

道哥的《白帽子講web安全》給出了如下例子:

在一個web網站中,存在用戶賬號被盜威脅,根據DREAD進行評分如下:

a.網站登陸頁面存在暴利破解:D(3)+ R(3) + E(3) + A(3) + D(3) = 15

b.密碼找回存在邏輯漏洞:D(3)+ R(3) + E(3) + A(3) + D(2) = 14

c.密碼可能被嗅探:D(3) + R(3) + E(3) + A(1) + D(3) = 13

d.服務端腳本漏洞(如SQL等): D(3) + R(3) + E(2) + A(3) + D(1) = 12

e.釣魚網站:D(3) + R(1) + E(3) + A(2) + D(3) = 12

f.XSS或其他客戶端威脅:D(3) + R(2) + E(2) + A(2) + D(2) = 11

g.病毒或木馬:D(3) + R(1) + E(2) + A(1) + D(1) = 8

根據計算結果,我們可以得出漏洞的具體等級。

2.個人實踐中增加的兩個應用

實際的在企業的應用時,除了DREAD模型本身,還可以考慮的方式,事先梳理好企業有哪些核心業務,並且根據企業的業務性質和漏洞本身的危害,梳理出不同漏洞類型的默認等級。

2.1核心業務

舉個例子,電商類的企業,電商主站和涉及資金交易的,更可能是核心業務;搜索類的企業,涉及競價排名的,更可能是核心業務.......或者更簡單的方式,大一些的公司自己會梳理自身的核心業務,一般每次發季報年報,榜上有名的都跑不了。一般這種是先考慮企業業務重要性,再考慮安全重要性,當然有些非核心,但是經常出現安全問題,甚至重大安全問題的業務,也考慮劃分在內。

除了核心業務,可以定出非核心業務,或者定出一般業務和邊緣業務。

是否核心業務本身,也是不少企業或者src評價漏洞的標準。當然,核心業務一旦產生安全漏洞,損失和受影響的用戶,往往也是高的,這個與上面的DREAD模型並不衝突,是便於評判的補充。

2.2漏洞類型和默認危害

這個也是個比較容易操作的衡量基準。為啥叫基準而不是標準?因為這裡僅僅指,按照不同的漏洞類型可以給出一個漏洞本身的危害,然後在這個基礎上利用DREAD模型和是否核心進行調節。

舉個例子,SQL注入常見等級嚴重或高危,XSS中存儲型風險高一些,但是反射型一般低一些。以此類推,可以梳理一張不同漏洞類型默認等級,在計算時能夠更快速的判斷漏洞等級。

個人淺見,請多指教。

創建於 2016-12-17

禁止轉載


依稀記得幾個月豬豬俠前輩 @王音 提交過一個漏洞《目錄遍歷到內網漫遊巨人網路--從不可能到可能》這樣看來,目錄遍歷這種漏洞可大可小,要是一般人來提交,估計就是低危、中危甚至忽略了

但是大牛愣是玩到內網漫遊了,依稀記得大牛也耗時三個月才辦下來。

內網漫遊是一種行為,一種危害。嚴格來說不算漏洞『個人見解,歡迎指點』

所以,漏洞本身不存在等級,應該按危害計算,評價的真正標準取決於這個漏洞能夠做什麼。

還有一次,很久以前,我在漏洞平台提交聯通運營商的反序列化漏洞時,這個漏洞本身就是getshell的漏洞,至於更大的危害就要看怎麼處理了。接著我按照以往的漏洞報告編寫,不過在結尾的時候偷了一個懶。之前的漏洞都是800 、1000甚至2000 ,但是這一次沒有給錢。原因是我在最後證明危害的時候只寫了當前庫某個表中的數據量。數據量有2千多萬。

後來我找審核問了一下,為什麼這一次沒錢呢?

他說:萬一這兩千萬數據是日誌信息之類的呢?

握草,從表名來看絕對是敏感信息。但是由於我沒有截圖和說明裡面的信息是什麼,結果判斷為高危,結果還是沒給錢。

提一下,這個漏洞平台的審核標準一向按照信息來評價,一般的系統即便拿到了Webshell或者伺服器也只是高危,但不會有錢。從這一次經歷中我也發現了一件事情,第三方漏洞平台的審核人員都是跟著你的報告去評定危害,比如你提交一個sql注入,這個注入明顯能夠危害到很多東西,但是如果你不去做。他們就當一個普通的sql注入來評定。在很大程度上,我覺得這是為了丟鍋。

所以,在提交漏洞的時候也要清清楚楚的把報告寫好,不要偷懶。這樣才會獲得更好的評價。


審核漏洞看似是個規範化,按漏洞類型給評分的機械式的活,其實對白帽子和安全審核人都是考驗。

對審核人員來說,得思考提交的漏洞能造成多大的影響,而不是單純根據漏洞種類硬性的給一個等級或者Rank,舉例來說。

有的存儲型Xss,通過修改頁面的個人地址,手機號等等嵌入代碼,但是這個地址和手機號僅僅自己可見,只能彈自己,這個存儲型的Xss的漏洞價值就不大,等級自然不會高。

但如果這個有問題的信息是管理員可見的,能拿到管理員的Cookie,獲取後台信息,那麼等級就又不同了。所以審核人員的能力非常重要,一個二把刀的審核人員,特別容易忽略高危的漏洞。

對「白帽子」來說,不少「白帽子」提交Xss,Sql注入,敏感後台等漏洞給個鏈接,好一點的貼個圖,什麼說明都沒有,更誇張的是有的只有個圖,一切還得安全人員自己去復現,你說怎麼給你審核?

如果白帽子能做到覺得漏洞風險很大的時候,增加一些簡要但是必要的描述和漏洞風險的具體表現,那麼審核人員也不會隨意給你評級,至少這是我認為讓審核人員給你的漏洞評級加分的最直接有效的方式。

「最後,願某雲能重生」


CVSS Common Vulnerability Scoring System (CVSS-SIG) Common Vulnerability Scoring System

漏洞盒子 | 互聯網安全測試平台cvss 計算


不請自來~

漏洞價值=業務係數*漏洞係數

這麼說,比如一個反射xss,只是一個http://xxx.xxxx.xxxx.com 的域名的反射,那麼這個反射,就是低危。

但是你利用http://xxx.xxxx.xxx.com這個域名配合了別的csrf之類的,可以修改用戶密碼,敏感信息的,那麼就是高危了。

主要看影響的危害程度。以及利用方式。


不請自來。私以為,單以漏洞類型評定級別本身就是很腦殘的行為。漏洞本身、 數據類型、 利用難度 、受影響用戶群體等等,需要綜合考慮的因素太多太多,何況更多時候,別人都是一套組合拳打過來。


量化損失,直接談錢


菊花公司內部用的是CVSS 3.0。

同時針對安全設計還有一套定級標準,主要維度是 攻擊者接入位置(部署場景)、缺陷利用條件、業務影響。


說一個我們現在所處的環境,為某些省市級政府單位電子政務外網提供漏洞預警與監測服務。不直接貼文檔了,大致是這樣的:

主要根據漏洞當前被利用後能形成的直接危害來分4個級別低危/中危/高危/嚴重

  • 低危: 不好定性為安全漏洞可是可非的問題,但存在一定安全隱患,像後台路徑可知、登錄可爆破等;
  • 中危:基本能明確定性為是安全漏洞的問題,但不直接導致系統中關鍵數據泄露或許可權泄露,像反射型XSS、目錄遍歷等;
  • 高危:能直接獲得數據或能直接獲得應用系統管理員許可權的漏洞,像普通的SQL注入、後台弱口令等、任意文件讀取;
  • 嚴重: 能直接GetShell/遠程執行命令的漏洞,像任意文件上傳寫入/遠程代碼執行/SSH弱口令等。

最後的評級是由這個安全漏洞評級參考(沒有形成標準)+技術人員主觀經驗判斷得出,因此,同一種(個)漏洞因當前利用空間不一樣也會讓評級不一樣。和高大上的SRC按等級發毛爺爺不同的是,這裡的分級最主要的現實意義是讓甲方能方便地進行後續處置讓整個過程能順利流轉,具體的等級與其對應過程流轉就不說了。


推薦閱讀:

HTTPS 和 OpenSSL 是什麼關係?
如何看待大疆漏洞獎勵計劃 ,信息安全研究員疑似遭威脅,拒絕獎勵協議並準備公開獲得的信息?

TAG:網路安全 | 信息安全 | 安全漏洞 |