免許証: アパッシュ ソフトウェア基礎 (ASF) を 1 つまたは複数の共同作成者のライセンス契約の下でライセンスされています。 著作権所有権に関する追加情報のためのこの仕事と分散 NOTICE ファイルを参照してください。 ASF は、Version 2.0 (「ライセンス」）; Apache ライセンスの下であなたにこのファイルをライセンスします。ライセンスに従う場合、このファイルを使用可能性があります。 ライセンスのコピーを入手した可能性があります。
http://www.apache.org/licenses/LICENSE-2.0 ソフトウェア ライセンスの下で配布で配布されて適用される法律によって必要なまたは書面で合意した、しない限り、「そのまま」なし保証またはいかなる種類の保証、明示または黙示を問わず、基礎。 アクセス許可と制限を支配する特定の言語用のライセンスを参照してください。
コルドバのアプリケーションを開発するときに考慮する必要がありますいくつかのセキュリティのベスト プラクティスについて説明します。 セキュリティは非常に複雑なトピック、従ってこのガイドは完全ではないことを留意してください。 このガイドに貢献することができる場合は、お気軽「ドキュメント」の下でコルドバのバグ追跡システム問題を報告します。 このガイドは、一般的なコルドバ開発 (全プラットフォーム) に該当するように設計されますが、特別なプラットフォーム固有の注意事項が記載されます。
読み取りし、ホワイト リスト ガイドを理解します。
既定では、新しく作成されたアプリケーションのホワイト リストにより、を介してすべてのドメインへのアクセスを <access> タグ： <access origin="*"> 、ホワイト リストに対して評価するネットワーク要求が必要な場合、この変更をのみアクセスする必要のあるドメインを許可することが重要です。 あるアプリケーション レベルの構成ファイルを編集することによってこれを： {project}/config.xml (最近プロジェクトの場合) または {project}/www/config.xml (古いプロジェクト)
Android のホワイト リスト コルドバの 2.9.x は安全と見なされます、しかし、それは発見された foo.com がホワイト リストに含まれる場合、foo.com.evil.com ホワイト リストのテストに合格することができるでしょう。 これはコルドバで修正された 3.x。
Android の API 10 と以下は、ホワイト リスト登録のドメインは動作しませんし、iframe の WP8 XMLHttpRequest。 つまり、攻撃者が iframe 内の任意のドメインに読み込むことができ、iframe 内のページのスクリプトも一切コルドバの JavaScript オブジェクトと対応するネイティブ Java オブジェクトに直接アクセスできます。 これらのプラットフォーム用のアプリケーションを構築する際、これを考慮に入れなければなりません。 実際にはつまり、ターゲット 10 より高い Android の API と、可能であればを使用しない iframe を読み込む外部コンテンツ - inAppBrowser プラグインや他のサードパーティ製プラグインを使用してください。
コルドバ 3.6.0、現在 Android 上だ今ホワイト リストの Url、アプリケーションの外部に必要なアプリケーションは、これらの Url へのリンクを生成する場合。 アプリケーションを生成する場合 tel: 、 geo: 、 sms: 、 intent: または同じような Url をユーザーのブラウザーで開くことを期待し、あなたのホワイト リストを更新する必要があります外部コンテンツへのリンクを提供しますか。 詳細については、ホワイト リスト ガイドを参照してください。
ホワイト リストに登録ドメインから iframe のコンテンツを提供しています、そのドメイン ネイティブ コルドバ ブリッジにお越し。 これはつまり、サードパーティの広告ネットワークをホワイト リストしこれら広告 iframe を通じて、悪意のある広告が iframe を打破し、悪意のある操作を実行することができること可能です。 このため、一般に使用しないでください iframe iframe コンテンツをホストしているサーバーをコントロールしていないかぎり。 サード パーティのプラグインの広告ネットワークをサポートするために利用できるがあることに注意してください。 この文が true の iOS は、iframe の接続を含むすべてを横取りしないことに注意してください。
コルドバは固定する真の証明書をサポートしません。 これに対する主要な障壁は Android にネイティブ Api の欠如 SSL サーバーの証明書のチェックを実行する接続を遮断します。 （JSSE を使用して Java で Android 上の固定を行う証明書することは、Android 上 webview は C++ で書かれてサーバー接続はあなたのため、webview によって処理されますが、だから不可能だが Java と JSSE を使用する。)Apache コルドバは複数のプラットフォーム間で一貫性のある Api を提供するものです、のでその一貫性が切れます主要なプラットフォームの機能を持っていません。
証明書を固定、またはアプリケーションの有効期間中に他の様々 な回でサーバーの公開キー (指紋) 予期される値が、アプリケーションの起動時のチェックなどを近似する方法があります。 サード パーティのプラグインを行うことができますコルドバがあります。 ただし、これは自動的に検証するサーバーへの接続ごとに予期される値の固定 true 証明書と同じです。
サーバーに自己署名証明書を使用することをお勧めします。 SSL を希望する場合、サーバーが既知の CA (証明機関) によって正しく署名されている証明書であることそれ勧め。 真の証明書を固定することができないことこれが重要になります。
自己署名証明書を受け入れるサーバー証明書がデバイスによって有効と見なされることができます証明書チェーンの検証をバイパスするからです。 これは、中間者攻撃への通信を開きます。 ハッカーを傍受し、デバイスとサーバー間の通信を読むだけでなくだけでなく、コミュニケーションを変更する非常に簡単になります。 デバイスは、サーバーの証明書が信頼された CA によって署名されていることを確認しないのでこれが起こっているか決して知らない。 デバイスには、サーバーはそれを予期している証拠がありません。 中間者攻撃を行うための使いやすさのため自己署名入りの証明書の受け入れがだけ、信頼されていないネットワーク上の https ではなく http を実行するよりも同然。 はい、トラフィックは暗号化されますが、しかし、真ん中の男は、暗号化は受動オブザーバーを除いて役に立たないので、すべてをアクセスできるように、- で-仲介者からのキーで暗号化できます。 ユーザーに SSL をセキュリティで保護された、信頼し、これが意図的を作ることそれ安全でない、SSL 使用は誤解を招くになります。 これが、信頼されたネットワークで使用される場合 （すなわち、あなたが制御された企業の完全に内側）、[自己署名入りの証明書はまだお勧めしません。 信頼されたネットワークで 2 つの提言は、ネットワーク自体が信頼できる、ちょうど http を使用するか （自己署名されていない) 信頼される CA によって署名された証明書を取得します。 ネットワークが信頼されているかはありません。
ここで説明した原則は Apache コルドバに限定されない、すべてのクライアント サーバー間の通信に適用されます。
Android でコルドバを実行する場合を使用して android:debuggable="true" 、アプリケーション マニフェストによって許可されます証明書などの SSL エラー チェーン検証エラー自己署名入りの証明書に。 この構成では自己署名入りの証明書を使用できますが、アプリケーションが運用環境で使用する構成ではありません。 アプリケーションの開発時にのみ使用するものです。
（未定）