WinHTTP のセキュリティに関する考慮事項

WinHTTP を使用するアプリケーションには、次のセキュリティに関する考慮事項が適用されます。

• サーバー証明書は、セッションごとに 1 回だけ検証されます。 証明書が検証された後も、現在のセッションの間は有効なままになります。 証明書のフィンガープリントが一致する限り、証明書が変更されていないことを示す限り、証明書は再検証され続けます。 その結果、プロトコル、失効チェック、または certificate-error-ignore フラグを使用した検証条件の変更は、証明書が検証されると有効になりません。 このような変更をすぐに有効にするには、現在のセッションを終了し、新しいセッションを開始する必要があります。 同様に、セッション中の証明書の有効期限は、アプリケーション自体が証明書サーバーを定期的にチェックして有効期限データを取得する場合にのみ検出できます。
• 自動プロキシには、スクリプトのダウンロードと実行が含まれます。 自動プロキシ検出のサポートには、DHCP または DNS による検出、Java スクリプトなどのプロキシ スクリプトのダウンロード、実行が含まれます。 高度なセキュリティを実現するには、自動プロキシ検出がアウトプロセスで開始されるように、アプリケーションで WINHTTP_AUTOPROXY_RUN_INPROCESS フラグを渡さないようにする必要があります。 その場合でも、スクリプトが正しくアウトプロセスで実行されない場合、WinHTTP は既定で自動プロキシ スクリプトをインプロセスで実行しようとします。 このフォールバック動作が許容できないリスクをもたらすと思われる場合は、 WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY フラグを使用してフォールバック動作を無効にします。
• WINHTTP_STATUS_CALLBACK関数は速やかにを返す必要があります。 これらのコールバック関数のいずれかを記述するときは、ブロックしないように注意してください。 たとえば、コールバックも呼び出す関数も、ユーザー ダイアログを表示したり、イベントを待機したりしてはなりません。 WINHTTP_STATUS_CALLBACK関数がブロックすると、WinHTTP の内部スケジューリングに影響し、同じプロセス内の他の要求がサービスを拒否されます。
• WINHTTP_STATUS_CALLBACK関数は再入可能である必要があります。 コールバックを記述するときは、再入時に安全でない静的変数またはその他のコンストラクトを避け、再入可能でない他の関数を呼び出さないようにします。
• 非同期操作が可能な場合は、OUT パラメーターに NULL を渡します。 コールバック関数を登録して非同期操作を有効にした場合は、WinHttpQueryDataAvailable の lpdwDataAvailable、WinHttpReadData の lpdwBytesRead、WinHttpWriteData の lpdwBytesWritten などの OUT パラメーターに対して常に NULL 値を渡します。 状況によっては、操作が完了する前に呼び出し元のスレッドが終了し、OUT パラメーターが NULL でない場合、関数は既に解放されているメモリに書き込む可能性があります。
• パスポート認証は確実ではありません。 Cookie ベースの認証スキームは、攻撃に対して脆弱です。 Passport バージョン 1.4 は Cookie ベースであるため、Cookie またはフォーム ベースの認証スキームに関連付けられている脆弱性の影響を受けます。 WinHTTP では、パスポートのサポートは既定で無効になっています。 WinHttpSetOption を使用して有効にすることができます。
• 基本認証は、セキュリティで保護された接続経由でのみ使用する必要があります。 ユーザー名とパスワードをクリア テキストで送信する基本認証 ( RFC 2617 を参照) は、暗号化された SSL または TLS 接続でのみ使用する必要があります。
• 自動ログオン ポリシーを "低" に設定すると、リスクが発生する可能性があります。 自動ログオン ポリシーが low に設定されている場合、ユーザーのログオン資格情報を使用して、任意のサイトに対する認証を行うことができます。 ただし、信頼できないサイトに対して認証することは、セキュリティ上の良い方法ではありません。
• SSL 2.0 接続は、明示的に有効にしない限り使用されません。 TLS 1.0 および SSL 3.0 セキュリティ プロトコルは、SSL 2.0 よりもセキュリティが高いと見なされます。 既定では、WinHTTP は SSL 2.0 ではなく SSL 接続のネゴシエート時に TLS 1.0 または SSL 3.0 を要求します。 WinHTTP での SSL 2.0 のサポートは、 WinHttpSetOption を呼び出すことによってのみ有効にすることができます。
• 証明書失効チェックは明示的に要求する必要があります。 既定では、証明書認証を実行するときに、WinHTTP はサーバーの証明書が取り消されたかどうかをチェックしません。 証明書失効チェックは、 WinHttpSetOption を使用して有効にすることができます。
• アプリケーションでは、セッションが 1 つの ID にマップされていることを確認する必要があります。 WinHTTP セッションは、1 つだけの ID にマップする必要があります。つまり、WinHTTP セッションは、1 人の認証されたユーザーまたは匿名ユーザーのグループのインターネット アクティビティを管理するために使用されます。 ただし、WinHTTP ではこのマッピングが自動的に適用されないため、アプリケーションでは、1 つの ID のみが関係するようにするための手順を実行する必要があります。
• WinHTTP 要求ハンドルに対する操作は同期する必要があります。 たとえば、アプリケーションは、別のスレッドが要求を送受信している間に、あるスレッドで要求ハンドルを閉じないようにする必要があります。 非同期要求を終了するには、コールバック通知中に要求ハンドルを閉じます。 同期要求を終了するには、前の WinHTTP 呼び出しが返されたときにハンドルを閉じます。
• トレース ファイルには機密情報が含まれています。 トレース ファイルは Access-Control リスト (ACL) を使用して保護されるため、通常はローカル管理者または作成したユーザー アカウントのみがアクセスできます。不正アクセスによるトレース ファイルの侵害を避けます。
• WinHttpSetOptionを介して機密データを渡さないようにします。 使用する認証スキームを制御できず、機密データがクリア テキストで予期せず送信される可能性があるため、 WinHttpSetOption にユーザー名、パスワード、またはその他の資格情報を指定しないでください。 資格情報を設定するには、WinHttpSetOption の代わりに WinHttpQueryAuthSchemes と WinHttpSetCredentials を使用します。
• 自動リダイレクトは、セキュリティ上のリスクを引き起こす可能性があります。 既定では、POST に対してもリダイレクト (302 メッセージ) が自動的にフォローされます。 誤ったリダイレクトの可能性を回避するには、アプリケーションで自動リダイレクトを無効にするか、機密情報を投稿するときにコールバックの方向を監視する必要があります。
• ユーザー定義ヘッダーは、リダイレクト間で変更されずに転送されます。 WinHTTPAddRequestHeaders で追加された Cookie などのユーザー定義ヘッダーは、変更なしでリダイレクト間で転送されますが、WinHTTP によって生成されたヘッダーは自動的に更新されます。 リダイレクト間でユーザー定義ヘッダーを転送するとセキュリティ 上のリスクが生じる場合は、 WINHTTP_CALLBACK_STATUS_REDIRECT 完了と共に WINHTTP_STATUS_CALLBACK コールバックを使用して、リダイレクトが発生するたびに問題のヘッダーを変更します。
• WinHTTP は同期モードでは再入できません。 WinHTTP は同期モードでは再入可能ではないので、WinHTTP 関数内で実行されるアプリケーション スレッドで WinHTTP を呼び出すことができる非同期プロシージャ 呼び出し (APC) をスケジュールしないでください。 同期モードでは、WinHTTP は "アラート可能な待機" を実行し、待機中のスレッドが APC を実行するために事前に割り込まれた後に WinHTTP に再び入ると、WinHTTP の内部状態が破損する可能性があります。