-1

この質問は本質的に少し悪意があるように思われるかもしれませんが、 Android /モバイルアプリ開発のベストプラクティスを学ぼうとしているだけであり、セキュリティはソフトウェアの大きな問題です。それでも、この質問（！）を読んだ後、それが本質的に悪意があると思う場合は、これらの攻撃を実装する方法を尋ねているのではなく、優れたAndroid/モバイル開発者が必要とする攻撃を尋ねているだけです。を認識すること。

以下は、アプリケーションの「公式」OWASPトップ10セキュリティ脅威のリストです（リンクはこちら）。これらのどれがAndroid開発に適用されるのか、またはここにリストされていない他の主要な攻撃があるのか​​どうか疑問に思いました：

  • 注入
  • クロスサイトスクリプティング（XSS）
  • 壊れた認証とセッション管理
  • 安全でない直接オブジェクト参照
  • クロスサイトリクエストフォージェリ（CSRF）
  • セキュリティの設定ミス
  • 安全でない暗号化ストレージ
  • URLアクセスの制限の失敗
  • 不十分なトランスポート層保護
  • 未検証のリダイレクトと転送

注意：私は、モバイルデバイスで表示するために構築されたWebサイトについて話しているのではありません。私は、モバイルデバイスに展開される実際のアプリケーションについて話しています。Androidの場合、これはAPKsを意味します。

4

4 に答える 4

3

OWASPトップ10はWebアプリケーションを対象としており、Androidアプリは異なります。

ただし、OWASPには急成長しているモバイルイニシアチブがあり、現在モバイルトップ10に取り組んでいます。今年のトップ10候補のリストは次のとおりです。

  1. 安全でないデータストレージ
  2. 弱いサーバーサイドコントロール
  3. 不十分なトランスポート層保護
  4. クライアントサイドインジェクション
  5. 不十分な承認と認証
  6. 不適切なセッション処理
  7. 信頼できない入力によるセキュリティの決定
  8. サイドチャネルデータの漏洩
  9. 壊れた暗号化
  10. 機密情報の開示

これらを非常に詳細に説明する素晴らしいスライドのセットがあります。

OWASPモバイルトップ10に加えて、 2011年12月にO'Reillyによって公開されたばかりのAndroidプラットフォームのアプリケーションセキュリティを紹介します。これは、Androidでの現在の安全なモバイルアプリケーションの設計について説明し、それに継承される脅威について説明しています。プラットフォームと、それらを回避するために安全な方法でアプリをコーディングする方法（免責事項：私はこの本の著者です:)）。

于 2012-01-25T19:44:36.030 に答える
2

あなたが投稿したものからあなたはあなたのAndroidアプリケーションとあなたのJavaサーバーに興味があるのであなたの質問に具体的に答えるのは難しいです、しかしあなたは非常に一般的な質問をしています。OWASPが公開しているものの多くは非常に高レベルであるため、Androidアプリケーションとサーバーの動作の詳細を知らなければ、実際の実質的な回答を得るのは困難です。一般に、サーバーを追跡し、単一の受話器だけでなくすべての電話を通過するすべてのデータを所有できる場合、人々は電話を攻撃することはありません。

したがって、インジェクション、XSS、CSRFなどは主にサーバー側に適用されます。プログラムでAndroidSQLiteデータベースを使用している場合は、Android SQLiteデータベースへのインジェクションを実行できます（アプリの詳細がどのように機能するかをここで確認してください）。XSS、CSRFは、アプリがWebベースのクライアントである場合、またはその一部にWebviewを使用している場合に適用できます（ここでも詳細が重要です）。

Java用のサーバーへのインジェクションは、PreparedStatements/PreparedCallを使用して簡単に修正できます。ステートメントは使用しないでください。JPA、Hibernate、iBatisを使用している場合、これらのほとんどは内部でPreparedStatementsを使用します。Javaアプリへのインジェクションは、これらの攻撃を簡単に阻止できます。

https://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

