我正在針對我正在開發的應用程式運行安全掃描程式，它正在上升紅色警報，gem rotr 的最大安全執行緒，它在其 Gemfile 源中使用 HTTP 協議揭示了中間人攻擊的可能性，這可能允許攻擊者將任何代碼注入應用程式
相關 Gemfile 的鏈接 - https://github.com/mdp/rotp/blob/master/Gemfile
它指出：
source 'http://rubygems.org'
如果這個 gem 被列為依賴項并且在我的 Gemfile 中我正在使用，這是否真的有問題：
source 'https://rubygems.org'
我試圖找出它到底是如何作業的，但沒能做到。
即捆綁器的作業方式：
它拉我從http指定所有寶石小號：//rubygems.org，然后將其拉所有依賴分別為每個寶石，從每個Gemfile中（對于每個寶石）指定的源和在ROPT寶石的情況下，它從拉HTTP：/ /rubygems.org（不是 https）——因此在安裝 ropt gem 時為中間人攻擊打開了理論上的可能性
Bundler 從 MY Gemfile (http s ://rubygems.org) 中指定的源中提取所有 gem，因此即使 Gem 指定http://rubygems.org (NOT https) - 它也會通過安全協議從我指定的位置，因此理論上沒有人在中間攻擊的可能性
uj5u.com熱心網友回復：
在您的示例中，gem 將通過 HTTPS 加載，因為Gemfile根本不會加載依賴項。從依賴項來看，gemspecBundler僅評估檔案。寶石Gemfile僅在開發該寶石期間使用。在這種情況下有趣的閱讀：如何捆綁優先級來源。
以下為感興趣的讀者提供為什么HTTPS在下載 gems 時使用很重要：
當您從非 HTTPS 源加載 gem 并且存在中間人攻擊者時，該攻擊者將能夠向您發送任何內容而不是您請求的 gem。
當然，也有男人ifs和whens。但是讓我們假設您要在像純 HTTP 這樣的非安全通信通道上下載 gem。讓我們假設有一個中間人攻擊者能夠嗅探您的流量。當在咖啡館或酒店使用相同的 WiFi 時，或者當資料中心的虛擬服務器上有不同的客戶或他們可以物理訪問您的座機時，這可能是可能的。
因為他們可以讀取您對 gem 的未加密請求，然后知道您正在使用哪些 gem。現在想象一下，他們不僅嗅探您的流量，而且還操縱服務器對您的回應。例如，當您請求流行 gem 的新版本來處理用戶身份驗證和授權或付款時，他們可以向您發送他們的版本而不是原始版本。
他們的版本可能包括一些小的更改，例如：
- 加載時，gem 可以將您的 Gemfile 上傳給攻擊者，這將使攻擊者對您的應用程式有一個很好的了解。
- 加載時，gem 可以獲取所有
ENV變數和/或Rails.credentials將它們上傳到由攻擊者控制的服務器。這肯定會向攻擊者提供您應用程式的所有密碼。 - 因為它更改了處理用戶憑據的原始 gem，惡意 gem 將能夠在用戶登錄或更新其憑據時跟蹤用戶或您的管理員憑據。鑒于許多用戶在任何地方都使用相同的電子郵件/密碼組合，這將是一場噩夢。
- 如果 gem 可以讀取
ENV變數，Rails.credentials那么這意味著它也可以更改它們。例如，連接到另一個支付提供商意味著您客戶的付款將被重定向到不同的帳戶。 - 最重要的是，一旦加載到記憶體中，惡意 gem 還可以用原始 gem 替換自己。什么會使您很難確定您的服務器受到攻擊。
tl;dr 當攻擊者能夠進行中間人攻擊時，他們可以向您發送 gem 的惡意版本。這些惡意 gem 幾乎可以對您的應用程式執行您可以想象的所有操作。當然，像這樣的攻擊并不簡單，但也不是超難。
經驗法則是：盡可能始終使用 HTTPS（不僅用于下載 gem，還用于所有網路流量）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/391217.html
上一篇：選股練習中的減少方法？