モバイルデバイスで利用できる確立された安全なコーディングガイドラインはありますか？

Question

特にモバイルデバイス（AndroidおよびiOS）向けの安全なコーディングガイドラインを探しています。私が興味を持っている言語は、Objective-C、JavaおよびHTML5です。

ESAPI for JAVAのような「クラシック」セキュリティフレームワークを使用するのは良いアプローチでしょうか？

D.W. · Accepted Answer

問題は、一般的に安全なソフトウェア開発の場合とほとんど同じです。

安全なソフトウェア開発のための最も重要な問題は、（1）セキュリティをソフトウェア開発ライフサイクルに統合する（したがって、セキュリティはプロセスの各ステップに統合される：設計、実装、保守、運用）、および（2）開発者のトレーニングです。ソフトウェアライブラリまたはフレームワークがシステムのセキュリティを魔法のように保証すると考えるのは誤りです。

モバイル固有の問題。とはいえ、モバイル分野で特に注意が必要な問題をいくつか次に示します。

安全な通信チャネルを使用します。モバイルアプリから他のサーバーへのHTTPまたはその他の暗号化されていない通信に注意してください。携帯電話ユーザーはネットワーク接続にオープンWifiネットワークを使用することが多く、盗聴や中間者攻撃のリスクが高くなります。したがって、機密情報やセキュリティ上重要な情報（個人情報、セッションCookie、認証トークン）を送信する場合は、HTTPではなくHTTPSを使用する必要があります。カスタムネットワークプロトコルの場合は、TLSを使用します。

一般的に、疑わしい場合は、平文の通信の使用に懐疑的です。いくつかの注目度の高いアプリにはこの形式の脆弱性がありました（クリアテキストHTTP経由でセッショントークンを送信しました）;同じ間違いをしないでください。
セキュリティ上重要なデータを安全に保管します。セキュリティ上重要なアプリを使用している場合は、携帯電話に非常に機密性の高いデータを保管することに注意してください。たとえば、オンラインバンキングのパスワードやそのようなものを携帯電話に保存したくない場合や、クレジットカードなどに注意したい場合があります。携帯電話が盗まれた場合、その情報にアクセスできるためです。盗人。携帯電話の盗難、紛失、借用が非常に簡単であるため、盗難と物理的なセキュリティは特に重要です。
アプリケーションデータの保存場所に注意してください。アプリケーションデータを保存するときは、保存場所と使用するアクセス許可に注意してください。機密情報を他のアプリが誤って利用できるようにしたくない場合。たとえば、Androidでは、アプリはアプリ固有のデータを内部ストレージ、SDカード、またはコンテンツプロバイダーに保存できます。これらには、異なるセキュリティ上の影響があります。内部ストレージはデフォルトで安全であり（他のアプリはデータを表示できません）、標準的な選択肢として適しています。 SDカードはデフォルトで他のアプリに表示されるため、注意が必要です。 SDカードにデータを保存する場合は、データの共有を意図していない限り、他のアプリがデータを読み取れないように少なくともファイルのアクセス許可を設定してください。コンテンツプロバイダーは、Android権限を使用して保護できます。
ユーザーのプライバシーを尊重します。ユーザーを見つけた場合、ユーザーを忍び込ませるようなことはしないでください。アプリが何をするのかを前もって考えましょう。たとえば、ユーザーの同意なしに、ユーザーのアドレス帳のコピーを取得してサーバーにアップロードしないでください（友達との連絡を手助けするなど、善意を持っていても）。ユーザーの背後にあるサーバーに写真をアップロードしないでください。

デバイスID、電子メールアドレス、電話番号などの一意の識別子を扱うときの1つの手法は、携帯電話から離れる前にこれらの識別子をハッシュすることです。それらをサーバーにアップロードしないでください。代わりに、アプリ固有の値と一緒にハッシュしてから、ハッシュをアップロードしてください。場合によっては、これはユーザーのプライバシーの向上に役立ちます。
静的分析。モバイル固有のリスクについて知っている静的分析ツールの使用を検討してください。商用ツールについては、Fortifyはこれについて高い評価を得ています。無料ツールの場合、 Comdroid および Stowaway Androidアプリケーションに固有のいくつかのリスクを確認します。ただし、無料ツールはFortifyのような商用製品ほど包括的でも洗練されていません。

