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 でない場合、関数は既に解放されているメモリに書き込むことになる可能性があります。
• Passport 認証は絶対確実なものではありません。 Cookie ベースの認証スキームは、攻撃に対して脆弱です。 Passport バージョン 1.4 は Cookie ベースであるため、Cookie またはフォーム ベースの認証スキームに関連付けられている脆弱性の影響を受けます。 WinHTTP では、Passport のサポートは既定で無効になっていますが、WinHttpSetOption を使用して有効にすることができます。
• 基本認証は、セキュリティで保護された接続でのみ使用する必要があります。 ユーザー名とパスワードをクリア テキストで送信する基本認証 (RFC 2617 を参照) は、暗号化された SSL 接続または TLS 接続でのみ使用する必要があります。
• 自動ログオン ポリシーを "低" に設定すると、リスクが生じる可能性があります。 自動ログオン ポリシーが低に設定されている場合、ユーザーのログオン資格情報を使用して任意のサイトに対する認証ができます。 ただし、信頼できないサイトに対して認証することは、セキュリティ上、適切な行為ではありません。
• SSL 2.0 接続は、明示的に有効にしない限り、使用されません。 TLS 1.0 および SSL 3.0 のセキュリティ プロトコルは、SSL 2.0 よりも安全であるとみなされます。 既定では、WinHTTP は SSL 接続をネゴシエートするときに、SSL 2.0 ではなく、TLS 1.0 または SSL 3.0 を要求します。 WinHTTP での SSL 2.0 のサポートは、WinHttpSetOption を呼び出すことによってのみ有効にできます。
• 証明書失効チェックを明示的に要求する必要があります。 既定では、証明書認証を実行するときに、WinHTTP はサーバーの証明書が失効されたかどうかを確認しません。 証明書失効チェックは、WinHttpSetOption を使用して有効にすることができます。
• アプリケーションは、セッションが 1 つの ID にマップされていることを確認する必要があります。 WinHTTP セッションは、1 つの ID にのみマップする必要があります。つまり、WinHTTP セッション、認証されたユーザー 1 人のまたは匿名ユーザー グループのインターネット アクティビティを管理するために使用されます。 ただし、WinHTTP ではこのマッピングが自動的に適用されないため、アプリケーションは、1 つの ID のみが関係していることを確認するための手順を実行する必要があります。
• WinHTTP 要求ハンドルに対する操作は同期する必要があります。 たとえば、アプリケーションは、別のスレッドが要求を送受信している間、1 つのスレッドで要求ハンドルを閉じないようにする必要があります。 非同期要求を終了するには、コールバック通知中に要求ハンドルを閉じます。 同期要求を終了するには、前の WinHTTP 呼び出しが返されたときにハンドルを閉じます。
• トレース ファイルには機密情報が含まれています。 トレース ファイルはアクセス制御リスト (ACL) を使用して保護されるため、通常、ローカル管理者またはトレース ファイルを作成したユーザー アカウントのみがアクセスできます。承認されていないアクセスによってトレース ファイルが侵害されないようにしてください。
• WinHttpSetOption を介した機密データの受け渡しは避けてください。 使用される認証スキームを制御できないと、機密データが予期せずクリア テキストで送信される可能性があるため、ユーザー名、パスワード、またはその他の資格情報を WinHttpSetOptionに提供しないでください。 資格情報の設定には、WinHttpSetOption の代わりに、WinHttpQueryAuthSchemes と WinHttpSetCredentials を使用します。
• 自動リダイレクトは、セキュリティ リスクを引き起こす可能性があります。 既定では、POST でもリダイレクト (302 メッセージ) が自動的に実行されます。 疑わしいリダイレクトの可能性を回避するために、機密情報を投稿するときに、アプリケーションでコールバックの自動リダイレクトを無効にするかリダイレクトを監視する必要があります。
• ユーザー定義ヘッダーは、変更されずにリダイレクト間で転送されます。 ユーザー定義ヘッダー (WinHTTPAddRequestHeaders を使用して追加された Cookie など) は、変更なしでリダイレクト間で転送されますが、WinHTTP によって生成されたヘッダーは自動的に更新されます。 リダイレクト間でユーザー定義ヘッダーを転送するとセキュリティ リスクが生じる場合は、 WINHTTP_STATUS_CALLBACK コールバックを WINHTTP_CALLBACK_STATUS_REDIRECT 完了と共に使用して、リダイレクトが発生するたびに問題のヘッダーを変更します。
• WinHTTP は同期モードでは再入できません。 WinHTTP は同期モードでは再入できないため、WinHTTP 関数内で実行されるアプリケーション スレッドで WinHTTP を呼び出すことができる非同期プロシージャ コール (APC) をスケジュールしないでください。 同期モードに設定している場合、WinHTTP は "警告可能な待機" を実行し、APC を実行するために待機中のスレッドへの割り込みが行われ、その後再び WinHTTP に入ると、WinHTTP の内部状態が破損する可能性があります。