PHPのブックセキュリティ（パート4）。 セキュリティの欠如（HTTPS、TLS、およびSSL）

「PHPのセキュリティ」という本（パート1）

「PHPのセキュリティ」という本（パート2）

「PHPのセキュリティ」という本（パート3）

プロセス参加者間のインターネットを介した通信にはリスクが伴います。 オンラインサービスを使用して支払い注文をストアに送信する場合、攻撃者がオンラインアプリケーションへのHTTP要求を傍受、読み取り、変更、または再試行できるようにすることは絶対に望ましくありません。 攻撃者がセッションのCookieを検討したり、受取人、商品、請求先住所を変更した結果を想像してください。 または、ユーザーのリクエスト、HTMLまたはJavaScriptへの応答としてストアから送信されたマークアップに埋め込みます。

重要な個人データの保護は深刻なビジネスです。 ブラウザとアプリケーションのユーザーは、セキュリティに関して非常に高い期待を持っています。 特に重要なのは、銀行カード取引の完全性、プライバシー、および識別情報です。 これらの問題を解決するには、プロセスの2人の参加者間のデータ転送を保護するために、通常HTTPS、TLS、SSLを含むトランスポートレベルのセキュリティが必要です。

保護対策の主な目的：

• 転送されたデータの安全な暗号化。
• 情報交換の片側または両側の保証された識別。
• データ破損保護。
• リプレイ攻撃に対する保護。

最も重要なポイント：トランスポートレベルで保護を成功させるには、4つの問題すべてを解決する必要があります。 少なくとも何らかの方法で成功しなければ、深刻な問題が待っています。

多くの人が、暗号化が重要なタスクであると誤って信じており、他のすべてはオプションです。 これは完全に真実ではありません。 送信されたデータを暗号化するとき、受信者はそれを復号化できる必要があります。 これは、クライアントが安全な接続を確立しようとするネゴシエーションフェーズ中に、クライアントとサーバーが（特に）暗号化キーに同意する場合に可能です。 ただし、攻撃者は簡単な方法を使用してクライアントとサーバーの間で侵入することができます。 クライアントマシンを強制的にサーバーと見なすことができます。これは、「中間者」攻撃（MitM、中間者）と呼ばれます。 そして、暗号化キーのネゴシエーションは、実際のサーバーではなく、偽物で行われます。 これにより、攻撃者はクライアントから送信されたすべてのデータを解読できます。 明らかに、このシナリオから保護するには、2番目の要件、つまりクライアントが通信しているサーバーの識別を検証する機能を遵守する必要があります。 このチェックなしでは、ターゲットサーバーとフロントサーバーを区別しません。

そのため、安全な接続のためには、4つの条件すべてを満たす必要があります。 それぞれが他の3つを理想的に補完し、トランスポートレベル（Transport Layer Security、TLS）で信頼性と持続性のあるセキュリティを提供します。

TLSの技術的側面に加えて、品質保証には別の側面があります。 たとえば、ユーザーがアプリケーション承認フォームにHTTPデータを入力できるようにする場合、承認データがインターセプトされ、その後使用されるMitM攻撃の可能性を受け入れる必要があります。 または、HTTPSで読み込まれたページに非HTTPSリソースを読み込むことを許可する場合、MitM攻撃者がクロスサイトスクリプティング攻撃を実行し、ユーザーのブラウザを事前にプログラムされた武器に変える手段を持っていることを受け入れる必要がありますブラウザベースのHTTPS接続を介して透過的に動作します。

上記の4つの主なタスクから生じる明らかな基準は、セキュリティ対策の品質を評価するのに役立ちます。

• 暗号化：強力な暗号化標準と暗号スイートが使用されていますか？
• 識別：サーバー識別の正確さと完全性は検証されていますか？
• データの歪み：セッション中、ユーザーデータは完全に保護されていますか？
• リプレイ攻撃：リクエストを記録して攻撃者がサーバーに送り返し、既知のアクションや効果をリプレイできるようにする攻撃者に対する保護方法はありますか？

