2

C#4.0でビルドされるプログラムを計画しています。LINQ to SQLを使用することを考えていましたが、ここに問題があります。このアプリケーションは公開されているため、誰でも難読化を解除して、約5分で.netリフレクターで開くことができます。その後、テーブルをダンプしたり、データを挿入/削除/更新したりするための変更を簡単に行うことができます。これらのプログラムを使用した基本的なリバースエンジニアリングのスキルがあれば、私でもそれができるので、私はこれを知っています。

上記のようなものから安全で安全な(または少なくともより安全な).netでDBトランザクションを実行する方法はありますか?今、私はあなたが100%安全になることは決してないことを知っています、そしてあなたができることはたくさんあります。これはかなりオープンなトピックですが、私はあなたが何をしたか、またはこのタイプの安全を確保するために人々がしていることを知っているかについてのアドバイスを探していますもの。

私はそれが十分に安全であることを望んでいるので、世界中の人が見ることができるようにそれを開くよりも、誰かが実際にダメージを与えようとする必要があります。

ありがとう!

4

4 に答える 4

4

コードを判読不能にする方法やReflectorを使用して検査できないようにする方法を探している場合、絶対確実な方法はありません。コードの難読化を使用できますが、それも破られる可能性があります。それはそれを少し難しくします。(詳細はこちら。)

ただし、ユーザーがデータベースに悪意を持って影響を与えないようにする安全な.NETアプリケーションを構築する方法があります。ほとんどすべての.NETアプリは、何らかの方法でデータベースを使用します。

あなたの質問は少し広いです。データベースとアプリケーションを効果的に保護するには、危険性、SQL Serverの構成方法、防御的なコーディング方法を知る必要があります。あなたが尋ねているのは良いことですが、答えは迅速で単純なものではありません。本当の答えは「研究と学習を始める」です。

.NETではなくWinFormsアプリケーションについて話しているように聞こえますが、対処している特定の脆弱性-SQLインジェクション(または、この場合、誰かがアプリを逆コンパイルすることを心配しているため、SQLの改ざん)-は両方に共通。データベースを保護することに関する最大の違いは、.configファイルの暗号化方法にあります。WinFormsでは少し異なります。 これがその方法を示す記事です。

防御的にコーディングすることは1つの要因です。この記事のレッスンは、ASP.NETを対象としていますが、WinFormsの世界、さらには.NETの外部にも引き継がれます。

あなたの場合、あなたが焦点を合わせる必要がある特定の慣行は、最小特権の慣行です。私がリンクした記事から:

最小特権のデータベースアカウントを使用する

アプリケーションは、最小特権のアカウントを使用してデータベースに接続する必要があります。Windows認証を使用して接続する場合、Windowsアカウントは、オペレーティングシステムの観点から最小特権であり、Windowsリソースにアクセスするための特権と機能が制限されている必要があります。さらに、Windows認証またはSQL認証のどちらを使用する場合でも、対応するSQLServerログインはデータベースのアクセス許可によって制限される必要があります。

同じドメイン内の別のサーバー上のデータベースにアクセスする、Microsoft WindowsServer2003で実行されているASP.NETアプリケーションの例を考えてみます。既定では、ASP.NETアプリケーションは、ネットワークサービスアカウントで実行されるアプリケーションプールで実行されます。このアカウントは最小特権のアカウントです。

したがって、最小特権の原則でデータベースを設計する必要があります。これにより、誰かがアプリケーションを逆コンパイルした場合でも、悪意のあることを実行できなくなります。

特定のユーザー(または複数のユーザー)を作成し、ユーザーに必要なアクセスのみを許可します。テーブルXから読み取る必要がありますが、書き込む必要はありませんか?問題ない。テーブルに対するSELECT権限のみを付与します。変更、編集、挿入、または表示を許可しないでください。つまり、事前に計画を立て、必要な権限を 把握し、それに応じてデータベースを設計します。


または(これは推奨されるアプローチではありません)、権限のないユーザーから始めてアプリを開発し、作業を進めながら権限を付与します。これは、本番ではなくテスト/開発DBで実行する必要があります。適切なセキュリティ慣行に従っている場合は、文書化する必要がありますが、それはまったく別の問題です。このアプローチは機能しますが、それは最も統制のとれたものではありません。

それを行う方法はServerFault.comにとってより大きな問題ですが、SQL Serverを使用している場合、MSDNは多くのガイダンスを提供し、他のデータベースシステムも同様に十分に文書化されています。


その他のオプションには、データベースへの直接アクセスを提供しないことが含まれます。WebサービスまたはWCFを使用して、サーバー上のサービスを公開します。クライアントは公開された関数を呼び出すだけで、基盤となるデータベースの知識がないため、直接アクセスするリスクはありません。このオプションは、セキュリティを強化し、データベースで何かが変更されたときにクライアントコードを再コンパイルして再デプロイする必要がないため、私たちが採用するオプションです。SQLServerからメインフレームのDB@データベースに(またはその逆に)切り替えたいとしましょう。何百ものクライアントではなく、Webサービスのコードを変更するだけです。

ただし、このアプローチを使用する場合でも、サービスを安全に設計する必要があるため、学習を行う必要があります。

于 2012-05-17T15:24:12.033 に答える
0

結果の.exeがReflectorや同様のツールに表示されても、データベースへの接続が必要であるとは限りません。

SQLインジェクションの脆弱性がある場合、それは異なり、個別に修正する必要がありますが、データベースの相互作用を暗号化する方法を検討する必要があります。

この質問と関連する回答により、概要がわかり やすくなります。データベース接続を安全に構成する方法

于 2012-05-17T15:22:13.140 に答える
0

アプリからデータベースに直接接続する場合、ユーザーはapp.configから接続文字列を取得し、コードを反映せずに直接dbに接続できます。もちろん、接続文字列を暗号化することはできますが、リフレクションとデバッグを少し使用するだけで、とにかく誰かがそれを抽出できます。
とにかくあなたのデータベースは保護されていないと思います。

dbを保護するには、次のようにします。あきらめて(アプリに対してローカルにする)、アプリケーションDALではなくdbを保護し、サービスアプローチを選択します。

于 2012-05-17T15:33:47.160 に答える
0

質問は、あなたが要点を見逃していることを示しています。

ユーザーがデータベース、パブリックWebサービス、またはパブリックインターフェイスにアクセスできる場合は、そのアクセスを認証および承認するための何らかの方法が必要です。

攻撃者がクライアントの動作を知っているかどうかに関係なく、そのインターフェイスが攻撃される可能性があります。クライアントを保護すると、速度が低下するだけです。

于 2012-05-17T16:33:40.690 に答える