傑奇 緩存漏洞_緩存欺騙：我如何在Medium中發現漏洞并幫助他們修複它

傑奇 緩存漏洞

by Yuval Shprinz

由Yuval Shprinz

緩存欺騙：我如何在Medium中發現漏洞并幫助他們修複它 (Cache Deception: How I discovered a vulnerability in Medium and helped them fix it)

In my previous post, I tried to demonstrate how powerful and cool reverse engineering Android apps can be. I did this by showing how to modify Medium’s app so all membership-required stories in it would be available for free.

在我以前的文章中 ，我試圖證明反向工程Android應用程式有多麼強大和酷。 我通過顯示如何修改Medium的應用程式來做到這一點，以便該應用程式中所有需要會員資格的故事都可以免費獲得。

Well, there was a bit more to the story :)

好吧，這個故事還有更多内容:)

While working towards my desired goal, I found a large collection of API endpoints that Medium declared in their code, which exposed a neat Cache Deception vulnerability after a short iteration on them. I was especially excited about that find because cache-based attacks are exceptionally awesome, and it could have been a great addition to my story.

在朝着我的目标努力的過程中，我發現Medium在其代碼中聲明了許多API端點，這些端點在經過短暫的疊代後就暴露出一個整潔的Cache Deception漏洞。 我對這一發現感到特别興奮，因為基于緩存的攻擊異常出色，這可能對我的故事大有助益。

Unfortunately, it took Medium three months and a couple of reminders to respond, so I had to wait with the public disclosure for a bit.

不幸的是，Medium花了三個月的時間，并催促了一些回複，是以我不得不等待公開披露。

In this post, I will try to explain intuitively what Cache Deception is, describe the bug at Medium, and reference two outstanding articles about cache-based attacks.

在這篇文章中，我将嘗試直覺地解釋什麼是“緩存欺騙”，描述Medium的錯誤，并參考兩篇有關基于緩存的攻擊的出色文章。

緩存欺騙 (Cache Deception)

Web browsers cache servers’ static responses so they won’t need to request them again — saving both time and bandwidth.

Web浏覽器緩存伺服器的靜态響應，是以它們無需再次請求它們-節省了時間和帶寬。

In a similar principle, servers and CDNs (Content delivery networks, Cloudflare for example) cache responses too (their own responses), so they won’t need to waste time processing them again. Instead of passing to the server a request that the CDN already knows its response to (i.e. a static image), it can return a response immediately to the client and reduce both server load and response time.

按照類似的原理，伺服器和CDN(例如内容傳遞網絡，例如Cloudflare)也緩存響應(它們自己的響應)，是以它們不需要浪費時間再次處理它們。 除了将CDN已經知道其響應的請求(即靜态映像)傳遞給伺服器之外，它還可以立即将響應傳回給用戶端并減少伺服器負載和響應時間。

When servers cache static responses, everyone benefits from it. But what happens when a server caches a non-static response that contains some sensitive information? The server will start serving the cached response to everyone from now on, hence making any sensitive information in it public!

當伺服器緩存靜态響應時，每個人都将從中受益。 但是，當伺服器緩存包含某些敏感資訊的非靜态響應時，會發生什麼情況？ 從現在開始，伺服器将開始向所有人提供緩存的響應，是以将其中的任何敏感資訊公開！

So that’s basically what Cache Deception is — making servers cache sensitive data, by exploiting badly configured caching rules. After the sensitive data is cached, an attacker can come back to hoard it, for example.

是以，這基本上就是“緩存欺騙”的内容-通過利用配置錯誤的緩存規則，使伺服器緩存敏感資料。 例如，在緩存了敏感資料之後，攻擊者可以再次将其存儲起來。

緩存使用者個人資料 (Caching User Profiles)

Medium uses the library Retrofit to turn their HTTP APIs into Java interfaces for their Android app, so basically every endpoint lies nicely in their code with all of its available parameters specified. I extracted all of them to a list that ended up being about 900 endpoints.

Medium使用Retrofit庫将其HTTP API轉換為其Android應用程式的Java接口，是以基本上每個端點都在其代碼中很好地指定了所有可用參數。 我将所有這些提取到一個清單中，最終得到大約900個端點。

That list was a real treasure, so I couldn’t stop myself from spending some time iterating it. Among other things, I looked for URLs that ended with user controlled input, because there is a common miss-configuration of caching services to cache every resource path that looks like a file. Remember, our goal is to find endpoints that both contain sensitive information and are cached by Medium’s servers. So, finding an API endpoint that’s being cached would be great.

該清單是一個真正的寶藏，是以我無法阻止自己花費一些時間對其進行疊代。 除其他外，我尋找以使用者控制的輸入結尾的URL，因為存在一種常見的緩存服務配置錯誤，用于緩存每個看起來像檔案的資源路徑。 請記住，我們的目标是找到既包含敏感資訊又被Medium伺服器緩存的端點。 是以，找到要緩存的API端點會很棒。

As it turned out, Medium indeed cached paths that looked like files by default, but only for resources that were right under the root directory of the site, URLs like

https://medium.com/niceImage.png

.

