web-dev-qa-db-ja.com

VBScriptを使用してソフトウェアをインストールするのは標準的に受け入れられている方法ですか?

次の要件を検討してください

  1. 基本認証を使用してWebアプリケーションと通信するWindowsソフトウェア
  2. ソフトウェアは [〜#〜] msi [〜#〜] パッケージです
  3. ソフトウェアは、Webアプリケーションに対して自身を認証するためにトークンを配置する必要があります
  4. トークンはすべてのユーザーに固有ですが、ユーザーは複数のマシンに同じトークンでソフトウェアをインストールすることが期待されています

質問は

適切なトークンを含むWebアプリケーションからソフトウェアを配布するための最良の戦略は何ですか? (ユーザーはトークンの入力を求められるべきではありません。)

提案された解決策は:

ユーザーがソフトウェアを提供する代わりに、Webアプリケーションからソフトウェアのダウンロードボタンをクリックすると、トークンとソフトウェアパッケージ(MSI)のダウンロード場所を含むVBScriptファイルが生成され、ダウンロードとして配信されます。その後、ユーザーがスクリプトを呼び出すと、次のことが起こります。

  • ソフトウェアがダウンロードされ、トークンがインストーラーに渡され、インストーラー内のカスタムアクションがトークンを取得し、それに応じてアプリケーションを構成します

Windowsの世界は上記のソリューションを受け入れますか?彼らはそれを不自然に感じますか?当面の問題に対するより良い解決策はありますか?

4
k4vin

あなたが他のソフトウェアベンダーから確かに見た標準的な解決策は、

  • ユーザーにソフトウェアのダウンロードとインストールを許可します。登録の有無にかかわらず、ソフトウェア自体がユーザーに登録プロセスを案内するようにします。

そのプロセスを通じて、ユーザーが認証された後、トークンはライセンスファイルの形式でダウンロードされます。ユーザーが新しい認証なしで別のマシンにソフトウェアをインストールできるようにする場合は、ライセンスファイルを他のマシンにコピーできるようにします。 「ユーザーはトークンの入力を求められるべきではありません」と書いたが、実際には、ユーザーがVBSファイルを2台目のマシンにコピーする必要がある場合、またはライセンスファイルをコピーする必要がある場合の違いはどこにあるのか。

これは、ユーザーがライセンスファイルと一緒にソフトウェアを他の人に譲渡することを妨げるものではないことに注意してください。しかし、あなた自身のアプローチもそれを妨げないので、私はあなたがその問題の解決策を求めていないと思います。

別のアプローチは、VBSを使用しないことですが、exeファイルの形式でパーソナライズされたダウンローダーを生成します(1つだけの小さなコードファイルを変更してパーソナライズされたCまたはC++ソースコードを提供し、その上でコンパイルすることはそれほど難しくありません) -Webサーバーでフライする)。少なくともこれは、VBSダウンローダーで可能である、メモ帳のような単純なテキストエディターでの平均的なユーザーによる変更を禁止します。また、VBスクリプトを実行する方法をユーザーに教える必要はありません。

また、パーソナライズされたインストーラパッケージを提供したい場合は、3つ目のオプションがあります。 MSIパッケージをオンザフライで生成または再生成することができるため、個々のダウンロードごとにMSIパッケージ内の個人トークンファイルを置き換えることができます。 This SO post にはこれに関するいくつかの情報が含まれています here は、圧縮されたMSI内で単一のファイルを置き換える方法を示しています。あなたのケースのための最もスムーズなソリューションである。

6
Doc Brown

実行するダウンロード可能なスクリプト-VBScriptまたはJavascript-は、特に非常に多くの黒い羊が悪意のあるソフトウェアをインストールするためにそのようなものを悪用しているので、私には非常に怪しげに聞こえます。プログラムを使用して、そのようなスクリプトを信頼、ダウンロード、および使用するようにトレーニングしたくない。

残念ながら、起こりうるセキュリティの脆弱性(インストーラパッケージの一部として誰かが意図せずにトークンを同僚に渡したような)を含まない、安全なファイアアンドフォーゲットのソリューションは考えられません。