XSSとCSRFはより困難ですが、フィルターを使用して防ぐことができます。このページを読むと、それを説明するプロジェクトへの別のリンクがある場所がわかります。

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

安全でない接続を介してパスワードを送信する。HTTPまたは非SSLソケットを介してパスワードを送信すると、多くの情報が開示されることになります（パスワードを知る必要がないため、一方向ハッシュを使用しても役に立ちません。必要なのはハッシュだけです。そしてそれは平文で送信されます）。したがって、ユーザーの認証にSSLを使用していることを確認してください。次に、これらのパスワードをデータベースに保存する方法について説明します。一方向ハッシュを使用していますか？bcryptを使用していますか？そうでない場合は、SALTを使用していますか？そのハッシュを壊すのにかかる時間を増やすためにハッシュを繰り返していますか？

ほとんどの侵入には、OS、データベース、SQLインジェクションなどの脆弱性を介して、基盤となるデータベースにアクセスすることが含まれます。ユーザーとパスワードを格納しているテーブルを取得します。次に、簡単な既製のグラフィックカードを使用して超高速のブルートフォース方式を実行し、ブルートフォースパスワードを実行します。パスワードを適切に保護するように注意しないと、今日、この方法を使用してほとんどの一方向ハッシュを破ることができます。

于 2012-01-25T18:55:13.003 に答える
1

(Android) アプリの場合、前述の攻撃のほとんどは定期的に適用されません。

あなたの場合、Alice、Bob、またはEveが誰であるかを知りたい場合は、誰かがあなたの質問に本当の答えを提供してくれるかもしれません。

  • 誰を保護する必要がありますか？
  • アプリのセキュリティを攻撃する (したい) のは誰ですか?

私が自発的に思いつく最も現実的な脅威 (情報が不足しているため、デバイス上のほとんどスタンドアロンのアプリを想定しています) は、アプリのバグであり、次のいずれかです。

  • （アプリの）個人情報を安全でないストレージに漏らす、または
  • ユーザー入力による悪意のあるデータの挿入を許可します (読み取り: SQL インジェクション。ただし、一般的な問題は SQL DB だけに関連するものではありません。たとえば、「XML インジェクション」について考えてみてください) 。

編集：

アプリのセキュリティで考えられる利害関係者をいくつか集めてみましょう (特定の順序はありません)。

  • アプリのユーザー: 彼、彼のデータ、彼の金銭的価値、または彼のプライバシーは、アプリによって保護/サポートされる必要がありますか?

  • アプリのユーザー: アプリや開発者の資産に脅威をもたらしますか?

  • アプリ開発者: 彼、彼の IP、またはその他のアプリケーション関連の資産は、アプリケーションの設計によって特に保護する必要がありますか?

  • アプリ開発者: 彼または彼の環境は、彼に属していない資産に脅威を与える可能性がありますか?

  • サード パーティ: IP またはその他の値を保護する必要があるサード パーティはありますか?

  • サード パーティ: 脅威にさらされている可能性のある上記の資産のセキュリティを侵害することに関心があるサード パーティはありますか?

（お好みで追加してください。）

于 2012-01-25T18:10:02.393 に答える
0

多くのモバイルデバイスでは、アプリでブラウザをポップアップし、ブラウザにフックを挿入して、キーストロークなどを監視できます。これにより、キーロギングが可能になります。攻撃は次のように発生します。

  1. アプリはブラウザインスタンスを作成します。
  2. アプリは特権ブラウザーAPIを使用して、ブラウザーによってロードされたページにキーイベントハンドラーを追加します。
  3. アプリにより、ブラウザは銀行のログインフォームなどのURLをロードします。
  4. 使用は、ブラウザの同一生成元ポリシーが入力されたデータを保護していることを前提としています。
  5. アプリは、パスワードを含む可能性のあるフォームコンテンツを監視し、盗み出します。

iPhoneアプリからSafariを起動するにはどうすればよいですか？

アプリケーションからAndroidのWebブラウザでURLを開くにはどうすればよいですか？

于 2012-01-25T18:46:47.177 に答える