これらは、本の第4部全体の重要な質問です。 これらの詳細やその他の詳細を掘り下げますが、肯定的な答えが得られない場合、すべてが何らかの形でこれらの質問と脆弱性の定義を中心に展開します。

もう1つの重要なポイントは、どのデータを保護する必要があるかです。 明らかに、これらは銀行カードの詳細、身元を確認できる情報、およびパスワードです。 ユーザーセッションIDはどうですか？ IDではなくパスワードを保護すると、攻撃者は送信されたCookieを盗み、セッションハイジャック攻撃を実行して、自分のコンピューターでユーザーになりすますことができます。 認証データを保存するには、認証フォームを保護するだけでは十分ではありません。 フォームにデータを入力してからセッションが終了するまで、HTTPSのフレームワーク内でのみユーザーセッションが実行される場合、最高の保護が実現されます。

ここで、なぜ「十分ではない」という言葉を理解する必要があります。 SSL / TLS実装の問題は、それらを使用しないだけでなく、最大限のセキュリティを確保するのに不十分な程度に使用することでもあります。

3つの観点から輸送の不安定性を検討します。

• サーバーアプリケーションとサードパーティサーバー間。
• クライアントとサーバーアプリケーション間。
• カスタムセキュリティポリシーを使用するクライアントとサーバーアプリケーション間。

最初の項目には、Webアプリケーションが他のプロセス参加者に安全に接続していることの確認が含まれます。 TLSは一般に、WebサービスAPIおよびアプリケーションの実行に必要な他の多くの入力ソースに使用されます。

2番目の項目は、ブラウザまたは他のクライアントアプリケーションを介したユーザーとWebアプリケーションとの対話です。 この場合、セキュリティで保護されたURLを公開し、セキュリティ対策が正しく実装されていることを確認して、それらをバイパスするリスクがないようにする必要があります。

3番目のポイントには、あらゆる種類の派手なソリューション（奇妙な奇妙さ）が含まれます。 SSL / TLSはプログラマーによって不適切に実装された標準に定評があるため、SSL / TLSなしで安全な接続を確保する方法は多数あります。 例は、SSL / TLSを必要としないが、それらによって提供される多くの保護手段を提供する署名済み要求のOAuthプロトコルによる使用です（特に、要求データの暗号化は省略されます）。 したがって、これは理想的なソリューションではありませんが、誤って構成されたSSL / TLSライブラリよりも優れています。

詳細を説明する前に、まずTLSの概要を見て基本的な知識を得てから、PHPの内部について深く掘り下げましょう。

定義と根本的な脆弱性

TLSは、暗号化、認証検証などを使用して2人の参加者の間に安全な接続を作成する方法を説明する一般的な名前です。 それらとその関係について簡単に見てみましょう。

PHPからのSSL / TLS（サーバーサーバー）

PHPをプログラミング言語としてどれほど愛しても、人気のあるオープンソースライブラリの最も表面的な概要でさえ明らかになります。それらには、あらゆる段階でトランスポートレベルのセキュリティ関連の脆弱性が含まれています。 また、PHPコミュニティは、問題を解決するよりもユーザーを脅かす方が簡単だからといって、正当な理由もなくこれらの脆弱性に苦しんでいます。 状況は、PHP自体が、ソケットベースのHTTPクライアントからfile_get_contents()



およびその他のファイルシステム関数に至るまで、あらゆる場所で使用されるPHPストリームでのSSL / TLSの実装が非常に貧弱であるという事実によって悪化します。 これに加えて、PHPライブラリの作成者は、SSL / TLSの潜在的なセキュリティへの影響についても議論しようとしていません。

この章で説明することを何も実行しない場合は、少なくともPHPのcURL拡張を使用してすべてのHTTPS要求を実行します。 デフォルト設定はセキュリティを提供し、さらに、拡張機能はPHPの範囲外の多数のユーザーの専門家による評価に依存しています。 したがって、セキュリティを向上させるためにこの簡単なステップを踏むと、後悔することはありません。 理想的な解決策は、PHPの作成者が最終的に起動し、組み込みのSSL / TLSサポートでSecure By Default原則（デフォルトセキュリティ）を実装する場合です。

