16

そのため、SQL 認証を使用して web.config で接続文字列を使用しています。

もちろん、パスワードをプレーンテキストで保存しているため、これは脆弱性である可能性があると人々は言います。

ただし、私の知る限り、IIS は web.config を提供することはなく、web.config は管理者と IIS への読み取りアクセスのみを持つ必要があります。したがって、ハッカーが Web サーバーへのアクセス権を取得した場合、秘密鍵は Web サーバー上にあるため、使用する暗号化は問題になりません。

接続文字列の暗号化は、難読化によるセキュリティとして分類されませんか?

web.config 接続文字列を暗号化し、秘密鍵を Web サーバーに保存する価値はありますか?

さらに、もちろん、SSL を使用しない場合は、接続文字列を HTTP 経由でプレーンテキストで送信しています。SSL を使用すると、この問題も軽減されるはずです。

4

5 に答える 5

23

平文のパスワードを Web.config に保存すること自体がセキュリティ上の脆弱性であるとは言いません。しかし、パスワードを暗号化することは有用な多層防御手段であり、隠蔽によるセキュリティだけではありません。

  1. Web.config を提供するように IIS が正しく構成されていない場合はどうなりますか?
  2. 誰でも Web.config をダウンロードできるセキュリティの脆弱性 (パディング oracleの脆弱性など) が ASP.NET で発見された場合はどうなりますか?
  3. Web サーバーへのアクセスには、完全な管理者権限からサーバー側のコード インジェクションまで、さまざまなレベルがあります。攻撃者が後者しか実行できない場合、特にアプリケーションが部分信頼で実行されている場合、攻撃者は Web.config を読み取れる可能性がありますが、マシン キーにアクセスできない可能性があります。

最終的には、プレーンテキストのパスワードを Web.config に保存するリスクを許容できるかどうかを判断するのはユーザー次第です。もちろん、Windows 認証がオプションである場合は、SQL 認証の代わりにそれを使用することを検討することをお勧めします。

更新:セキュリティについて話すときは、資産と脅威を特定することをお勧めします。この場合、資産はデータベース内の機密データであり (データが重要でない場合、わざわざパスワードで保護する必要はありません)、攻撃者が Web.config にアクセスしてデータベースにアクセスする可能性があるという脅威があります。同じように。考えられる軽減策は、Web.config でデータベース パスワードを暗号化することです。

それはどのくらいのリスクですか？このような天文学的にまれな出来事に対して、私たちは本当に計画を立てる必要があるのでしょうか?

この軽減策は、ASP.NET パディング oracle の脆弱性が発見されたときに、すでにその価値を証明しています。プレーンテキストのパスワードを Web.config に保存した人は誰でも危険にさらされました。パスワードを暗号化した人は誰でもそうではありませんでした。ASP.NET の別の同様の脆弱性が今後数年間発見されないという確信はありますか?

ソースコードも暗号化し、実行時に復号化する必要がありますか? 私には過剰に思えます。

では、攻撃者がソース コードにアクセスできたらどうなるでしょうか? 保護している資産は何ですか?また、懸念している脅威は何ですか? 多くの場合、ソース コードはデータよりもはるかに価値が低いと思います。(ここでは、誰でも入手できる市販のオープン ソース ソフトウェアについて考えています。) また、ソース コードに価値がある場合は、難読化を検討する必要があるかもしれません。

彼らがすでにあなたのボックスへのアクセスを制限しているとしたら、ホストに障害が発生しているか、脆弱なサービスがすでにインストールされていると思います.

ASP.NET またはコードのセキュリティの脆弱性はどうですか? 彼らは時々ポップアップします。

私の懸念は標準的な慣行です。それは標準ですか？

Microsoftは、接続文字列を暗号化することを推奨しています。

あなたがすべきことは、プレーンテキストのパスワードを保存することによるリスクを評価することです:

  • 攻撃者が Web.config を公開するセキュリティの脆弱性を発見して悪用できる可能性はどのくらいありますか? 過去の歴史に基づいて、その可能性は低いと思います (ただし、「天文学的に」低いわけではありません)。
  • データの価値や機密性は? 保存しているのが猫の写真だけである場合、攻撃者がデータベースのパスワードを取得するかどうかはあまり重要ではありません。ただし、個人を特定できる情報を保存している場合は、法的な観点から、接続文字列の暗号化など、アプリケーションを保護するためにあらゆる手段を講じる必要があります。
于 2012-05-06T22:58:24.687 に答える
3

運用パスワードが web.config ファイルに存在する場合、そのファイルにアクセスできるすべての開発者が運用データベースにアクセスできることを考慮してください。これは、接続文字列のユーザー名がデータベースへの読み取り/書き込みアクセス権を持っている場合に特に問題になります。その後、開発者は「修正」が行われたという記録がなくても「修正」できるようになります。

于 2012-05-02T16:01:32.870 に答える
1

IHackStuff オンライン ブログでいくつかの記事を読んでいました。この男は、Google 検索エンジンを使用して、検索ボックスに次のように入力することで、本当に興味深い情報にたどり着く方法をいくつか説明しました。

filetype:config web.config -CVS

これにより、運用サーバー上のキャッシュされた web.config ファイルに関連する複数の結果が得られ、これらのファイルのすべての情報が公開されました。この可能性を考慮して、web.config データベース アクセス情報が十分に価値がある場合はいつでも暗号化することをお勧めします。

于 2012-05-02T16:11:37.260 に答える
0

あなたはそれweb.configがASP.NETによってブラウザに提供されないと言うのは正しいです。ただし、開発者は慎重であるため、新しいバージョンをリリースするときに、既知の適切なweb.configをweb.config.oldやweb.config.bakなどにコピーすることがあります。また、開発者は怠惰であるため、リリース後、古いweb.configを削除するのを忘れるか、リリースをロールバックする必要がある場合に備えて、数日間そのままにしておきます。

これで、.oldファイルと.bakファイルがブラウザに提供されるようになります。つまり、これらのファイルをスキャンして攻撃者にダウンロードし、攻撃者が自由に接続を探すことができるスクリプトやツールを簡単に作成できます。ユーザー名とパスワードを含む文字列、およびデータベースからの突然のクレジットカード番号がインターネットを循環しています...

コマンドラインとRSAキーを使いたくない場合（そして率直に言って、なぜそうするのですか？）、web.configを暗号化するためのこのツールを見てください。

于 2012-05-02T16:26:47.207 に答える