license: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations
コルドバのアプリケーションを開発するときに考慮する必要がありますいくつかのセキュリティのベスト プラクティスについて説明します。 セキュリティは非常に複雑なトピック、従ってこのガイドは完全ではないことを留意してください。 このガイドに貢献することができる場合は、お気軽「ドキュメント」の下でコルドバのバグ追跡システム問題を報告します。 このガイドは、一般的なコルドバ開発 (全プラットフォーム) に該当するように設計されますが、特別なプラットフォーム固有の注意事項が記載されます。
読み取りし、ホワイト リスト ガイドを理解します。
Android の API 10 と以下は、ホワイト リスト登録のドメインは動作しませんし、iframe の WP8 XMLHttpRequest。 つまり、攻撃者が iframe 内の任意のドメインに読み込むことができ、iframe 内のページのスクリプトも一切コルドバの JavaScript オブジェクトと対応するネイティブ Java オブジェクトに直接アクセスできます。 これらのプラットフォーム用のアプリケーションを構築する際、これを考慮に入れなければなりません。 実際にはつまり、ターゲット 10 より高い Android の API と、可能であればを使用しない iframe を読み込む外部コンテンツ - inAppBrowser プラグインや他のサードパーティ製プラグインを使用してください。
ホワイト リストに登録ドメインから 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 エラー チェーン検証エラー自己署名入りの証明書に。 この構成では自己署名入りの証明書を使用できますが、アプリケーションが運用環境で使用する構成ではありません。 アプリケーションの開発時にのみ使用するものです。
(未定)