2

C++-> モバイル デバイス、および Perl-> デスクトップ PC (Windows /Linux/Mac OS など) を使用して作成されるクロス プラットフォーム アプリに取り組んでいます。

現在、アプリはダウンロード可能になるため、ハッカーがアプリのソース コードを入手できる可能性について懸念があります。

具体的には、アプリは中央データベースに接続します。少なくとも、ハッカーがデータベース接続の詳細を取得できないようにしたいと考えています。理想的には、コードのどの部分もハッキングされたくないでしょう。

基本的に、ユーザーはこのアプリを使用して自分の情報の一部を更新できます。ハッカーがこのデータを入手すると、不幸なユーザーのデータを簡単に変更できます。私が考えたことの 1 つは、ユーザーは最初に OAuth/OAuth2 で (メール ID @yahoo/@hotmail/@gmail を使用して) 認証する必要があるということです。その後、アプリは実際に管理インターフェイスを表示します。しかし、いずれにせよ、ある時点でアプリは中央データベースに接続します。これが、データベースのアクセスの詳細が危険にさらされることを望まない理由です。

多くの組織がそのようなアプリを作成しているため、この種の問題に直面しているのではないでしょうか? アプリ (理想的にはコード全体) を保護する方法と、少なくとも db 資格情報を知りたいです。

4

4 に答える 4

5

簡単な答えは、データベースを公開しないことです。これまで。

認証と承認を処理するサービス層 (HTTP ベースである可能性がありますが、そうである必要はありません) を一番上に追加します。その後、アプリはユーザーの資格情報を使用してログインし、ユーザーに代わって動作します。サービス層は、アプリケーションが対話する API を公開しますが、サービスはDB へのすべての呼び出しを行い、制御します。

OAuth については既に言及していますが、これは、そのような API に認証を追加するための完全に受け入れられる方法です。

于 2012-11-10T11:47:26.300 に答える
4

それはいけません。

明るい面では、サーバーにセキュリティを設定できます。接続しているクライアントは、特定のユーザーであるという資格情報を提供します。サーバーは、要求が許可されていることを証明した後、SQLコマンドを生成します。支援者はアプリでできることは何でもできますが、アプリはデータベースに対して不適切な動作をすることができなくなります。

于 2012-11-10T11:44:56.387 に答える
1

以前の答えは絶対に正しいです。認証/承認コードを提供し、データベースとやり取りするサーバー ベースのサービス レイヤーが必要です。ただし、常に完璧な世界であるとは限りません。これらのアプリケーションがデータベース クライアントとして機能する必要がある場合は、公開をできるだけ制限したいと考えています。通常、これは、一般データベースへのアクセスが許可されていない特定のアカウントをクライアントに使用させることによって行われます。次に、アプリケーションに必要な操作とクエリのみを実行できる特定のストアド プロシージャを作成します。これにより、コード内の資格情報を見つけた人がデータベース内で意図しない操作を行うことを防止できますが、コードを確認することで誰かが他人になりすます可能性があるという問題は依然としてあります。ありません』サーバー側のコンポーネントなしでそれを防ぐ方法。これは、クローズド/信頼できるユーザーのグループには問題ないかもしれませんが、この方法で一般に公開することはありません。

于 2012-11-11T00:28:14.083 に答える
0

それができる場合は、OAuth2 を使用して、信頼できるサード パーティのハンドル認証を許可します。Twitter、Facebook、および GitHub はすべて、セキュリティに関して比較的偏執的です。他のポスターは正しいです。ユーザーがアクセスできるアプリの一部として、データベースへの直接アクセスを決して公開しないでください。それを独自のサービスの背後に置きます。

幸運を！:)

于 2012-11-11T21:15:11.780 に答える