人気のあるブラウザーがNPAPIアーキテクチャをサポートすることを拒否した後、生活はありますか

従来、強力な2要素認証と強化された電子署名のタスクは、トークンの形式で作成された暗号情報保護ツールを使用して解決されていました。 ユーザーが潜在的に脆弱な環境で作業している場合のサイバー犯罪者に対する保護を強化するために、トークンとTrust Screenデバイスが追加で使用されます。





デフォルトでは、ブラウザーはWebページコードにトークンおよびTrust Screenデバイスへのアクセスを提供しません。 このようなアクセスを実装するには、ブラウザ用の特別な拡張機能(プラグイン)の開発または他の技術の使用が必要です。 Javaアプレットとローカルプロキシを作成することもできます。

ブラウザ拡張機能は通常、NPAPI(Netscape Plugin Application Programming Interface)アーキテクチャを使用して開発されました。 JavaアプレットもNPAPIを介して機能しました。 Microsoft Internet Explorerの場合、原則として、ActiveXコンポーネントが開発されました。







NPAPI時代の終わり



NPAPIアーキテクチャの特定された脆弱性と制限により、ブラウザ開発者は独自のソリューションを支持してこのアーキテクチャのサポートを放棄し始めました。 そのため、Google ChromeはネイティブメッセージングテクノロジーとMozill Firefox WebExtensionsテクノロジーの使用を提案しました。 Yandex.Browserは、NPAPIの拒否も発表しました。 Microsoftは、Microsoft Edgeブラウザー用の独自の拡張機能開発プラットフォームの作成を発表しました。 Appleは、NPAPIのすべての脆弱性にもかかわらず、Safariブラウザーの代替拡張テクノロジーをまだ提案していないため、Mac OS Xユーザーは潜在的に脆弱です。

その結果、Webアプリケーション開発者は、さまざまなブラウザーで使用されるさまざまなテクノロジーの「動物園」にアプリケーションを適合させる必要がありました。 この状況は、セキュリティ機能を実装するためのトークンのマルチブラウザーサポートのタスクを複雑にし、そのようなデバイスの埋め込みとサポートの開発者のコ​​ストを増加させ、多数の潜在的な障害点を作成し、後方互換性の問題を引き起こしました。 特に、NPAPIアーキテクチャは、トークンを操作するための同期メソッドと非同期メソッドの両方をサポートしています。 ネイティブメッセージングテクノロジー-非同期のみ







疑問が生じました-さまざまな技術の「動物園」を取り除き、すべての一般的なブラウザでトークンのサポートを提供し、NPAPIを使用していた以前のソリューションと最も互換性のあるソリューションをリリースできる代替アプローチがありますか? 多くのAladdin R.D.テクノロジーパートナーがWebアプリケーションでNPAPIプラグインに基づくJC-WebClient 2.4ソリューションを使用したため、この瞬間は非常に重要でした。したがって、パートナーが新しいものにできるだけ簡単に移行できるようにすることが重要でしたJC-WebClientバージョン。 理想的には、Microsoft Windows 10のMicrosoft Edgeブラウザーをすぐにサポートしたいので、次のようになります。











ローカルプロキシサーバー



すべてのブラウザに共通する代替技術として、ローカルプロキシサーバーの技術を検討しました。







このアーキテクチャにより、すべての一般的なブラウザにトークンサポートを提供できますが、いくつかの欠点があります。 特に:





上記の欠点に関連して、このようなアーキテクチャは、最適なものとして認識されていませんでした。 さらに研究を続けました。



ローカルWebサーバー



ソリューションを分析し、このトピックに関する調査を実施した後、ローカルWebサーバーの技術に基づいてアプリケーションを開発することにしました。 このアーキテクチャとローカルプロキシサーバーテクノロジーの主な違いは、ローカルWebサーバーがブラウザーからリモートサーバーへのアプリケーショントラフィックの転送を妨げないことです。 ブラウザは、トークンおよび/またはTrust Screenデバイスの機能にアクセスするためにのみローカルWebサーバーにアクセスします。 電子サービスを使用している間、ユーザーはブラウザのアドレスバーにWebアプリケーションのページの1つの正しいURLが表示されたままです。

Microsoft Windowsプラットフォーム用に開発されたプロトタイプは、このテクノロジーが機能することを証明しています。 ただし、プロトタイプの最初のバージョンには重大な制限がありました。ローカルWebサーバーへのアクセスはHTTP経由でのみ行われ、ブラウザーの制限により、WebアプリケーションはリモートWebサーバーでHTTPSを使用できませんでした。 プロトタイプの2番目のバージョンを開発し、ローカルWebサーバーにTLSサポートを実装して、ブラウザーがHTTPSを介してローカルWebサーバーとリモートWebサーバーの両方との接続を確立できるようにしました。

プロトタイプの2番目のバージョンは、Microsoftが拡張機能を開発する機会をまだ提供していないMicrosoft Edgeを含む 、すべての一般的なブラウザーで正常に機能しました。 プロトタイプの2番目のバージョンに基づいて、 JC-WebClient 3.0ソリューションの新しいバージョンを開発し、一般的なすべてのブラウザーをサポートしました。











JC-WebClient 3.0の主要コンポーネント:







メリット



ローカルWebサーバーの選択されたテクノロジーにより、JC-WebClient 3.0でトークンを操作するための同期メソッドと非同期メソッドの両方をサポートできるようになりました。 もう1つの利点は、以前にNPAPIを使用していたWebサービス開発者が、同じブラウザータブ内でアプリケーションのページを切り替えてもトークンセッションを保存する機能を失うことがなかったことです。 これら2つの状況により、テクノロジーパートナー向けにJC-WebClient 2.4からバージョン3.0への移行プロセスを容易にすることができました。 新しいバージョンに切り替えるには、グラフィカルインターフェイスのロジックをやり直すことなく、トークンで動作する各Webページに同じコードの複数の行を追加するだけで十分です。

異なるブラウザタブ間でコンテキストを分離することにより、Webアプリケーションが実行されているタブ以外のタブからトークンにアクセスしようとする悪意のあるスクリプトから保護することが可能になりました。



使いやすさ



一般的なシナリオでは、JC-WebClient 3.0配布パッケージはWebサービスページからダウンロードされ、ユーザーのコンピューターに1回インストールされます。その後、JC-WebClient 3.0バンドルのローカルWebサーバーはインストール後すぐに自動的に起動します。 ローカルWebサーバーはバックグラウンドで排他的に実行されます。 最小限のリソースを消費し、コントロールはありません。 また、新しいバージョンがリリースされたときに簡単に更新できます。



サポートされているハードウェアデバイス



強力な2要素認証と電子署名の手段として、JC-WebClient 3.0はJaCartaおよびeToken USBトークン/スマートカードをハードウェアで実装されたロシアの暗号化アルゴリズムとともに使用します。 それらの中で-JaCarta GOSTJaCarta PKI / GOSTeToken GOST 。 信頼できるトラストスクリーンデバイス-Antifraud-terminalとして、Aladdin R.D.の専有製品



サポートされているオペレーティングシステム



バージョンJC-WebClient 3.0は、Microsoft Windows XPからMicrosoft Windows 10までのMicrosoft Windowsプラットフォームをサポートしています。近い将来、Mac OS XとLinuxをサポートするバージョン3.1のリリースが計画されています。 ニュースをフォローしてください。




All Articles