PHPでのSSL / TLSの紹介は非常に失礼でした。 TLSの脆弱性は、ほとんどのセキュリティ問題よりもはるかに単純であり、ブラウザーにとってこれがどれほど重要であるかは誰もが知っています。 しかし、サーバーアプリケーションは、ユーザーデータのセキュリティチェーンにおいても同様に重要なリンクです。 それでは、PHPのSSL / TLSを詳しく見てみましょう。次に、PHPスレッドと優れたcURL拡張機能を見てみましょう。

PHPスレッド

ストリームに慣れていない場合：ファイル、ネットワーク、および共通の機能を共有する他の操作を一般化するために必要です。 ストリームが特定のプロトコルを使用する方法を知るには、ラッパーを使用して、ストリームがファイル、HTTPリクエスト、PHARアーカイブ、データURI（RFC 2397）などを表すことができます。ストリームを開始するには、補助ファイル関数を呼び出すだけで十分です（サポートファイル関数）に対応するURLを使用して、ラッパーとターゲットリソースを示します。

 file_get_contents('file:///tmp/file.ext');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、ストリームはファイルラッパー（ファイルラッパー）を使用するため、通常、URLは必要ありません。ファイルへの相対パスでも十分です。 file()



、 include()



、 require_once



file_get_contents()



などのほとんどのファイルシステム関数はストリーム参照を受け入れるため、これは明らかです。 したがって、前の例を書き直します。

 file_get_contents('/tmp/file.ext');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

議論中のトピックを考えると、これを行うことができます：

 file_get_contents('http://www.example.com');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

file_get_contents()



などのファイルシステム関数はHTTPラップストリームをサポートしているため、PHPでHTTPクライアントを形成します。これは非常に簡単にアクセスできます。 専用のライブラリを使用して、Guzzle、Buzz、またはZend \Zend\Http\Client



フレームワークのクラスなどのHTTPクライアントを作成する必要がないと感じる場合に使用できます。 シンプルなクライアントが機能するには、 php.ini



でallow_url_fopen



オプションを有効にする必要がありphp.ini



。 デフォルトでは有効になっています。

もちろん、 allow_url_fopen



有効にすると、リモートファイルの実行による攻撃のリスクが伴い、アクセス制御や情報漏えいが回避されます。 攻撃者がオプションでリモートURIをファイル関数に挿入できる場合、リモートの信頼できないソースからのものを含め、ダウンロードしたファイルをアプリケーションに簡単に実行、保存、または表示させることができます。

ファイルはlocalhost



からダウンロードされることを忘れないでください。これは、ローカルサーバーに登録されている制限に基づいてアクセス制御をバイパスできることを意味します。 また、 allow_url_fopen



オプションallow_url_fopen



デフォルトで有効になっている場合、最大限のセキュリティを確保するには無効にする必要があります。

PHPストリームを単純なHTTPクライアントとして使用することに戻りましょう（これでお勧めできません ）。 これを行おうとすると、すべてがより興味深いものになります。

 $url = 'https://api.twitter.com/1/statuses/public_timeline.json'; $result = file_get_contents($url);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、HTTPSを介した（以前の）Twitter API 1.0への単純な非認証リクエストです。 重大なリークがあります。 HTTPS-（https：//）およびFTPS-（ftps：//）ラッパーを使用して行われたリクエストの場合、PHPはSSL Context



使用します。 SSL / TLSには多くの設定があり、それらのデフォルト値は完全に安全ではありません。 file_get_contents()



パラメーターとして設定された元のSSL Context



