如何管理需要客戶端代碼密鑰的npm包的API密鑰？

關于如何安全地處理 API 密鑰，這是一場激烈的辯論。

幾乎我們所有人都知道將它們存盤在服務器端是最好的解決方案，并且永遠不會在客戶端應用程式中公開。

我們的客戶可以向我們的 API 發送請求，我們的 API 可以充當代理向第三方 API 發送/接收資料，并將回應回傳給我們的客戶。

但是，您可以將一些第三方 SDK 集成到您的客戶端應用程式中，并且它們也有自己的 API 密鑰。

例如，Zoom 有適用于 Web、Android、iOS、Windows 等的 SDK，或者 Pusher 有 Pusher Key。

當您想使用這些庫時，您不能向您的 API 發送請求以隱藏 API 密鑰。您必須在客戶端代碼中初始化這些庫（例如，react）。

Zoom 的一個示例，用于在您的 Web 應用程式中加入會議：

client.join({
    apiKey: apiKey,
    signature: signature,
    meetingNumber: meetingNumber,
    password: password,
    userName: userName
})

保護客戶端 SDK 和庫的 API 密鑰的最佳實踐是什么？

uj5u.com熱心網友回復：

你的問題

當您想使用這些庫時，您不能向您的 API 發送請求以隱藏 API 密鑰。您必須在客戶端代碼中初始化這些庫（例如，react）。

保護客戶端 SDK 和庫的 API 密鑰的最佳實踐是什么？

好吧，您發現自己是一個非常難以解決的問題（但在某種程度上并非不可能），因為一旦 API 密鑰在客戶端，它就是公開的。因此，無論您隱藏得有多好，始終可以在瀏覽器或移動應用程式上檢索它。

網路應用程式

在瀏覽器上獲取 API 密鑰非常簡單，只需打開開發人員工具并在網路選項卡中查找您有興趣提取 API 密鑰的請求，然后單擊它以檢查請求標頭。

移動應用程式

在移動設備中，從移動應用程式中提取 API 密鑰更加費力，但很多人可能認為并不那么困難。

JNI/NDK - 在本機 C 代碼中隱藏 API 密鑰

例如，您可以通過JNI/NDK在 C 本機代碼中隱藏 API 密鑰：

使用 Android Studio 2.2 及更高版本，您可以使用 NDK 將 C 和 C 代碼編譯到本機庫中，并使用 IDE 的集成構建系統 Gradle 將其打包到您的 APK 中。然后，您的 Java 代碼可以通過 Java 本機介面 (JNI) 框架呼叫本機庫中的函式。

這種方法旨在保護 AP/i 密鑰不被通過靜態二進制分析從您的移動應用程式二進制檔案中提取，如我寫的這個 repo和博客文章所示：

在本文中，我們將使用Android Hide Secrets研究存盤庫，這是一個使用多種不同技術隱藏 API 密鑰的虛擬移動應用程式。

使用 MitM 攻擊提取隱藏在原生 C 代碼中的 API 密鑰

在上面的博文中，隱藏在帶有 JNI/NDK 介面的源代碼中的 API 密鑰無法通過靜態二進制分析來提取，但是我在文章Steal that Api Key with a中間人攻擊：

為了幫助演示如何竊取 API 密鑰，我在 Github 中構建并發布了適用于 Android的Currency Converter Demo應用程式，它使用與我們在早期的Android Hide Secrets應用程式中使用的JNI/NDK技術相同的JNI/NDK技術來隱藏 API 密鑰.

因此，在本文中，您將學習如何設定和運行中間人攻擊來攔截您控制下的移動設備中的 https 流量，以便您可以竊取 API 密鑰。最后，您將在高層次上看到如何緩解 MitM 攻擊。

通過證書鎖定防止中間人攻擊

防止中間人攻擊的第一件事是使用證書鎖定，我在文章使用證書鎖定保護 HTTPS 中寫了如何做到這一點：

In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.

In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.

I see the smile on your face now, but will not be for long because certificate pinning can be bypassed.

Bypassing Certificate Pinning

You can do it repackaging the mobile app without pinning or by using an instrumentation framework at runtime to disable it.

Repackaging the mobile app to bypass pinning

This is not hard to achieve when you have the correct tools and open source is full of them. I wrote how to do it in the article Bypassing Certificate Pinning

