Вопросы безопасности 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 функции должны выполняться повторно. При написании обратного вызова избегайте статических переменных или других конструкций, которые небезопасны при повторном вызове, и избегайте вызова других функций, которые не являются повторными.
• Если асинхронная операция возможна, передайте NULLs для параметров OUT. Если вы включили асинхронную операцию путем регистрации функции обратного вызова, всегда передайте значения NULL для таких параметров OUT, как lpdwDataAvailable для WinHttpQueryDataAvailable, lpdwBytesRead Для 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.
• Файлы трассировки содержат конфиденциальную информацию. Файлы трассировки защищены с помощью списков управления доступом (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 может быть повреждено.