Вопросы безопасности WinHTTP

К приложениям, используюющим WinHTTP, применяются следующие рекомендации по безопасности:

• Сертификаты сервера проверяются только один раз за сеанс. После проверки сертификат остается действительным в течение текущего сеанса. Пока отпечаток сертификата совпадает, что указывает на то, что сертификат не изменился, сертификат будет проверяться повторно. В результате любое изменение критериев проверки с помощью флагов протокола, проверка отзыва или игнорирования ошибки сертификата не вступают в силу после проверки сертификата. Чтобы такое изменение вступило в силу немедленно, необходимо завершить текущую сессию и начать новую. Аналогичным образом, истечение срока действия сертификата в ходе сеанса может быть обнаружено только в том случае, если само приложение периодически проверяет сервер сертификатов для получения данных об истечении срока действия.
• Автоматический прокси-сервер включает загрузку и выполнение скриптов. Поддержка автоматического обнаружения прокси-серверов включает обнаружение через DHCP или DNS, загрузку и выполнение скриптов прокси-сервера, таких как скрипты Java. Чтобы обеспечить более высокий уровень безопасности, приложение должно избегать передачи флага WINHTTP_AUTOPROXY_RUN_INPROCESS , чтобы автоматическое обнаружение прокси-сервера было инициировано вне процесса. Даже в этом случае WinHTTP пытается по умолчанию запустить скрипт с автоматическим прокси-сервером в процессе, если скрипт не удается правильно запустить вне процесса. Если вы считаете, что такое резервное поведение представляет неприемлемый риск, отключите его с помощью флага WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY .
• WINHTTP_STATUS_CALLBACK функции должны быстро возвращаться. При написании одной из этих функций обратного вызова следует соблюдать осторожность, чтобы она не блокироваться. Например, ни обратный вызов, ни вызываемая функция не должны отображать диалоговое окно пользователя или ждать события. Если функция WINHTTP_STATUS_CALLBACK блокируется, это влияет на внутреннее планирование WinHTTP и приводит к отказу в обслуживании других запросов в том же процессе.
• WINHTTP_STATUS_CALLBACK функции должны быть повторно вошли. При написании обратного вызова избегайте статических переменных или других конструкций, которые являются небезопасными при повторном вводе, и избегайте вызова других функций, которые не являются повторными.
• Если асинхронная операция возможна, передайте значения NULL для параметров OUT. Если вы включили асинхронную операцию, зарегистрировав функцию обратного вызова, всегда передайте значения NULL для таких параметров OUT, как lpdwDataAvailable для WinHttpQueryDataAvailable, lpdwBytesReadReadдля WinHttpReadData или lpdwBytesWritten для WinHttpWriteData. В некоторых случаях вызывающий поток завершается до завершения операции, и если параметры OUT не имеют значения NULL, функция может в конечном итоге записывать данные в память, которая уже была освобождена.
• Проверка подлинности по паспорту не является надежной. Любая схема проверки подлинности на основе файлов cookie уязвима для атак. Passport версии 1.4 основан на файлах cookie и, следовательно, подвержен уязвимостям, связанным с любой схемой проверки подлинности на основе файлов cookie или форм. Поддержка паспортов отключена по умолчанию в WinHTTP; Его можно включить с помощью WinHttpSetOption.
• Обычная проверка подлинности должна использоваться только при безопасном подключении. Обычная проверка подлинности, которая отправляет имя пользователя и пароль в виде ясного текста (см. RFC 2617), должна использоваться только для зашифрованных подключений SSL или TLS.
• Установка политики автоматического входа в режим "низкий" может представлять риск. Если политика автоматического входа имеет низкий уровень, учетные данные пользователя можно использовать для проверки подлинности на любом сайте. Однако не рекомендуется выполнять проверку подлинности на сайтах, которым вы не доверяете.
• Подключения SSL 2.0 не используются, если они не включены явным образом. Протоколы безопасности TLS 1.0 и SSL 3.0 считаются более безопасными, чем SSL 2.0. По умолчанию WinHTTP запрашивает TLS 1.0 или SSL 3.0 при согласовании SSL-подключения, а не SSL 2.0. Поддержку SSL 2.0 в WinHTTP можно включить только путем вызова WinHttpSetOption.
• Проверка отзыва сертификатов должна быть запрошена явным образом. По умолчанию при проверке подлинности на основе сертификата WinHTTP не проверка, был ли отозван сертификат сервера. Проверку отзыва сертификатов можно включить с помощью WinHttpSetOption.
• Приложения должны гарантировать, что сеанс сопоставляется с одним удостоверением. Сеанс WinHTTP должен сопоставляться только с одним удостоверением; то есть сеанс WinHTTP используется для управления действиями одного прошедшего проверку подлинности пользователя или группы анонимных пользователей в Интернете. Но так как WinHTTP не применяет это сопоставление автоматически, приложение должно принять меры, чтобы обеспечить использование только одного удостоверения.
• Операции с дескриптором запроса WinHTTP должны быть синхронизированы. Например, приложение не должно закрывать дескриптор запроса в одном потоке, пока другой поток отправляет или получает запрос. Чтобы завершить асинхронный запрос, закройте дескриптор запроса во время уведомления обратного вызова. Чтобы завершить синхронный запрос, закройте дескриптор при возврате предыдущего вызова WinHTTP.
• Файлы трассировки содержат конфиденциальную информацию. Файлы трассировки защищаются с помощью списков Access-Control (ACL), поэтому доступ к ним обычно может получить только локальный администратор или учетная запись пользователя, создавшего его. Избегайте компрометации файлов трассировки при несанкционированном доступе.
• Избегайте передачи конфиденциальных данных черезWinHttpSetOption. Не указывайте имя пользователя, пароль или другие учетные данные в WinHttpSetOption , так как у вас нет контроля над используемой схемой проверки подлинности и конфиденциальные данные могут неожиданно отправляться в виде открытого текста. Для настройки учетных данных используйте WinHttpQueryAuthSchemes и WinHttpSetCredentials вместо WinHttpSetOption .
• Автоматическое перенаправление может представлять угрозу безопасности. По умолчанию перенаправление (сообщение 302) выполняется автоматически даже для POST. Чтобы избежать вероятности фиктивных перенаправлений, приложения должны отключить автоматическое перенаправление или отслеживать повторное направление в обратных вызовах при публикации конфиденциальной информации.
• Определяемые пользователем заголовки передаются по перенаправлениям без изменений. Определяемые пользователем заголовки, такие как файлы cookie, добавленные с помощью WinHTTPAddRequestHeaders, передаются через перенаправления без изменения, а заголовки, созданные WinHTTP, обновляются автоматически. Если передача определяемого пользователем заголовка между перенаправлениями представляет угрозу безопасности, используйте обратный вызов WINHTTP_STATUS_CALLBACK с завершением WINHTTP_CALLBACK_STATUS_REDIRECT , чтобы изменить рассматриваемый заголовок при каждом перенаправлении.
• WinHTTP не повторно входит в синхронном режиме. Так как WinHTTP не повторно входит в синхронном режиме, не следует планировать асинхронные вызовы процедур (APC), которые могут вызывать WinHTTP в потоке приложения, который выполняется внутри функции WinHTTP. В синхронном режиме WinHTTP выполняет "оповещенное ожидание", и если ожидающий поток предварительно выполняет APC, а затем снова входит в WinHTTP, внутреннее состояние WinHTTP может быть повреждено.