理論的には、ブラウザプラグインをインストールして、Webアプリケーションとネイティブプログラム間の認証/通信ブリッジとして機能させることができます(EAが新しいバトルフィールドゲームのバトルログプラグインを使用して行うのと同様)。しかし、それでも完璧ではありません。

そのため、プログラムがインストールされたら(少し)より煩わしい方法でユーザーにログインの詳細を尋ねることを強くお勧めします。トークンを取り消す方法が必要になる場合があることを覚えておいてください(盗まれたマシンが原因である場合でも)。

9
Mario

確かではありませんが、ユーザーのトークンをインストーラーのファイル名に埋め込み、それを取得するためのコードをインストーラーに挿入することもできます。

ソフォスのウイルス対策ソフトウェアがこれを実行していないことを証明します。むしろ予想通り、 インストールに関する最も一般的な問題 のリストで1番目は「インストーラーファイル名の変更」です。しかし、利点は、インストーラーの内容がまったく変更されないため、それを配布するサーバーが、署名する秘密鍵にアクセスする必要がないことです。

とにかく、一般的な原則は、深刻なソフトウェアの場合、最も安全な場所で生成された署名済みの実行可能ファイルと、公開されているWebサーバーによってその場で生成される署名されていないトークンを配布することです。ユーザーが2つのファイルをダウンロードしたり、トークンをコピーして貼り付けたりしたくない場合は、ファイル名は、通信するために残されたビットだけです。

ユーザーのマシンで完全なユーザー権限で実行することを目的とした未署名のコードにトークンを配置すると、スクリプトだけでも、インストーラーに署名する目的が損なわれます。そのルートを使いたい場合は、almostで、ユーザーのトークンがパッチされた署名なしインストーラーを配布することもできます。マニアックなユーザーのごく一部にとって、非常に単純なVBScriptは、悪意がないことを目で確認できるため、署名する必要はありません。しかし、その数は多くないので、「ほぼ」は「非常に近い」です。

4
Steve Jessop

この質問には2つの側面があります。

  1. アプリケーションのパッケージ化
  2. ユーザートークンの配布

ポイント1については、 ClickOnce 配置モデルをお勧めします。 Microsoft .NETフレームワークアプリケーションを構築したと想定しています。それ以外の場合でも、テクノロジープラットフォームにClickOnce配置に似たものを実装できます。特定のテクノロジではなく、展開モデルにさらに焦点を当てます。

ポイント2については、2つの異なる方法で対処できます-

  1. 小さなアプリケーション(現在のVBScriptコードに似たもの)の構築を検討してください。ただし、このアプリケーションは.exeのような実行可能ファイルです。このアプリケーションは、配布するプログラムと一緒にパッケージ化されます。これをProduct Activatorと呼びます。その唯一の目的は、トークン生成サービスに接続し、現在のユーザーに対して1つのトークンを取得することです。ユーザーからユーザーIDを収集するためのUIフィールドがあるとします。この製品アクティベータは、Web経由で配布するアプリケーションのより大きなポートフォリオの一部になる可能性があります。
  2. アプリケーションの一部として、上記の製品アクティベータと同じアクティビティを実行するワンタイムスタートアップモジュール/コードが存在する場合があります。

トークン生成サービスに焦点を当てましょう。この要素は、ソリューションの両方のオプションに存在します。このサービスは、今日ユーザーがトークンを生成するために必要なコードです。トークンを生成するロジックが公開されないようにするには、検出とアクセスが制限されたWebサービスとしてそれをホストすることを検討する必要があります。

どちらの方法でも、ユーザーはトークンの入力を求められません。ただし、ユーザーIDは、ユーザーが予期するユーザー入力である可能性があります。 @Marioが指摘したように、どちらのアプローチでも、VBScriptスクリプトを実行するようにユーザーを教育するリスクは回避されます。さらに、アプリケーションのインストールプロセスは、クライアントマシンにアプリケーションのバイナリを登録するタスクです。ユーザーを登録するロジックは別の見方であり、ユーザーがVBScriptファイルを開いた場合とは異なり、ユーザーが微調整することはできません。

3
Siva Senthil