クライアントアプリケーションのリバースエンジニアリングの防止
Flashクライアントが使用するWebサービスがあります。サービスとFlashクライアントはどちらも私が作成しています（read：my company）。 FlashクライアントはHTTPSを介してサーバーと通信します。
最近確認された問題の1つは、人々がFlashクライアントを逆コンパイルしてから、サーバーと対話するための独自のクライアントを作成することです。サーバーには多くの「コントロール」があるため、これは大きな問題ではありませんが、迷惑です。
Flashの難読化については知っていますが、私の質問はもう少し一般的です。クライアントソフトウェアを配布してWebサービスと連携させる場合、人々がクライアントソフトウェアを改ざんするリスクを制限するためにどのような対策を講じますか？
難読化は最初の明白なステップのように見えるかもしれませんが、難読化はコード内の何かを保護する必要があり、SSL暗号化されていてもトラフィックをインターセプトすることによってリバースエンジニアリングされるため、何かはWebサービス機能ではありません。証明書のピン留めは、事前定義された証明書を信頼することにより、単純なSSL傍受を防ぐことができます。
通信データを対称的に暗号化し、キーをクライアントに保存してから難読化を使用して、そのキーと暗号化アルゴリズムへのアクセスを困難にすることができます。また、逆コンパイルを困難にすることで難読化を保護することもできます。フラッシュ難読化ツールおよび逆デコンパイラーの例は SWFencrypt および BISguard です。
上記は静的なソースコード保護ですが、ライブ/ダイナミックな攻撃から保護しません。これらの攻撃から保護する1つの方法は、クライアントがメモリとリソースの整合性チェックを使用することです。また、ライブデバッグを困難にする可能性があるアンチリバースエンジニアリング手法もいくつかあります。
ライブ攻撃を防ぐもう1つの方法は、クライアントソフトウェアの改ざんに使用される可能性のあるシステムの改ざんを探すソフトウェアを使用することです。これは、パンクバスター、ウォークラフトのワーデン、バルブのVACのようなルートキットのようなアンチチートエンジンの領域です。
別の種類の保護は、iOSやAndroidなどのクローズドプラットフォームでのコード署名とメモリ署名（メモリページまで）です。このようにして、静的な変更をクライアントのバイナリに、動的な変更をクライアントのメモリとOSに制限できます。
古いCAPTCHAも自動化に対する保護として使用できますが、ユーザーの使いやすさが損なわれます。また、ユーザーの動作と使用パターンを通じてサーバー上の自動化を検出し、CAPTCHAと組み合わせて誤検知を減らすこともできます。
技術的な保護は別として、法的手段やインセンティブでさえ使用できます。最高のクライアントを提供して、ユーザーが自分をハッキングしたり、自分で書いたりしないようにします。または、カスタムまたはハッキングされたクライアントがハッカーにはるかに大きな利点を与えないようにします。法的手段は私の強みではなく、国によって異なりますが、リバースエンジニアリングに関する訴訟について聞いたことがあります。法的脅威は、企業や個人がカスタムクライアントを販売または提供することを阻止する可能性があります。
最後に、問題全体を解決し、柔軟なAPIを介してWebサービスに簡単にアクセスできるようにし、サーバーでの悪用を防ぐことができます。また、ハッカーが切望している優れた機能に対して少額の料金を請求する場合もあります。 :)
基本的に、クライアントを保護することはできません。攻撃者がクライアントを変更することをより困難にするために、せいぜいあいまいにして難読化することができます。
サーバーは適切に保護されているため、セキュリティ上の問題ではなく、単に煩わしいものだとあなたは言っています。いくつかの変更されたクライアントに、サーバーによって拒否された不正な要求を行わせるよりも、クライアントを不明瞭にしようとするほうが煩わしいかもしれません。
それは本当にあなたの脅威モデルに依存します。私が取り組んだほとんどのクライアントでは、サーバーは完全に保護されており、クライアントを変更しても何も得られないため、不明瞭さや難読化に悩むことはありませんでした。
ここで、クライアント自体を保護しようとする場合（つまり、IPの問題のため、誰かがクライアントを盗むことを望まない場合）、これを達成するのを困難にするために時間を費やす方が理にかなっている可能性があります（ただし、心に留めておきます）クライアントを完全に保護することはできません。せいぜい、やる気のない攻撃者をやめさせ、やる気のある攻撃者を遅らせることができます）。
なし。アプリを逆コンパイルしない場合は、独自のSSL証明書を使用してプロキシ経由でアプリを配置します。クライアントはバックエンドにセキュリティを提供できません。
クライアントソフトウェアを改ざんされるリスクを制限するためにどのような対策を講じますか？
ここには、あなただけが測定できるバランスがあります。保護が有効なユーザーの邪魔にならないと仮定すると、保護を破る攻撃者にとっての価値からソフトウェアを保護するという価値のバランスをとるだけで済みます。
それほど高価ではないソフトウェアやサービスについて話していて、クライアントが単純な手段を超えるタイプではない場合は、難読化で十分かもしれません。
非常に高価なサービスやソフトウェアについて話している場合、または誤用した場合に価値がある場合で、クライアントが独自のソフトウェアでサービスを使用することを決心している場合は、さらに厳密な手段を使用する必要があります。
最初のケースでは、ツールはすでに存在しています。
2番目のケースでは、ブラウザーで実行されない署名付きアプリケーションを許可するAdobe Airを使用するのが最良のオプションです。公開鍵暗号を使用して、1）アプリケーションと通信しており、2）アプリケーションが変更されていないことを確認できます。非常に勤勉な攻撃者を阻止しなければならない場合（そして正直なところ、絶対に侵入できないものはない場合）は複雑ですが、注意深い設計と頻繁な強制更新を使用すると、攻撃するのに多くの労力を費やすだけで攻撃の大部分を排除できます。