クライアントの変更されていないバージョンがサーバーに接続していることを検証することは基本的に可能ですか？
私は Programmers.SEからのこの質問をクロス投稿 です。なぜなら、それはここでも同じようにトピックであり、このコミュニティにも質問を投げかけたいからです。
これはプログラミングの質問のように見えますが、実際にはセキュリティの基本的な質問でもあります。
クライアントの変更されていないバージョンがサーバーに接続していることを検証することは基本的に可能ですか？
私は自分のクライアント側のアプリにそれ自身のソースコードであるハッシュをハッシュさせ、それが変更されていないことの証明としてリクエストとともにサーバーへのキーとして送信するという考えを考えていましたが、それは誰でもクライアントにハッシュを送信させることができるのでばかげています変更されたバージョンを介して変更されていないバージョンの。
しかし、クライアントが変更されていないことを示す何らかの証拠を介して、これを行う安全な方法があるかどうか疑問に思っていました。
制御できないシステムでクライアントを検証することは基本的に不可能です。
それはそれが十分な程度に行うことができないという意味ではありません。たとえば、電子書籍リーダーは通常、クライアントが本物であることを確認しようとします。彼らは（そうであるように）彼らの脅威から守るのに十分安全な方法でそうします。核の秘密を守るのに十分ですか？いいえ。しかし、彼らの脅威環境には十分です。
そのコントロールがアプリケーションにとってどれほど重要であるかを理解し、誰かが引き裂き、アプリケーションを模倣するという問題に遭遇したときのダメージを制限するために配置する代替コントロールを決定します。黒/白、可能/不可能の観点から考えないでください。許容可能かつ達成可能なセキュリティの観点から考えます。
クライアントの変更されていないバージョンがサーバーに接続することを検証することは、基本的に不可能です。
...あなたがそれを確実にするために必要なことをしない限り。これは、クライアント側の改ざん防止ハードウェアを意味します。
コードがクライアントのコンピューターで実行されると、コンピューターの所有者はデバッガーを実行し、任意の時点で任意の値を使用してクライアントコードを変更できます。 「デバッガ」は、本格的な仮想マシンにすることができます。それを回避したい場合は、追加の検出システムを想像する手の込んだかくれんぼゲームに従事してみてください。攻撃者は、独自のツールのバリアントでこれらに対抗します。これは、チート対策ソフトウェアソリューションを設計しようとする人々の問題です（例 PunkBuster ）;これは、顧客がビデオをローカルに保存してからさまざまなファイル共有プラットフォームで公開することを防ぎながら、ビデオオンデマンドサービスを販売したいという人々の問題でもあります。
まとめると、これらの保護は、保護するデータが一部のゲームで余計な命のように取るに足らないものであっても、うまく機能しません。
これを回避するには、保護されたハードウェアでコードを実行する必要があります。これにより、想定される所有者からの詳細な検査から身を守ることができます。これは、ゲームコンソール、決済端末、スマートカードのモデルです。
[〜＃〜] tpm [〜＃〜] は妥協の試みです。通常のPCと同じものの内部で実行される改ざん防止モジュール。ここでの仮定は、通常のユーザーがハードウェアを変更して、たとえば、RAMのすべてをTPMモジュールの監視下にある部分を経由せずに読み書きすること）に変更するのが難しいと感じることです。 （CPUなど）。
クライアント側にそのようなハードウェアがないと、実行しようとしていることが機能しません。クライアントのコードを変更しない限り、誰も試みないほど価値がありません。それはすべて、ここで問題となっているものの価値に依存します。
あなたが試すことができます 暗号化難読化 存在する場合
暗号化の難読化とは、ある意味で、プログラムのソースコードを読み取り不可能にすることです。次に、暗号化キーをプログラムにハードコードすることができます。また、コンピューターは信頼できないため、サーバーにランダムシードをプログラムに提供させることもできます。このアプローチの唯一の問題は、暗号化の難読化がまだ実装されていないことと、特定の意味のみが可能であることです。
私も、このような問題に取り組んでいる会社で取り組みました。何週間かそれを解決した後、答えは実際には不可能です。
そしてここに理由があります：
基本的に「信頼されたクライアント」の問題が発生しています。クライアントコードはユーザーのPCで実行され、ユーザーは元のPCを完全に制御できます。ユーザーは、ディスク上、または場合によってはメモリ内のプログラムのバイトを変更できます。コードに対してハッシュまたはチェックサムを実行しようとした場合、その検証を行ったコードを変更して、「変更されていない」コードを返すようにすることができます。その煙と戦術を反映しています。
悪意のあるユーザーの状況を少し難しくすることもできますが、望んでいることを実現する実際的な方法はありません。それが大きな頭痛になることなしではありません。
HTTPSとクライアント証明書認証を併用できます。次に、有効な証明書を持つクライアントのみがサイトを使用できるようにします。
その後、クライアント証明書は、あなたが言及したパスワードを置き換え、ユーザーはバックグラウンドで行われる魔法に気づきません。
userを一意に識別したい場合、APIキーが適切に機能します。 FacebookのAPI 、または Stack ExchangeのAPI （など）を使用するには、自分を特定のユーザーとして識別するためのAPIキーを取得する必要がありますAPIを使用し、リクエストごとにそのAPIキーを送信します。したがって、APIにヒットするすべてのリクエストは、元のユーザーまでさかのぼることができます。これにより、API所有者は、APIキーへのアクセスを許可するユーザーを制限することにより、APIにアクセスするユーザーを制御することもできます。
ただし、userを一意に識別するだけです。ユーザーが元のソフトウェアを使用していることは確認されません（たとえば、ゼロから作成されたクローンではなく）。ユーザーが元のソフトウェアを使用していることを確認することは、ユーザーが自分のコンピューターを制御できず、デバッガーでプログラムを実行したり、ソフトウェアの指示を自由に変更したりできないという前提に依存しているため、事実上不可能です。 。