In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.

Using an Instrumentation Framework to bypass pinning

This is my preferred method and my instrumentation framework of preference is Frida, and guess what, I also have an article on it with the title How to Bypass Certificate Pinning with Frida on an Android App to show you how to do it:

Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.

Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.

Possible Solutions

You may employ an array of different approaches and techniques to defend your API server and mobile app, but give preference to use a security solution that spans both the mobile/web app and API server.

The solution(s) to use will depend on your threat model, your budget and your resources and I will give you below pointers to some options.

For Mobile Apps

I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.

For Web Apps

You can learn some useful techniques to help your API backend to try to respond only to requests coming from what you expect, your genuine web app, and to do so I invite you to read my answer to the question Secure api data from calls out of the app, especially the section dedicated to Defending the API Server.

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

For Web Apps

The Web Security Testing Guide:

OWASP Web 安全測驗指南包括一個“最佳實踐”滲透測驗框架，用戶可以在他們自己的組織中實施該框架和一個“低級”滲透測驗指南，它描述了測驗最常見的 Web 應用程式和 Web 服務安全問題的技術。

uj5u.com熱心網友回復：

您到底想保護什么？我假設您想避免有人濫用您的 API 密鑰，但您應該問問自己，您想要保護哪些安全風險或威脅？

您還應該了解您處理的是哪種 API 密鑰，因為并非所有 API 密鑰都針對相同的用例，并且可以“提供”不同級別的安全性。例如，您可以擁有一個形式為 a personal access token（例如在 GitHub 中）的 API 密鑰，其中令牌直接系結到用戶/員工并且應該被視為秘密，或者您可能擁有形式為的 API 密鑰一個機器令牌，它與您的組織或您的存盤庫（例如仍在 GitHub 中）相關聯，并且可以配置不同的權限（只讀、讀寫）。

根據客戶端本身的可能性，也可以配置 API 密鑰并將其限制為某些客戶端。例如，某些 Google Maps API 允許您配置一個可信源，允許使用您的特定 API 密鑰執行請求，但是這種保護是通過檢查請求的參考標頭來實作的，并且它可能會被任意客戶端欺騙。瀏覽器仍應遵守約定并發送正確的引薦來源網址，以保護您免受希望在其網站上使用您的 API 密鑰的人的侵害。

移動應用程式世界中的另一個示例：有些供應商允許您將 API 密鑰系結到特定的包名稱，然后在運行時由供應商的 SDK 進行驗證，但是這種保護通常作為一種許可機制，以避免開發人員免費配置帶有泄露 API 密鑰的 SDK。

最普遍的是，如果 API 密鑰打算在公共客戶端上使用，那么 API 的開發人員已經考慮了泄露的威脅，您不應該有任何影響。這意味著您將免于巨額 API 使用賬單或費率限制/使用配額限制（但最好檢查一下自己！）。

一般規則是始終檢查您嘗試配置的應用程式的開發人員檔案，并查看如何為您的用例創建適當的 API 密鑰，以及是否可以從客戶端“泄露”此密鑰。另外，如果API key允許你配置權限，記得遵循最小權限原則。

另一個黃金法則是始終對您的實施進行威脅建模：

• API 密鑰的功能是什么？
• 如果攻擊者訪問 API 密鑰，他們能做的最壞的事情是什么？
• 我是否在保護自己免受這些威脅？如何？我可以在后端放置更多控制元件或監視器嗎（即高使用率通知等）？

最后，如果您的 API 密鑰需要保密，那么無論它多么隱藏，您都不能在公共客戶端上使用它。總會有至少一個人能夠檢索它（并且也不要依賴客戶端檢查！）。在這種情況下，您可能想要擁有自己的后端服務，負責使用秘密 API 密鑰查詢 API 以及對您的客戶/用戶進行身份驗證和授權，并實施額外的安全措施，例如速率限制。

我發現非常有用的一件事是始終記錄任何生成/使用的 API 密鑰及其功能，以及它們泄露的威脅以及一些預防措施以最大限度地降低風險。

標籤：安全 客户端 api-key

上一篇：如何從一張影像中自動檢測特定特征并將其映射到另一張蒙版影像？那么如何只平滑影像的角落呢？

下一篇：java介面的冪等性及解決方案