設定を挿入する方法を示すために例を変更します。

 $url = 'https://api.twitter.com/1/statuses/public_timeline.json'; $contextOptions = array( 'ssl' => array() ); $sslContext = stream_context_create($contextOptions); $result = file_get_contents($url, NULL, $sslContext);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前述のように、SSL / TLSを正しく構成しないと、アプリケーションは「中間者」攻撃に対して無防備になります。 デフォルトでは、PHPストリームはSSL / TLSを使用して作業する場合、完全に安全ではありません。 完全に安全になるように例を修正しましょう。

 $url = 'https://api.twitter.com/1/statuses/public_timeline.json'; $contextOptions = array( 'ssl' => array( 'verify_peer' => true, 'cafile' => '/etc/ssl/certs/ca-certificates.crt', 'verify_depth' => 5, 'CN_match' => 'api.twitter.com', 'disable_compression' => true, 'SNI_enabled' => true, 'ciphers' => 'ALL!EXPORT!EXPORT40!EXPORT56!aNULL!LOW!RC4' ) ); $sslContext = stream_context_create($contextOptions); $result = file_get_contents($url, NULL, $sslContext);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今、すべてが大丈夫です！ 以前のバージョンと比較すると、PHPによって最初に設定または無効化されなかった4つのオプションが設定されていることがわかります。 彼らが何をするか見てみましょう。

• verify_peer

ピア検証-HTTPSリクエストを送信したホストによって提供されたSSL証明書の有効性の検証。 正しい証明書は、信頼できる認証局（CA）の秘密鍵で署名されます。 検証は、使用するSSLコンテキストのcafile



オプションとしてファイルセットに含まれているCA公開キーを使用して実行できます。 また、証明書の有効期限が切れないようにする必要があります。

• cafile

cafile



は、信頼できるCAの公開鍵を含む有効なファイルを指す必要があります。 PHPでは、これは自動的に行われないため、リンクされたファイルにキーを特別な形式（通常はPEMまたはCRT）で保管してください。 コピーが見つからない場合は、 Mozilla VCSからダウンロードして解析します。 このファイルがなければ、ピアをチェックすることは不可能であり、リクエストは実行されません。

• verify_depth

この設定は、中間証明書発行者の最大数、つまり元のクライアント証明書の検証に使用できるCA証明書の数を指定します。

• CN_match

前述の3つのオプションは、サーバーから提供された証明書の検証に関連しています。 ただし、それらは私たちが要求したドメイン名またはIP、つまりホストに関連するURLの一部に対して有効かどうかを理解するのに役立ちません。 証明書が現在のドメイン/ IPにバインドされているかどうかを確認するために、ホスト検証（ホスト検証）を実行します。 PHPでは、サブドメインがある場合は、 CN_match



ホスト値（SSLコンテキスト内）を設定する必要があります。 このオプションが設定されている限り、PHPは内部チェックを実行します。 これが行われない場合、中間者攻撃中に、攻撃者は信頼できるCAによって署名された有効な証明書を提供できます。 ただし、証明書は攻撃者の制御下にあるドメインに対して有効であり、接続したいドメインに対しては有効ではありません。 CN_match



オプションを設定すると、証明書の不一致を特定し、HTTPS要求の失敗につながります。

攻撃者が使用する有効な証明書には攻撃者の識別情報が含まれているため（これを取得するための条件です！）、経験豊富な攻撃者は、対応する秘密キーを備えた有効な署名付きCA証明書にいくつでもアクセスできることに注意してください。 他の会社から盗まれたり、信頼できるCAチェックをすり抜けたりする可能性があります。 これは、2011年にDigiNotorがgoogle.com



不明なパーティの証明書を発行したときに起こりました。 彼女は、主にイランのユーザーに対する「中間者」攻撃に使用しました。

• disable_compression

このオプションは、PHP 5.4.13で登場しました。 CRIME攻撃およびBEASTのようなパディングを伴う他の攻撃から保護する必要があります。 この記事の執筆時点では、このオプションは10か月間利用可能です。 オープンソースPHPでの使用のほとんど唯一の例を見つけるには、多くの忍耐が必要でした。

• SNI_enabled

単一のIPが複数のSSL証明書で動作するように構成できる場合、すべてのサイトまたはこのIPでホストされる非HTTPサービスに限定されないように、サーバー名表示のサポートが含まれます。

