次の要件を検討してください
質問は:
適切なトークンを含むWebアプリケーションからソフトウェアを配布するための最良の戦略は何ですか? (ユーザーはトークンの入力を求められるべきではありません。)
提案された解決策は::
ユーザーがソフトウェアを提供する代わりに、Webアプリケーションからソフトウェアのダウンロードボタンをクリックすると、トークンとソフトウェアパッケージ(MSI)のダウンロード場所を含むVBScriptファイルが生成され、ダウンロードとして配信されます。その後、ユーザーがスクリプトを呼び出すと、次のことが起こります。
Windowsの世界は上記のソリューションを受け入れますか?彼らはそれを不自然に感じますか?当面の問題に対するより良い解決策はありますか?
あなたが他のソフトウェアベンダーから確かに見た標準的な解決策は、
そのプロセスを通じて、ユーザーが認証された後、トークンはライセンスファイルの形式でダウンロードされます。ユーザーが新しい認証なしで別のマシンにソフトウェアをインストールできるようにする場合は、ライセンスファイルを他のマシンにコピーできるようにします。 「ユーザーはトークンの入力を求められるべきではありません」と書いたが、実際には、ユーザーがVBSファイルを2台目のマシンにコピーする必要がある場合、またはライセンスファイルをコピーする必要がある場合の違いはどこにあるのか。
これは、ユーザーがライセンスファイルと一緒にソフトウェアを他の人に譲渡することを妨げるものではないことに注意してください。しかし、あなた自身のアプローチもそれを妨げないので、私はあなたがその問題の解決策を求めていないと思います。
別のアプローチは、VBSを使用しないことですが、exeファイルの形式でパーソナライズされたダウンローダーを生成します(1つだけの小さなコードファイルを変更してパーソナライズされたCまたはC++ソースコードを提供し、その上でコンパイルすることはそれほど難しくありません) -Webサーバーでフライする)。少なくともこれは、VBSダウンローダーで可能である、メモ帳のような単純なテキストエディターでの平均的なユーザーによる変更を禁止します。また、VBスクリプトを実行する方法をユーザーに教える必要はありません。
また、パーソナライズされたインストーラパッケージを提供したい場合は、3つ目のオプションがあります。 MSIパッケージをオンザフライで生成または再生成することができるため、個々のダウンロードごとにMSIパッケージ内の個人トークンファイルを置き換えることができます。 This SO post にはこれに関するいくつかの情報が含まれています here は、圧縮されたMSI内で単一のファイルを置き換える方法を示しています。あなたのケースのための最もスムーズなソリューションである。
実行するダウンロード可能なスクリプト-VBScriptまたはJavascript-は、特に非常に多くの黒い羊が悪意のあるソフトウェアをインストールするためにそのようなものを悪用しているので、私には非常に怪しげに聞こえます。プログラムを使用して、そのようなスクリプトを信頼、ダウンロード、および使用するようにトレーニングしたくない。
残念ながら、起こりうるセキュリティの脆弱性(インストーラパッケージの一部として誰かが意図せずにトークンを同僚に渡したような)を含まない、安全なファイアアンドフォーゲットのソリューションは考えられません。
理論的には、ブラウザプラグインをインストールして、Webアプリケーションとネイティブプログラム間の認証/通信ブリッジとして機能させることができます(EAが新しいバトルフィールドゲームのバトルログプラグインを使用して行うのと同様)。しかし、それでも完璧ではありません。
そのため、プログラムがインストールされたら(少し)より煩わしい方法でユーザーにログインの詳細を尋ねることを強くお勧めします。トークンを取り消す方法が必要になる場合があることを覚えておいてください(盗まれたマシンが原因である場合でも)。
確かではありませんが、ユーザーのトークンをインストーラーのファイル名に埋め込み、それを取得するためのコードをインストーラーに挿入することもできます。
ソフォスのウイルス対策ソフトウェアがこれを実行していないことを証明します。むしろ予想通り、 インストールに関する最も一般的な問題 のリストで1番目は「インストーラーファイル名の変更」です。しかし、利点は、インストーラーの内容がまったく変更されないため、それを配布するサーバーが、署名する秘密鍵にアクセスする必要がないことです。
とにかく、一般的な原則は、深刻なソフトウェアの場合、最も安全な場所で生成された署名済みの実行可能ファイルと、公開されているWebサーバーによってその場で生成される署名されていないトークンを配布することです。ユーザーが2つのファイルをダウンロードしたり、トークンをコピーして貼り付けたりしたくない場合は、ファイル名は、通信するために残されたビットだけです。
ユーザーのマシンで完全なユーザー権限で実行することを目的とした未署名のコードにトークンを配置すると、スクリプトだけでも、インストーラーに署名する目的が損なわれます。そのルートを使いたい場合は、almostで、ユーザーのトークンがパッチされた署名なしインストーラーを配布することもできます。マニアックなユーザーのごく一部にとって、非常に単純なVBScriptは、悪意がないことを目で確認できるため、署名する必要はありません。しかし、その数は多くないので、「ほぼ」は「非常に近い」です。
この質問には2つの側面があります。
ポイント1については、 ClickOnce 配置モデルをお勧めします。 Microsoft .NETフレームワークアプリケーションを構築したと想定しています。それ以外の場合でも、テクノロジープラットフォームにClickOnce配置に似たものを実装できます。特定のテクノロジではなく、展開モデルにさらに焦点を当てます。
ポイント2については、2つの異なる方法で対処できます-
トークン生成サービスに焦点を当てましょう。この要素は、ソリューションの両方のオプションに存在します。このサービスは、今日ユーザーがトークンを生成するために必要なコードです。トークンを生成するロジックが公開されないようにするには、検出とアクセスが制限されたWebサービスとしてそれをホストすることを検討する必要があります。
どちらの方法でも、ユーザーはトークンの入力を求められません。ただし、ユーザーIDは、ユーザーが予期するユーザー入力である可能性があります。 @Marioが指摘したように、どちらのアプローチでも、VBScriptスクリプトを実行するようにユーザーを教育するリスクは回避されます。さらに、アプリケーションのインストールプロセスは、クライアントマシンにアプリケーションのバイナリを登録するタスクです。ユーザーを登録するロジックは別の見方であり、ユーザーがVBScriptファイルを開いた場合とは異なり、ユーザーが微調整することはできません。