HTTP используется для связи через Интернет, поэтому разработчики приложений, поставщики информации и пользователи должны знать об ограничениях безопасности в HTTP / 1.1. Это обсуждение не включает в себя окончательное решение проблем, упомянутых здесь, но оно предлагает некоторые предложения по снижению рисков для безопасности.
Утечка личной информации
HTTP-клиенты часто получают доступ к большому количеству личной информации, такой как имя пользователя, местоположение, почтовый адрес, пароли, ключи шифрования и т. Д. Поэтому вы должны быть очень осторожны, чтобы предотвратить непреднамеренную утечку этой информации через протокол HTTP в другие источники.
-
Вся конфиденциальная информация должна храниться на сервере в зашифрованном виде.
-
Раскрытие конкретной версии программного обеспечения сервера может позволить серверной машине стать более уязвимой для атак на программное обеспечение, которое, как известно, содержит дыры в безопасности.
-
Прокси, которые служат порталом через сетевой брандмауэр, должны принимать особые меры предосторожности в отношении передачи информации заголовка, которая идентифицирует хосты за брандмауэром.
-
Информация, отправляемая в поле «От», может противоречить интересам пользователя в отношении конфиденциальности или политике безопасности их сайта, и, следовательно, ее не следует передавать без возможности отключить, включить и изменить содержимое поля.
-
Клиенты не должны включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.
-
Авторам сервисов, которые используют протокол HTTP, не следует использовать формы на основе GET для представления конфиденциальных данных, поскольку это приведет к тому, что данные будут закодированы в Request-URI.
Вся конфиденциальная информация должна храниться на сервере в зашифрованном виде.
Раскрытие конкретной версии программного обеспечения сервера может позволить серверной машине стать более уязвимой для атак на программное обеспечение, которое, как известно, содержит дыры в безопасности.
Прокси, которые служат порталом через сетевой брандмауэр, должны принимать особые меры предосторожности в отношении передачи информации заголовка, которая идентифицирует хосты за брандмауэром.
Информация, отправляемая в поле «От», может противоречить интересам пользователя в отношении конфиденциальности или политике безопасности их сайта, и, следовательно, ее не следует передавать без возможности отключить, включить и изменить содержимое поля.
Клиенты не должны включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.
Авторам сервисов, которые используют протокол HTTP, не следует использовать формы на основе GET для представления конфиденциальных данных, поскольку это приведет к тому, что данные будут закодированы в Request-URI.
Атака на основе имен файлов и путей
Документ должен быть ограничен документами, возвращаемыми по HTTP-запросам, чтобы они были только теми, которые были предназначены администраторами сервера.
Например, UNIX, Microsoft Windows и другие операционные системы используют «..» в качестве компонента пути, чтобы указать уровень каталога выше текущего. В такой системе HTTP-сервер ДОЛЖЕН запретить любую такую конструкцию в Request-URI, если в противном случае он разрешил бы доступ к ресурсу, который не предназначен для доступа через HTTP-сервер.
DNS спуфинг
Клиенты, использующие HTTP, в значительной степени зависят от службы доменных имен и, таким образом, обычно подвержены атакам безопасности, основанным на преднамеренной неправильной ассоциации IP-адресов и DNS-имен. Таким образом, клиенты должны быть осторожны, предполагая, что IP-адрес / DNS-имя сохраняются.
Если клиенты HTTP кэшируют результаты поиска имен хостов, чтобы добиться улучшения производительности, они должны наблюдать информацию TTL, сообщаемую DNS. Если клиенты HTTP не соблюдают это правило, они могут быть подделаны при изменении IP-адреса ранее посещенного сервера.
Расположение заголовков и спуфинг
Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, он ДОЛЖЕН проверить значения заголовков Location и Content Location в ответах, которые сгенерированы под управлением указанных организаций, чтобы убедиться, что они не пытаются сделать недействительными ресурсы которые они не имеют никаких полномочий.
Учетные данные аутентификации
Существующие HTTP-клиенты и пользовательские агенты обычно сохраняют информацию аутентификации на неопределенный срок. HTTP / 1.1 не предоставляет серверу способ направить клиентов на сброс этих кэшированных учетных данных, что является большой угрозой безопасности.
Существует несколько способов решения этой проблемы, поэтому рекомендуется использовать защиту паролем в хранителях экрана, тайм-аутах простоя и других методах, которые уменьшают проблемы безопасности, присущие этой проблеме.
Прокси и кеширование
Прокси-серверы HTTP — это «люди посередине» и предоставляют возможность для атак «человек посередине». Прокси имеют доступ к информации, связанной с безопасностью, личной информации об отдельных пользователях и организациях, а также конфиденциальной информации, принадлежащей пользователям и поставщикам контента.
Прокси-операторы должны защищать системы, в которых работают прокси, так как они будут защищать любую систему, которая содержит или транспортирует конфиденциальную информацию.
Кэширующие прокси предоставляют дополнительные потенциальные уязвимости, так как содержимое кэша представляет собой привлекательную цель для злонамеренной эксплуатации. Поэтому содержимое кэша должно быть защищено как конфиденциальная информация.