0

教えてください、Silverlightビジネスアプリケーションは安全ですか？

私の知る限り、ユーザーはアプリケーションをロードしたローカルコンピューターのキャッシュから.xapファイルを取得できます。または、既知のファイル名と場所（HTMLコードで記述されている場合）を直接取得できます。ブラウザーのアドレスバーに入力するだけで、ファイルは次のようになります。ダウンロードしました。（質問1：それは正常ですか？または、特定のホスティングの設定によって直接ダウンロードが拒否される可能性がありますか？）

最も興味深いことがあります-したがって、ユーザーは、Webページをダウンロードすると、ファイルシステムに.xapファイルを持ちます。質問2：ユーザーはこのxapファイルを開く（つまり逆コンパイルする）ことができるので、ユーザーの特定の役割の確認など、多くのデータを取得できますか？コードでは、特定の役割の許可されたユーザーの存在を定期的にチェックしています。これに応じて、異なるコンテンツによって提供される場合があります。 psもちろん、私は属性によるサーバー側のチェックの役割について知っていますが、これについては話しません。さらに、私はMEFモジュール方式を使用し、モジュール間の通信には、通信インターフェイスを備えたグローバルライブラリプロジェクトを使用しました。モジュール間を通過する情報が盗まれる可能性はありますか？

次。いくつかのアプリケーション設定を含むweb.configファイルには、ログインパスワード情報を含むデータベース接続文字列がさらに含まれています。質問3があります：web.config、そのようなデータを保存するのに十分安全ですか？

そして最後の質問-SSL接続。私は知っています、私はこれを使うためにお金を払う必要があります。とにかく、質問4：SSLはどのようにアプリケーションを保護し、データを（ビジネスアプリケーションに）含めることができますか？

4

1 に答える 1

2

質問1.xapファイルはエンドユーザーがアクセスできる必要があるため、認証されたユーザーがサーバーからファイルを取得するのを阻止することはできないと思います。また、利用できない場合でも、ユーザーはブラウザのキャッシュで見つけることができます。

質問2a。はい、ユーザーはxapを逆コンパイルできます。単なるzipファイルです。名前を変更してzipに変更し、コンテンツを抽出し、Reflectorで表示します。SilverlightSpyを試してみてください。また、興味深いものをいくつか見ることができます。アセンブリで難読化ツールを使用できます。これは便利な抑止力ですが、それでも十分なリソース/エネルギーを持っている人が逆コンパイルすることができます。

質問2b。SilverlightアプリはWinDbgを使用してデバッグできるため、「モジュール間で渡される情報」を確認できると思います。繰り返しになりますが、難読化は少なくともカジュアルな内省を阻止するのに役立ちます。

質問3.はい、web.configは、公開するのに邪魔にならない限り、安全である必要があります。

質問4.SSLは、上記のxapファイルのイントロスペクションの問題を防ぐことはできませんが、トラフィックを盗聴する人々を阻止します。唯一の問題は、中間者攻撃（プロキシが独自の証明書で代用する）の中間者攻撃をどのように軽減するかです。これを軽減する方法はいくつかありますが、頭のてっぺんからのベストプラクティスがわかりません。

あなたが尋ねた質問に基づいて、ここにあなたが軽減すべきリスクがあります。ユーザーがSLアプリに接続してログインし、サーバーから「役割」を取得するとします。彼らがあなたのxapを逆コンパイルし、すべてへのアクセスを開くために「管理者」の役割を担う必要があると判断した場合、SLアプリとサーバーの間にプロキシを配置し、SLアプリが応答するように応答を変更できます。彼らは「管理者」の役割を果たしていると考えています。これは、エンドユーザーがシステムをハッキングしようとしている中間者攻撃です。SSLを使用している場合でも、プロキシは独自の証明書を使用し、エンドユーザーはプロキシの証明書を信頼できる証明書ストアに追加できるため、これは可能です。

私は、クライアント側で上記のリスクを適切に解決することができたことがありません。難読化を使用し、リクエスト/応答にカスタムヘッダーを追加することで、ハッカーが困難になりました。これは、チェックサムを暗号化するための非表示の秘密鍵を使用したチェックサムでした。ただし、エンドユーザーがxapの難読化/逆コンパイルに成功した場合、理論的には秘密鍵を見つけて暗号化アルゴリズムを確認できるため、上記の「役割」を変更した後、新しいチェックサムで置き換えることができます。例。

要約すると、クライアント側を適切に保護することは不可能であると結論付けました。また、リスクが十分であると判断した場合は、サーバーで認証を複製することをお勧めします。

たとえば、ユーザーが「customers」を表示するには「admin」ロールである必要がある場合、ユーザーが「admin」ロールである場合は、クライアントに「customers」画面を表示します。ただし、サーバーでは、SLクライアントがサービスを呼び出して「顧客」データをフェッチするときに、現在認証されているユーザーが（画面を表示するのではなく）データを表示する権限を持っていることも確認します。

于 2013-03-04T07:07:15.090 に答える