web-dev-qa-db-ja.com

Web GmailよりもGmailアプリを使用する方が安全ですか？

GmailアプリではなくWeb Gmailを使用する方が安全です。たとえば、次のオプションを参照してください。

  • Android Google ChromeまたはAndroid App
  • Windows Google ChromeまたはWindows Universal App
  • MacOS SafariまたはMacOS App Storeアプリケーション
  • iOS SafariまたはiOS App Storeアプリケーション
  • Linux Google ChromeまたはLinuxデスクトップアプリ？

各アプリが独自のディレクトリにデータを保存し、標準のサンドボックスを使用することを想定している他のアプリケーションにも当てはまりますか？

たとえば、Linux向けGoogleマップは、独自のフォルダを使用している Epiphany を使用して構築されており、サンドボックスは問題なく追加できます。

これは、専用のアプリを実行しているかどうかを調査するためのものです。 Windows、Linux、MacOSプラットフォームは、Banking ApplicationなどのWebブラウザーよりも高いセキュリティを提供します。

web-applicationweb-browserappsecsandbox
3
Aria

セキュリティの意味によって異なります...専用のメールアプリケーションを使用するとすぐに、ローカルクライアントにメッセージのコピーが保持されます。言い換えると、チェーンに要素を追加すると、チェーンのグローバルセキュリティが最も弱い要素の1つになります。

そうは言っても、セキュリティサーバー側はユーザー名+パスワードです。したがって、ローカルコピーを使用しても、物理的なセキュリティの問題を除いて、弱点は実際にはありません。正しく保護された建物にデスクトップがある場合、物理的なメールの盗難の問題は、物理的な侵入の問題ほど重要ではありません。持ち運ぶ携帯電話やデスクトップを使用する場合、物理的な盗難のリスクははるかに高く、フルディスク暗号化の使用を検討する必要があります。

より一般的な質問の場合、応答は異なる場合があります。ただし、いずれにしても、多層アプリケーションには、少なくともプレゼンテーションレイヤー（Webまたはアプリ）、ビジネスレイヤー、永続レイヤーが必要です。ビジネス層と永続層はサーバー側である必要があり、承認規則のカーネルはサーバー側でサービス層に実装する必要があります。認証は同じでなければならず、クライアントとサーバー間のプロトコルはサーバー証明書とクライアント認証で同じレベルの保護（TLSまたはSSL）を使用する必要があります。そのため、メールの場合、主な問題はローカルデータのセキュリティです。

忘れないでください。セキュリティチェーンの最も弱い要素は、多くの場合ユーザー自身です。画面の下部にある投稿に書かれている場合、最も強力なパスワードはアカウントを保護できません。ほとんどのブラウザーのパスワードコンテナーは、それ自体がパスワードで保護されていない場合、大きなリスクになる可能性があり、同じルールがリッチクライアントアプリケーションに適用されます。

5
Serge Ballesta

TL; DRアプリのルートとブラウザのみのどちらを使用するかを検討する必要があります。

どちらの場合も、サーバー側のアプリケーションのセキュリティを考慮する必要があります。

Webブラウザーやアプリは、SSL/TLSなどの交渉を行う必要があります。 app-routeを使用する場合は、アプリケーションのセキュリティも考慮する必要があります。証明書の固定などの問題を考慮に入れてください。

一般に、Webブラウザーのみがアクセスできるようにシステムを設計すると、セキュリティが100％バックエンドに配置されます。一方、アプリはセキュリティリスクの一部をアプリケーションに転送します。アプリケーションをリバースエンジニアリングして機密情報を公開することもできるため、アプリ開発に特別な注意を払う必要があり、安全なコーディングガイドラインが特に重要になります（これらは関係なく重要ですが、提供される場合はさらに重要になります）。ユーザーへ）。

2
HashHazard

具体的にはGmailですか、それともアプリケーションですか？

アプリケーションのWebルートを下っていくということは、そのアプリケーションをOWASPトップ10に対して保護する必要があるということです。

  • セッション固定
  • クロスサイトスクリプティング
  • クロスサイトリクエストフォージェリ
  • HTTPSとHTTPの同じ生成元ポリシーを共有するCookie
  • クリックジャッキング

私のポイントは、Webはデフォルトで安全ではないということですが、専用クライアントアプリケーションを強化して、一般的なWeb標準の採用に存在するいくつかの不安を取り除くことができます。つまり、クライアントは、サーバーに対してAPI要求を行うだけで、UIコードと純粋なデータを混在させないという点で、クライアントの処理をより簡単にすることができます。これは、安全な方法で記述する必要がないことを意味するのではなく、開発者が犠牲になる「落とし穴」が少ないと私は信じています。

1
SilverlightFox