• 暗号

この設定は、SSL / TLS接続を確立するときに、どの暗号を選択すべきか、または選択すべきでないかを表示するのに役立ちます。 デフォルトのリストは、openssl拡張機能によって提供されます。 使用を強制されない限り、無効にする必要がある安全でない暗号が含まれています。 以下のリストは、opensslで受け入れられている構文を使用して、2014年1月にcURLによって実装されました。 転送の完全なセキュリティ（Perfect Forward Secrecy）に重点が置かれているため、Mozillaによって提案された代替リストの方が優れている可能性があります。これは最良の実用的なアプローチです。 Mozillaのリストはもっと長いです：

 ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

制限事項

上記のように、中間者攻撃中に使用しているURLで指定されたホストに対してサーバーから提供された証明書の有効性をチェックしても、不正に購入または受信した有効な証明書を単にスリップすることはできません。 これは、接続を完全に安全にするための4つの重要なステップの1つです。

システムは、PHP HTTPSラッパーのSSL Context



によって宣言されたCN_match



パラメーターのおかげでチェックを実行します。 しかし、彼には欠陥があります。 執筆時点では、SSL証明書の共通名（Common Name、CN）のみがチェックされ、証明書で定義されたSubject Alternative Name（SAN）フィールドの有効性はチェックされませんでした。 SANでは、単一のSSL証明書で複数のドメイン名を保護できるため、非常に重要であり、最新のすべてのブラウザーでサポートされています。 また、PHPはまだSANチェックをサポートしていないため、このような証明書で保護されたドメインへのSSL / TLS接続は確立されません。 SANのサポートは、バージョン5.6以降のPHPで提供される予定です。

一方、そのまま使用できるcURL拡張機能はSANをサポートしているため、組み込みのPHP HTTPS / FTPSラッパーと比較して、その使用ははるかに信頼性が高く望ましい方法です。 この点で、PHPストリームを高い確率で使用すると、誤った動作が発生する可能性があり、短気なプログラマーはホストチェック全体を単純にオフにしますが、これは非常に望ましくありません。

PHPソケットのSSLコンテキスト

PHPの多くのHTTPクライアントは、cURLアダプターとデフォルトのPHPソケットアダプターの両方を提供します。 後者のデフォルトの使用は、cURLがオプションの拡張機能であることを意味し、実際には無効にできます。

PHPソケットは、PHPスレッドと同じSSL Context



リソースを使用するため、上記と同じ問題と制限があります。 副作用：多くの主要なHTTPクライアントは、アプリオリに信頼性が低く、本来よりも安全性が低い可能性があります。 可能であれば、そのようなクライアントライブラリはcURLアダプタを使用するように構成する必要があります。 また、クライアントが正しいSSL / TLSセキュリティアプローチを使用することを忘れないようにしてください。

追加のリスク

CURL拡張

PHPストリームとは異なり、cURL拡張機能はHTTPリクエストを含むデータのみを転送します。 また、 SSL Context



フローとは異なり、cURLはデフォルトでSSL / TLSを介して安全にリクエストを実行します。 CA証明書パッケージ用のストレージなしでコンパイルされた場合（たとえば、cert.pemファイルまたは信頼できるCA証明書付きのca-bundle.crtなし）でコンパイルされた場合を除き、これに対して何もする必要はありません。

これには特別なアプローチは必要ないため、TwitterのAPIを呼び出すことができます。これは、PHPストリームを使用したSSL / TLSの場合と同様です。 最小限の手間、および中間攻撃の男性のためにあなたを開くいくつかのオプションを忘れるという事実を心配しないでください。

 $url = 'https://api.twitter.com/1/statuses/public_timeline.json'; $req = curl_init($url); curl_setopt($req, CURLOPT_RETURNTRANSFER, TRUE); $result = curl_exec($req);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、HTTPSリクエストにはcURLをお勧めします。 これはデフォルトでは安全ですが、PHPスレッドはおそらく安全ではありません。 それ以外の場合は、cURLを使用するだけで、頭痛から解放されます。 最終的に、cURLはより安全で、必要なコードが少なく、人為的エラーによりSSL / TLSセキュリティで失敗する可能性が低くなります。

