作者AmosYang (泛用人型編碼器)
看板Soft_Job
標題Re: [心得][.NET] GetHashCode()
時間Sun Nov 27 15:29:11 2016
新話題,資訊安全(information security),開篇新文章 :)
※ 引述《AmosYang (泛用人型編碼器)》之銘言:
: * C# `System.Valuetype.GetHashCode()` 潛在效能、安全問題
: http://www.30abysses.com/TWY/2016/11/21/c_sharp-gethashcode-valuetype.html
:
: ValueType 的 `GetHashCode() 預設實作是把所有欄位(field) 大鍋炒成
: 雜湊(hash)值;有看過些說法主張這可能造成潛在的效能問題外,然而,更嚴
: 重的 是如其原碼註解 所指出的,這多少會在某種程度上把敏感資訊透露出去
: ,也就是有 **潛在的安全問題** 。
:
: 是故,原碼註解主張
:
: 若此 value type 含有敏感資訊,那它應該為 GetHashCode() 提供自己
: 的實作版本。
:
: 推 james732: 不過有可能從標準實作算出的hash去倒推特定的資料嗎? 11/27 14:22
資訊安全(information security)是很機車的 :D 很難從單一 attack vector 來
評估;每個系統的 threat model 不同,當通常你透露給攻擊者的資訊是愈少愈好
========================================================================
舉個例子,假設要設計個有權限控制的檔案系統;假設有這樣一個檔案
/foo/bar.txt
假設使用者可以下「讀檔案」的指令
read /foo/bar.txt
而對沒有權限讀這檔案的使用者,要怎麼回報錯誤?這裡有至少兩個可能性
(1) 「找不到 /foo/bar.txt 」
(2) 「你沒有權限讀 /foo/bar.txt 」
(2) 的 UX *感覺* 比 (1) 好;然而,若我是攻擊者,即使我沒有權限讀檔案,
我仍能把 (2) 當作 File.Exists(string path) 來用;反過來說, (1) 就沒有
透露出「檔案是否存在?」的訊息。
當然,光是有 (2) 或許不足以造成實質上的破壞,但這裡要說明的,就是「意外
地透露資訊」這個觀念;也就是 (2) 的設計,能讓沒有閱讀權限的攻擊者 probe
整個檔案系統;而有時檔名可能就帶有商業機密 (例如,新產品的 codename )
更有趣的是,這永遠是道高一尺魔高一丈、貓追老鼠的遊戲。例如,就算使用 (1)
的設計,就沒問題了嗎?假如說,以下的情形
read /foo/bar.txt
read /foo/non-existing-file.exe
假設 non-existing-file.exe 這個檔案是不存在的,然後又採用 (1) 的設計,
對沒有閱讀權限的攻擊者,兩者都傳回
「找不到 /foo/bar.txt 」
「找不到 /foo/non-existing-file.exe 」
But!假設系統在處理以下兩個情形所「使用的時間」不同
(a) 讀本來就不存在的檔案;傳回錯誤
(b) 讀存在的檔案;讀取使用者身份;讀取使用者權限;比對權限;傳回錯誤
那麼,攻擊者仍能分別出 (a) 與 (b) 的不同;最後這設計仍然「意外地透露
資訊」…
所以說,資訊安全(information security)是很機車的 :D
========================================================================
回到一開始的問題
> 有可能從標準實作算出的hash去倒推特定的資料嗎?
也許大概應該不太可能,但也沒有人能保證 100.00% 零風險。因為你不知道攻擊
者手上有沒有別的資訊(碎片),就差這一塊就能爆機,所以,還是要
threat model 畫出來,風險評估報告作出來,看 mitigation/isolation/etc.
有的沒的五四三的要怎麼作
反正,誰有那個心臟拿那薪水,誰去簽字負責 :D
--
個人 雜談、學習、英語、軟體
https://www.facebook.com/tw.yang.30 https://www.facebook.com/30abysses/
https://twitter.com/twy30 http://www.30abysses.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 70.181.102.71
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1480231756.A.29E.html
※ 編輯: AmosYang (70.181.102.71), 11/27/2016 15:39:51
補述
> 有時檔名可能就帶有商業機密 (例如,新產品的 codename )
像之前 Bandai Namco 出 Summer Lesson 時,就有 *無聊人士* 去研究其日本官
方網站,發現它雖然把 directory listing 關掉了,但從首頁上 Hikari 的人物
圖可以很明顯的看出它的名命規則
http://summer-lesson.bn-ent.net/images/chara/hikari/img_hikari.png
所以該 *無聊人士* 就寫了個簡單的 script, 拿「2012 日本最常見 50 個女姓
名字去踹官方主機」,看能不能碰巧挖出未公開資訊
雖然最後沒挖出任何東西,但世界上就是有這類 *無聊人士* ,以 exploit 不經
意透露的資訊為樂 :D 而 ValueType.GetHashCode() 的原碼註解就是試著在警告
提醒這種事 :)
例如, **假設**
*
http://summer-lesson.bn-ent.net/images/chara/hikari/img_hikari.png 傳
回 HTTP 200
*
http://summer-lesson.bn-ent.net/images/chara/akane/img_akane.png 傳回
HTTP 404
*
http://summer-lesson.bn-ent.net/images/chara/kasumi/img_kasumi.png 傳
回 HTTP 403
即使讀不到 img_kasumi.png 的內容,攻擊者也知道了 "kasumi" 的存在
※ 編輯: AmosYang (70.181.102.71), 11/27/2016 16:01:51
※ 編輯: AmosYang (70.181.102.71), 11/27/2016 16:09:00
推 Ekmund: 仔細想想 我好像幹過這種事...(" 艸) 11/27 18:44
推 sing10407: 寫爬蟲的時候最喜歡猜規則了XD 11/27 19:34
自學起手的碼猴,十個裡面大概有九個有寫過爬蟲抓圖的程式或 script... 剩下
的那一個直接架站 :D
推 sivid: 好文推推 11/27 19:44
推 SeaSprite: Very well said! 11/27 22:25
推 mummyqq: 說的真好 11/27 23:28
→ yyc1217: 但一律回傳404會讓工程師很難debug 建議還是要有log 11/28 00:35
推 zombiesky: 回樓上 可以讓開發模式和正式模式 回傳不同訊息 11/28 03:28
是的,不同的危機等級,有不同的作法。在商業上也有反向操作,故意流出資訊,
製造 hype 的作法 :D 這篇文的起源是 ValueType.GetHashCode() 的作者無法預
測所有的情形,所以只是用 "should" == "應該" 建議一個作法。
題外話,關於規格書中 should/should not/must/must not 這類用詞,可以參考
這篇 RFC
https://www.ietf.org/rfc/rfc2119.txt
有更詳細的說明 :)
※ 編輯: AmosYang (70.181.102.71), 11/28/2016 05:01:39
這篇文整理後收錄於
http://www.30abysses.com/TWY/2016/11/28/information-security.html
另外寫了篇文,簡介 RFC2119
http://www.30abysses.com/TWY/2016/11/28/rfc2119.html
※ 編輯: AmosYang (70.181.102.71), 11/29/2016 14:29:59
推 zanyking: 推! 12/02 08:00