1

ユーザーが ASMX Web サービス経由でトランザクション ログをメイン サーバーにアップロードしているシナリオがあります。アプリケーションはclickonce .Net winformsアプリです

現在、オブジェクトのリストをJsonに変換し、サービスで逆シリアル化するためにこれを行っています。SSL経由。

string data = JsonConvert.SerializeObject(Values_Static.logitems);

私のコードは SmartAssembly によって保護されています。それでも、攻撃者がネットワーク接続にアクセスでき、データを逆シリアル化できるという違反が発生しています。

今、Json 文字列を秘密文字列キーで暗号化し、サーバー上で復号化するシナリオを考えています。

例えば

private string salt = "$e7?8f@l4";
return ByteArrToString(Encrypt(TextValue + salt));

アプリでキーをハードコーディングし、サーバーでデコードします。

それは動作しますか？ユーザーは毎分ログをサーバーにアップロードしており、アップロードごとに 20 ～ 30 のエントリがある可能性があります。壊れたデータやハッキングの可能性はありますか?

更新: 以下の議論によると。コードに問題があることを理解しています。コードは無効な証明書を受け入れています。https://Webサービスから有効な証明書のみを受け入れることを防ぐ方法. ATM では、復号化 HTTPS をオンにして、誰もがフィドラーを介してコードを見ることができます。

IIS 7 に有効な証明書がインストールされています。問題はコードにあります。および Visual Studio での標準の自動生成された Web 参照。

更新 2: 最終結果は、Post データは暗号化されておらず、プレーンな XML であり、盗聴できる任意のソフトウェアで読み取り可能ですが、GET データは安全です。有効な回答が見つからないビットを検索しました。

4

2 に答える 2

1

SSLを使用していますか？その場合、アプリケーション レベルの暗号化は冗長です。また、キーはコードに埋め込む必要があるため、攻撃者が読み取ることができます。

于 2012-09-08T14:15:14.643 に答える
0

Fiddler (または他の HTTPS プロキシ) は、すべてのHTTPS トラフィックを復号化できます。

システム自体が信頼する証明書を信頼するのではなく、クライアント コードで特定のサーバー証明書を要求することにより、Fiddler の単純な使用を防ぐことができます。ただし、これは弱い抑止力にすぎません。ユーザーはコードを逆コンパイルして変更するだけで、新しい証明書チェックが無効になる可能性があるからです。

これは「信頼されていないクライアント」問題と呼ばれ、デジタル著作権管理 (DRM) ソフトウェアを鉄壁の保護ではなく「ベスト エフォート」の問題にするのと同じことです。

于 2012-11-29T23:25:07.727 に答える