執筆時点で、PHP 5.6はalpha1に達しました。 最終リリースでは、PHPストリームおよびSSL / TLSを介したソケット接続のより安全なデフォルトが導入されます。 これらのイノベーションは、PHP 5.3、5.4、または5.5には移植されません。 したがって、プログラマーはPHP 5.6が最低限必要になるまで、安全なデフォルト設定を意識的に実装する必要があります。

もちろん、信頼できる証明書のパッケージの配置を構成せずにcURL拡張機能を有効にした場合、上記の例は機能しません。 公に配布されたライブラリの場合、安全な動作を強制する必要があります。

 $url = 'https://api.twitter.com/1/statuses/public_timeline.json'; $req = curl_init($url); curl_setopt($req, CURLOPT_RETURNTRANSFER, TRUE); $result = curl_exec($req); /** * ,     SSL,      * CA-, ,      *  ext/curl.  77   CURLE_SSL_CACERT_BADFILE,  *  -         PHP. */ $error = curl_errno($req); if ($error == CURLE_SSL_PEER_CERTIFICATE || $error == CURLE_SSL_CACERT || $error == 77) { curl_setopt($req, CURLOPT_CAINFO, __DIR__ . '/cert-bundle.crt'); $result = curl_exec($req); } /** *        . *     SSL    ;). */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最も難しいのは、明らかにcert-bundle.crt



またはcafile.pem



証明書パッケージファイルを配布することです（ファイル名はソースによって異なります！）。 CAの証明書は、セキュリティまたはピアレビュープロセスに違反した場合、ほとんどのブラウザでいつでも失効する可能性があるため、証明書ファイルを長期間更新しないことはお勧めできません。 ただし、最も明らかな解決策は、必要なライブラリまたはアプリケーションファイルのコピーを配布することです。

配布された証明書パッケージの更新を厳密に制御できない場合、またはこれを定期的に確認できるツールが必要な場合は、 Sslurpを使用してください 。

クライアント側のSSL / TLS接続（クライアント/ブラウザーサーバー）

以前に話したことのほとんどは、PHP Webアプリケーションのイニシアチブで別のサーバーと確立されたSSL / TLS接続に関連していました。 もちろん、アプリケーションがクライアントブラウザーや他のアプリケーションにSSL / TLSサポートを提供する場合、多くのセキュリティ上の問題があります。 これにより、トランスポートレベルでのセキュリティの脆弱性に関連する攻撃のリスクが高まります。

考えてみると、これは非常に簡単です。 ユーザーパスワードの入力時に保護を提供するオンラインアプリケーションを作成しているとします。 承認フォームはHTTPS経由で提供され、そこからのデータもHTTPS経由で送信されます。 ミッションは完了しました。 アカウントで作業を開始するために、ユーザーはHTTP URLにリダイレクトされました。 問題に気づきましたか？

「中間者」攻撃の脅威がある場合、承認フォームを保護してから閉じるだけではいけません。 ユーザーセッションとすべての入力データ、およびユーザーが受信したすべてのHTMLコードのCookieは、HTTP経由で作業する場合は安全ではありません。 攻撃者はCookieを盗んでユーザーになりすますことができ、ユーザーが受信したページにXSSコードを挿入して、ユーザーに代わってタスクを実行したり、アクションを制御したりできます。 そして、これらすべてのために、ユーザーのパスワードは必要ありません。

HTTPSのみで認証プロセスを保護すると、パスワードの直接盗難は防止されますが、セッションハイジャック、他の形式のデータ盗難、およびXSS攻撃のコードの導入に対する保護は行われません。 HTTPSを使用して1人のユーザーのみを保護すると、トランスポートレベルでの保護が不十分になります。 ユーザーは、中間者攻撃に対して脆弱なままです。