事實證明，預設情況下，Medium确實确實緩存了看起來像檔案的路徑，但是僅針對網站根目錄下的資源(如

https://medium.com/niceImage.png

緩存。

Fortunately, my beautiful list contained one endpoint that held the above requirements — user profile pages. By setting my username to “yuval.png”, my profile page URL became

https://medium.com/@yuval.png

, and when someone visited it, its response was cached there for a while (4 hours, then the server dropped it). And that was actually the whole bug, setting usernames to end with a file extension -in order to cause profile pages to be cached.

幸運的是，我的清單很漂亮，其中包含一個滿足上述要求的終結點- 使用者個人資料頁面 。 通過将我的使用者名設定為“ yuval.png”，我的個人資料頁面網址變為

https://medium.com/@yuval.png

，當有人通路它時，其響應被緩存了一段時間(4小時，然後是伺服器)删除)。 這實際上是整個錯誤，将使用者名設定為以檔案擴充名結尾-以導緻配置檔案頁面被緩存。

What sensitive information can be extracted from cached responses of visits to my profile page?

從對我的個人資料頁面的通路的緩存響應中可以提取出哪些敏感資訊？

• CSRF tokens. Those are embedded in the returned document. (Cross-Site Request Forgery in simple words)

  CSRF令牌。 這些嵌入在傳回的文檔中。 ( 簡單的跨站請求僞造 )

• Information about who viewed my profile. The currently logged in user can also be extracted from returned documents.

  有關誰檢視了我的個人資料的資訊。 也可以從傳回的文檔中提取目前登入的使用者。

The fact that each cached response was there for 4 hours and blocked other responses from being cached wasn’t a problem, because by using a simple script usernames can be changed repeatedly (and generate new URLs that aren’t cached yet).

每個緩存的響應在那裡存在4小時并阻止其他響應被緩存的事實并不是問題，因為通過使用簡單的腳本，使用者名可以重複更改(并生成尚未緩存的新URL)。

Note that this bug could have also been used by users that were willing to hide the “block user” option on their own profile page, if they repeatedly entered it (again, using a script). This would work because users don’t have the option to block themselves on their own profile and so others wouldn’t have it either when they receive a cached response that was created for the account owner.

請注意，如果使用者重複輸入(再次使用腳本)，則願意在其個人資料頁面上隐藏“阻止使用者”選項的使用者也可以使用此錯誤。 之是以可行，是因為使用者沒有選擇阻止自己的個人資料的權限，是以其他人在收到為帳戶所有者建立的緩存響應時也不會擁有自己的個人資料。

報告時間表 (Report Timeline)

I sent Medium my report through their bug bounty program, and here’s the timeline:

我通過他們的漏洞賞金計劃向我的報告發送了媒介，這是時間表：

Aug 24 — Sent my initial report, and received an automatic email which said that Medium would try to get back to me within 48 hours.

8月24日-發送了我的初次報告，并收到一封自動發送的電子郵件，其中說Medium将嘗試在48小時内回複我。

Sep 14 — Checked with them if something wasn’t clear since they hadn’t responded yet.

9月14日-與他們核實是否有不清楚的内容，因為他們尚未回複。

Nov 1 — Issued another message, saying was fine with me if my report got rejected, and asking for a response so I would know they received it.

11月1日-發出另一封郵件，說我的報告是否被拒絕對我很好，并要求答複，以便我知道他們收到了。

Nov 20 — Response from Medium! apologizing for the delay and rewarding my bug with $100 and a shirt.

11月20日-來自Medium的回複！ 對延誤表示歉意，并獎勵我的蟲子$ 100和一件襯衫。

I guess it took them a while because Cache Deception isn’t the usual kind of bug people report — but I was just hoping for a quick response asking me for more explanation or something. I assumed no one was reading their inbox.

我猜他們花了一段時間是因為Cache Deception并不是人們報告的常見錯誤類型-但是我隻是希望快速響應，要求我提供更多解釋或其他資訊。 我以為沒人在讀他們的收件箱。

P.S. the bug was rewarded only $100 because Medium’s program is small, not because it’s lame :P

PS該錯誤僅被獎勵$ 100，因為Medium的程式很小，而不是因為它很la腳：P

基于緩存的攻擊-進一步閱讀 (Cache Based Attacks — Further Readings)

Cache-based attacks have been known for a long time, but were considered mostly theoretical until the recent publish of two outstanding works by Omer Gil and James Kettle. If you find the subject interesting, don’t miss these:

基于緩存的攻擊早已為人所知，但直到最近Omer Gil和James Kettle出版了兩本傑出著作時，才被認為是理論性的。 如果您發現該主題很有趣，請不要錯過以下内容：

Web緩存欺騙攻擊 — Omer Gil，2017年2月 (Web Cache Deception Attack — Omer Gil, Feb 2017)

While demonstrating it on PayPal, Omer claims the term Cache Deception for this new and amazing attack vector.

當在PayPal上進行示範時，Omer稱呼“緩存欺騙”一詞是指這種新穎而驚人的攻擊媒介。

實用的Web緩存中毒-James Kettle，2018年8月 (Practical Web Cache Poisoning — James Kettle, Aug 2018)

Cache Poisoning has been known for years, but by publishing his extensive research James made it practical. Check out his follow up article on the subject “Bypassing Web Cache Poisoning Countermeasures” too.

快取毒藥已廣為人知，但詹姆斯發表了廣泛的研究成果，使之實用化。 也可以檢視他關于“ 繞過Web緩存中毒對策 ”主題的後續文章。

See you next time…???

下次見... ???

翻譯自: https://www.freecodecamp.org/news/cache-deception-how-i-discovered-a-vulnerability-in-medium-and-helped-them-fix-it-31cec2a3938b/

傑奇 緩存漏洞