プラットフォームを理解します。特定のモバイルプラットフォームに固有のセキュリティリスクについて学習します。例えば：

Androidでは、Webviewに関連する脆弱性に注意してください。アプリケーションでWebviewを使用していて、Javascriptインターフェース（例： webview.addJavascriptInterface()、webview.setWebViewClient()）、次に微妙なセキュリティリスクがあります。
Androidでは、インテント関連の脆弱性に注意してください。Androidインテントは素晴らしいです;それらは柔軟なクロスアプリケーションを可能にしますただし、これらは新しいセキュリティリスクももたらします。特に、盗聴、なりすまし、中間者攻撃など、他の通信チャネルの潜在的なリスクの多くを共有しています。

これらの問題を回避するには、リスクを知っています。アプリ内部の通信にインテントを使用する場合は、明示的なインテントのみを使用し（暗黙的なインテントではなく）、すべてのインテントレシーバーが内部のみであり、世界にエクスポートされないことを確認してください（状況によってはAndroidは暗黙的にコンポーネントをエクスポートします。内部インテントを受信する可能性があるコンポーネントはそれを避けたいと思います。アプリケーション間通信にインテントを使用する場合、注意しないとインテントが挿入されたり盗聴されたりする可能性があることに注意してください。別のアプリケーションから送信された可能性のあるインテントを受信し、そのコンテンツを信頼できないものとして扱い、適切な入力検証/サニタイズを適用します。受信した各インテントの送信者も確認する必要がある場合があります。他のアプリが受信する可能性のある暗黙のインテントを送信する場合、悪意のあるアプリによって傍受される可能性があることに注意してください。インテントに機密情報や機密情報を含めないでください。内部通信と外部通信を混在させることは避けてください。イオン。

インテント関連の脆弱性の概要については、 here および here を参照してください。より技術的な詳細はテクニカルペーパーにあります。
Androidでは、権限の再委任攻撃を回避します。A 権限の再委任の脆弱性は、アプリに権限Pが付与されている脆弱性です、および権限Pを必要とする操作を実行することにより、他のアプリからのリクエストに喜んで応答します。他のアプリに権限Pがない場合は、Pに関連付けられた権限を他のアプリに漏らしたことになります。
Androidでは、SQLインジェクションの脆弱性に注意してください。Androidでは、SQLクエリを介してコンテンツプロバイダーにアクセスできます。従来のSQLインジェクションの脆弱性を回避する必要があります。さらに、独自のコンテンツプロバイダーを構築し、独自のメソッド（delete、execSQL、rawQuery、update、updateWithNoConflictなど）を実装してコンテンツプロバイダーに対するクエリを処理する場合は、SQLインジェクションの脆弱性を誤って導入しないように、これらのメソッドを実装するときに注意してください-経験上、開発者はこれらのメソッドを実装するときに問題を引き起こすことがよくあります。これらの問題を回避する最良の方法は、モバイル以外のプラットフォームと同じです。パラメーター化されたクエリ（準備されたステートメント）を使用します。

その他のリソース。Androidの場合、次のプレゼンテーションを強くお勧めします。

Google Androidで自分をつなぐ7つの方法（ slides ）

モバイルセキュリティ全般については、次の質問にも目を通すことをお勧めします。

rook · Answer

私は何も知りませんが、それが必要だとは思いません。モバイルプラットフォームは何も新しいです。結局のところ、同じ脆弱性の多くがこのプラットフォームに影響を与えています。多くのモバイルアプリは、コードのクライアント側がすべてHTML/JavaScriptで記述されている単なるWebアプリケーションです。

そうは言っても、モバイル開発者は他のプラットフォームの開発者よりも CWE-602 に違反しています。正直に言うと、脆弱性が非常に明白であるため、かなり不可解です。良い例は MySQLバックエンドに直接接続されたSuper Meat Boy です。このゲームのモバイルバージョンがありますが、それもプレーンな古いデスクトップアプリケーションであり、どちらも同じ攻撃に対して脆弱です！

K.M. Goertzel · Answer

1月に質問されて以来、次のようなかなりの数のものが公開されています。

Threadstrong から利用できるオンラインコースもあります。