APIキーを非公開にする必要があるのはなぜですか？
私は1つの小さなプロジェクトでパブリックAPIを使用して作業しましたが、最近、APIキーを使用してプロジェクトを配布すると、これがセキュリティリスクになることを学びました。
だから私は2つの質問があります：
- セキュリティリスクをもたらすAPIキーには何が含まれていますか？
- パブリックAPIを利用するアプリケーションをどのように作成し、セキュリティリスクをもたらすことなくそのアプリケーションを配布するのですか？
確かに誰かがアプリケーションをリバースエンジニアリングできる場合、存在するすべてのAPIキーを抽出できます。
APIキーの機能によって異なります。しかし、APIキーが何かへのアクセスを許可したり、何かへのアクセスを制御したりしている場合、アクセスできるリソースを他の人に便乗させたいのはなぜですか？あなたはしません。
このように考えてください。私はサービスを所有していて、あなたはそのサービスのユーザーです。合意されたサービスレベルに基づいてAPIキーを提供します（おそらく単位時間あたりのAPI呼び出し）。このAPIキーが公開されている場合、他の人がそれを使用してあなたになりすまし、限られたAPI呼び出しを使い果たす可能性があります。
それはおそらく最も懸念される状況ではありません。 APIキーがデータのサブセットへのアクセスのために誰かを認証する場合、APIキーの共有はより重要になります。
APIキーを保護する方法は、使用しているテクノロジーによって異なります。たとえば、Webまたはモバイルアプリケーションを開発する場合、クライアント（Webブラウザーまたはモバイルデバイス）でAPIキーが失われないようにすることで、APIキーを保護できます。代わりに、クライアントが使用するサーバーに残すことができます。クライアントは、適切な呼び出しを行うことができるサービスに対して認証できます。環境によっては、APIキーは異なる環境に保存されるため、暗号化することもできます。
APIキーにはさまざまな種類があります。一部のAPIキーは公開されるように設計されており、通常は公開可能なキーのようなものと呼ばれ、Webページまたはアプリケーションバンドルでユーザーに送信されるように設計されています。このタイプのAPIキーは認証用ではなく、単純な識別用です。これが妥当なユースケースはほとんどありませんが、一般に、セキュリティの低いアプリケーションや、別の場所にセキュリティがある場合は、これで問題ありません。
ただし、ほとんどのAPIキーは認証秘密です。保護するリソースの価値はさまざまです。 API自体が公開データのみを表示していて、プライベートリソースがない場合でも、APIプロバイダーは、APIキーを使用してレート制限を適用できるように要求することがあります。これは、APIキーが漏洩し、誰かがAPIを使用した場合のリスクです。重要なのは、指定した制限に達したために、アプリケーションがサービスを実質的に拒否される可能性があることです。これが有料APIの場合、他の人があなたのAPIキーを使用した場合、不要なコストが発生する可能性があります。
また、APIキーは、サービスプロバイダーがリクエストを実行する必要があることを承認するためのトークンとしても使用されます。 APIキーを漏らした場合、ユーザーは目的のビジネスロジックをバイパスしてアーカイブプロバイダーに直接指示できるため、保護されたリソースを制御できなくなります。
このように考えると、ほとんどの人は自分の私有財産（家、車など）に鍵を配布する習慣がありません。どうして？ これらのキーは重要な資産を保護し、知らない人が物を盗むのを防ぎます。あなたはAPIキーはAPIパスワードと考えることができます。アプリケーションがAPIを使用して許可されていることは何でも、他の誰かがあなたの資格情報を盗んだ場合に実行できます。
コンセプトはデジタルキーでも同じです。唯一の課題は、デジタルキーを保護したり、キーを安全に処理することがより困難になることです。 APIのクライアントごとに個別のキーを提供することも一般的です。これにより、クライアントごとに異なるサブスクリプションレベルまたは権限セットを管理できるようになるだけでなく、APIキーの所有者ができない権限のある監査ログも有効になります repudiate ログに記録されたアクション。
私たちが話している場合OAuth 2、最も一般的なAPIアクセス制御メカニズム、それから2つのキーが心配する必要があります：
- クライアントキー：APIプロバイダーに対してアプリケーションを識別します
- 秘密鍵：誰もあなたを偽装できないようにあなたを認証します
キーの組み合わせは重要です。そのため、OAuth=キーを交換するためにTLSを義務付けています。クライアントキー自体は、保護するリソースに対してそれほど重要ではありませんが、宣伝する必要はありません。秘密鍵は、保護するために追加の対策を講じる必要があるものです。
肝心な点は、どのキーも慎重に保護する必要があるということです。セキュリティの弱点を悪用して欲しいものを手に入れようとしている人はたくさんいます。重要ではない小さなサイトでも、他の場所でユーザーを偽装するために使用できる何かを見つけることができれば、良いターゲットです。
2番目の質問については、OAuth 2が業界標準になった理由があります。これは明確に定義されており、ほぼすべてのプログラミング言語でサポートライブラリが動作します。特に、既存の標準に対するサポートが非常に多い場合は、十分な理由なしにホイールを再発明しないでください。
注：アプリケーションのロジックをリバースエンジニアリングしても、管理するデータへのアクセスが自動的に許可されるわけではありません。アプリケーションを正しく設計すれば、他の人のキーを盗むために必要な情報を必ずしも入手できなくなります。
私は1つの小さなプロジェクトでパブリックAPIを使用したことがありますが、最近、APIキーを使用してプロジェクトを配布すると、これがセキュリティリスクになることを学びました。
真面目に言えば、これをキャリアの早い段階ですでに知っていることを祝福したいと思います。信じられないかもしれませんが、多くの上級開発者は、APIキーの配布によるセキュリティへの影響をまだ知らされていないか、気づいていません。
APIキーに関するこのすべての混乱を招く主な原因の1つは、多くの人が気づいてさえいないことですが、開発者は[〜＃〜]の違いに注意する必要があるということです[〜＃〜]および[〜＃〜] who [〜＃〜]がAPIサーバーにアクセスしています。
WHOとWHATの違いはAPIサーバーにアクセスする
[〜＃〜] who [〜＃〜]と[〜＃の違いをよりよく理解するために〜] what [〜＃〜]がAPIサーバーにアクセスしているので、次の図を使用してみましょう。
Intended Communication Channelは、悪意のある意図のない正当なユーザーが、改ざんされていないバージョンのモバイルアプリを使用して、途中で攻撃されることなくAPIサーバーと直接通信することで、予想どおりにモバイルアプリを使用していることを表します。
実際のチャネルは、悪意のある意図を持った合法的なユーザーが再パッケージ化されたバージョンのモバイルアプリを使用している可能性がある、正規のバージョンのモバイルアプリを使用しているハッカーが途中で攻撃しているなど、いくつかの異なるシナリオを表している可能性があります。 APIに対する攻撃を自動化できるようにするために、モバイルアプリとAPIサーバー間の通信が行われています。他にも多くのシナリオが考えられますが、ここではそれぞれを列挙しません。
[〜＃〜] who [〜＃〜]と[〜＃〜]何[〜＃〜]は同じではありませんが、そうでない場合はすぐに明らかになります。
[〜＃〜] who [〜＃〜]は、次のようないくつかの方法で認証、承認、および識別できるモバイルアプリのユーザーです。 OpenID ConnectまたはOAUTH2フローを使用します。
通常、OAuthは、リソース所有者に代わってサーバーリソースへの「安全な委任アクセス」をクライアントに提供します。リソース所有者が共有せずにサーバーリソースへのサードパーティアクセスを承認するプロセスを指定しますハイパーテキスト転送プロトコル（HTTP）で動作するように特別に設計されたOAuthは、基本的に、リソース所有者の承認を得て、認証サーバーによってサードパーティのクライアントにアクセストークンを発行できるようにします。次に、サードパーティはアクセストークンを使用して、リソースサーバーがホストする保護されたリソースにアクセスします。
OpenID Connect 1.0は、OAuth 2.0プロトコルの上にあるシンプルなIDレイヤーです。これにより、クライアントは、承認サーバーによって実行された認証に基づいてエンドユーザーのIDを確認できます。エンドユーザーに関する基本的なプロファイル情報を相互運用可能なRESTのような方法で取得する。
ユーザー認証はAPIサーバーに[〜＃〜] [〜＃〜]がAPIを使用していることを通知する可能性がありますが、リクエストが[〜＃〜] what [〜＃〜]から発生した、モバイルアプリの元のバージョン。
次に、[〜＃〜] [〜＃〜]がAPIサーバーを呼び出していることを特定する方法が必要です。開発者は考えるかもしれません。 [〜＃〜] what [〜＃〜]は、APIサーバーにリクエストを送信するものです。それは本当にモバイルアプリの本物のインスタンスですか、それともボット、自動化スクリプト、またはPostmanなどのツールを使用して手動でAPIサーバーを操作する攻撃者ですか？
驚いたことに、モバイルアプリの再パッケージ化されたバージョンを使用している合法的なユーザー、またはアプリケーションが提供するサービスを悪用して利用しようとしている自動化されたスクリプトであることに気付くかもしれません。
[〜＃〜] what [〜＃〜]を特定するために、開発者は通常、ハードコードするAPIキーに頼る傾向がありますモバイルアプリのコード。一部の開発者は余計な作業を行わず、モバイルアプリで実行時にキーを計算するため、静的なシークレットがコードに埋め込まれている場合の以前のアプローチとは対照的に、ランタイムシークレットになります。
上記の記事は、私が書いたというタイトルの記事から抜粋したものです。モバイルアプリにAPIキーが必要なのはなぜですか。これは完全に読むことができます here 、これはAPIキーに関する一連の記事の最初の記事です。
リバースエンジニアリング
確かに誰かがアプリケーションをリバースエンジニアリングできる場合、存在するすべてのAPIキーを抽出できます。
Webアプリケーションに格納されているシークレットは簡単に抽出できます。ブラウザでF12キーを押すか、view page sourceで検索します。
モバイルアプリの場合、これはかなり難しいと思われるかもしれませんが、実際には簡単でもあり、この記事で示したように、モバイルAPKをリバースエンジニアリングする方法をとることができます静的バイナリ分析でモバイルアプリからAPIキーを抽出する方法：
モバイルアプリのAPKをリバースエンジニアリングするためにMobSFを使用すると、APIキーをすばやく抽出でき、さらに分析を実行するために使用できる大量の情報が得られるため、モバイルアプリとAPIサーバーへの攻撃ベクトルが増える可能性があります。この情報の中で、またはsmaliおよびJava形式でダウンロードできる逆コンパイルされたソースコードで、サードパーティサービスにアクセスするための秘密を見つけることも珍しくありません。
しかし、APIキーを抽出するための私の好ましい方法は、MitM攻撃です。ここでは、 mitmproxy オープンソースツールを介してモバイルアプリとAPIサーバー間のトラフィックをプロキシし、私が書いたこの記事のモバイルアプリでそれを行う方法を学ぶことができますそのAPIキーを中間者攻撃で盗みます：
JNI/NDKなどの高度な手法を使用してモバイルアプリのコードでAPIキーを非表示にすることはできますが、APIキーを盗むために誰かがMitM攻撃を実行するのを妨げることはありません。実際、MitM攻撃は、開発者以外でも達成できるほど簡単です。
あなたの質問
質問1
セキュリティリスクをもたらすAPIキーには何が含まれていますか？
多くの場合、それが何を含んでいるのかではなく、何を表しているのかではありません。今では、これを使用して[〜＃〜]何[〜＃〜] がAPIサーバーに接続しています。
APIキーが JWTトークン の場合、それ自体に機密情報が含まれる場合と含まれない場合があります。
JSON Web Token（JWT）はオープンな標準（RFC 7519）であり、JSONオブジェクトとしてパーティ間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義しています。この情報はデジタル署名されているため、検証および信頼できます。 JWTは、シークレット（HMACアルゴリズムを使用）を使用して署名することも、RSAまたはECDSAを使用して公開鍵/秘密鍵のペアを署名することもできます。
したがって、APIキーに機密データが含まれていなくても、リソースへのアクセスを保護するために使用された瞬間からセキュリティリスクになります。これは、クライアントアプリケーションからキーを抽出し、それらを再利用して自動攻撃を実行するのが簡単であるため攻撃者は、APIサーバーを正規のアプリケーション（WHAT）、および正規のユーザー（WHO）として偽装することができます。
質問2
パブリックAPIを利用するアプリケーションをどのように作成し、セキュリティリスクをもたらすことなくそのアプリケーションを配布するのですか？
本当の真実...それをリリースすると、公開された機密の日付はパブリックドメインの一部になるため、Webアプリでそれを行うことはできません。ブラウザー開発者ツール。
これで、モバイルアプリでは、モバイルアプリの構成証明によって認識されている、可能な解決策がある可能性があります。
モバイルアプリの認証の説明
モバイルアプリ認証ソリューションの役割は、モバイルアプリが改ざんされていないこと、ルート化されたデバイスで実行されていないこと、xPosedやFridaなどのフレームワークによって計測されていないこと、MitM攻撃されていないことを実行時に保証することです。 SDKをバックグラウンドで実行することで実現します。クラウドで実行されているサービスはアプリに挑戦し、その応答に基づいて、モバイルアプリとデバイスが実行されていることの完全性を証明します。したがって、SDKが決定に責任を負うことはありません。
独自のスクリプトをブラックボックスプロセスに挿入します。関数をフックし、暗号化APIをスパイし、プライベートアプリケーションコードをトレースします。ソースコードは必要ありません。編集して保存をクリックすると、すぐに結果が表示されます。コンパイル手順やプログラムの再起動なしですべて。
Xposedは、APKに触れることなくシステムとアプリの動作を変更できるモジュールのフレームワークです。これは素晴らしいことです。つまり、元のコードがあまり変更されていない限り、モジュールは変更なしでさまざまなバージョンやROMでも機能します。元に戻すのも簡単です。
侵入テスターやソフトウェア開発者向けのインタラクティブなTLS対応インターセプトHTTPプロキシ。
モバイルアプリの整合性の認証に成功すると、短期間のJWTトークンが発行され、APIサーバーとクラウド内のモバイルアプリ認証サービスのみが認識している秘密で署名されます。モバイルアプリの認証に失敗した場合、JWTトークンは、APIサーバーが知らない秘密で署名されます。
これで、アプリはリクエストのヘッダーにあるすべてのAPI呼び出しでJWTトークンを送信する必要があります。これにより、APIサーバーは、JWTトークンの署名と有効期限を検証できる場合にのみリクエストを処理し、検証に失敗した場合にリクエストを拒否できます。
モバイルアプリ認証サービスで使用されるシークレットがモバイルアプリで認識されない場合、アプリが改ざんされているか、ルート化されたデバイスで実行されているか、または接続されている接続を介して通信している場合でも、実行時にそれをリバースエンジニアリングすることはできません。中間者攻撃のターゲット。
Mobile App Attestationサービスは、ApproovでSAASソリューションとしてすでに存在しています（私はここで働いています）。これは、iOS、Android、React Nativeなど）のSDKを提供します。統合には、クラウドサービスによって発行されたJWTトークンを検証するためのAPIサーバーコードの小さなチェックこのチェックは、APIサーバーが提供する要求と拒否する要求を決定できるようにするために必要です。
結論
私はコンピュータサイエンスの新卒なので、この説明をいただければ幸いです。
私はあなたの質問に簡単に答えることができたことを願っています。これで[〜＃〜]何[〜＃〜]と[〜＃〜] who [〜＃〜]はAPIサーバーにアクセスしています。バックエンドまたはクライアント側のコードに関係なく、はるかに安全なコードを記述できます。
そのため、Webアプリの場合、APIキーを安全に保つ形式でそれらを配布することはできません。そのため、APIサーバーにセキュリティの取り組みを集中させる必要があります。
モバイルアプリの場合、モバイルアプリとAPIサーバーの両方を保護し、誤検知に対処する必要がないモバイルアプリ認証ソリューションの形で存在することを期待しています。
結局、アプリケーションとAPIサーバーを保護するために使用するソリューションは、保護しようとしているものの価値とそのタイプのデータの法的要件（ヨーロッパのGDPR規制など）に従って選択する必要があります。
エクストラマイルに移動しますか？
OWASP Mobile Security Project-Top 10 risks
OWASP Mobile Security Projectは、開発者とセキュリティチームが安全なモバイルアプリケーションを構築および維持するために必要なリソースを提供することを目的とした一元化されたリソースです。このプロジェクトを通じて、私たちの目標は、モバイルセキュリティリスクを分類し、その影響や悪用の可能性を低減するための開発管理を提供することです。