0

プログラムを逆アセンブルして、データベースへの接続に使用している資格情報取得したり、実行時にプログラムをインターセプトして (SQL) クエリを操作したりできるかどうかという問題について考えるようになりました (SQLインジェクションについては話していません) 。 .

ばかげた考えかもしれませんが、顧客が受け取るプログラムが、特定のテーブルへのアクセス (および権限、つまり読み取り専用) のみを持つアカウントを使用する必要があるかどうかを知る必要があります。

4

5 に答える 5

2

これは決してばかげた考えではありません。プログラムをソースコードに逆アセンブルするためのツールはたくさんあります。.NET の世界では、たとえばReflectorILSpyがあり、ほとんどの言語には同等のものがあります。

ユーザー名またはパスワードがソース コードにプレーン テキストで表示されている場合、逆アセンブル ツールを使用して簡単に取得できます。暗号化されているように見えても、暗号化アルゴリズムとキーがソース コードの一部である場合は、簡単に入手できます。

これを解決するために、.NET の世界では、暗号化されたパスワードを構成ファイルに保存できます。

または、ハードコードされたユーザー名/パスワードではなく、ユーザーのドメイン アカウントが透過的にアクセスに使用されるドメイン認証を使用するようにデータベースを構成することもできます。

最後に、可能な限り最小限の権限の原則を常に使用する必要があります。必要な最小限のアクションのサブセットを実行するユーザー権限のみを許可してください。

于 2012-09-03T14:59:02.173 に答える
2

理論的には、作成するすべてのプログラムは逆アセンブルの対象となるため、クレデンシャルをプログラムに直接書き込むべきではありません。

作成しているプログラムの種類に応じて、クレデンシャルを記述する代わりの方法がいくつかあります。たとえば、Web アプリケーションでは、jndi ルックアップを使用して、アプリとは別に作成したサーバー接続を検索する必要があるため、何も保存しません。プログラムの接続情報。

デスクトップ アプリを作成している場合でも、jndi ルックアップを使用できますが、もう少し複雑になります。その場合、認証とサーバーからのデータベース接続を処理し、表示のみを行うサーバー アプリケーションを作成する必要があります。データをクライアント アプリケーションに送信します。

于 2012-09-03T15:01:27.243 に答える
1

セキュリティの観点から、分解は常に可能です。十分に洗練された攻撃者は、マシンコードを読み取って、それが通常のソースコードであるかのようにそれが何をするのかを理解することができます。確かに、それは簡単ではありませんが、「太陽が続くと予想されるよりも多くの時間を必要とすると数学者が考えている」という意味ではなく、「まともな道具とある程度の賢さが必要」という意味では難しいです。

于 2012-09-04T02:27:07.527 に答える
1

すべての顧客に同じアカウントを使用していて、それを広めるつもりなら、それはそのアカウントにパスワードをまったく設定しない (または公開する) ことと同じです。コード。それは、5 人以上に届く予約済みの情報を制御し続けることは事実上不可能だからです。たとえ信頼できるものであっても、彼らが使用するシステムはそうではありません。誰が DB にアクセスするかを本当に制御したい場合は (当然のことですが)、上記のようにサーバー側などの制限された場所で認証を行ってください。

man-in-the-middle 攻撃に関して、信頼性の低いネットワーク (たとえば、小規模な LAN ではない) を介して通信する場合は、これが発生する可能性があると想定する必要があります (SQL またはその他の種類の情報を傍受するため)。たとえば、暗号化された接続 (SSL または TLS など) を使用して、通信を保護します。もちろん、何が送信されるかを気にしないか、傍受されるリスクが低から中程度であることを受け入れる場合を除きます。

于 2012-09-03T15:56:40.640 に答える
0

サードパーティ製品を分解することは通常、ライセンス契約に違反するため、その理由だけではお勧めできません。

とはいえ、アプリケーションは通常、インストールまたは展開に固有であるため、ハードコードされたデータベース資格情報を使用することはめったにありません。多くのアプリケーションは、それらを web.config または app.config ファイルに保存します。レガシ アプリケーションは、それらをレジストリに格納する場合があります。

より良い解決策は、WireSharkのようなネットワーク スニファを実行し、ネットワークを通過するパケットを調べることです。SQL Server の場合、デフォルトでポート 1433 が使用されます。

于 2012-09-03T15:01:04.763 に答える