HTTP - Безопасность
HTTP используется для связи через Интернет, поэтому разработчики приложений, поставщики информации и пользователи должны знать об ограничениях безопасности в HTTP / 1.1. Это обсуждение не включает окончательных решений упомянутых здесь проблем, но дает некоторые предложения по снижению рисков безопасности.
Утечка личной информации
HTTP-клиенты часто имеют доступ к большому количеству личной информации, такой как имя пользователя, местоположение, почтовый адрес, пароли, ключи шифрования и т. Д. Поэтому вы должны быть очень осторожны, чтобы предотвратить непреднамеренную утечку этой информации через HTTP-протокол в другие источники.
Вся конфиденциальная информация должна храниться на сервере в зашифрованном виде.
Выявление конкретной версии программного обеспечения сервера может сделать серверный компьютер более уязвимым для атак на программное обеспечение, которое, как известно, содержит бреши в безопасности.
Прокси-серверы, которые служат порталом через сетевой брандмауэр, должны принимать особые меры предосторожности в отношении передачи информации заголовка, которая идентифицирует хосты за брандмауэром.
Информация, отправляемая в поле «От», может конфликтовать с интересами конфиденциальности пользователя или политикой безопасности их сайта, и, следовательно, ее не следует передавать, если пользователь не сможет отключить, включить или изменить содержимое поля.
Клиенты не должны включать поле заголовка 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-прокси - это люди посередине, и они представляют собой возможность для атак типа «человек посередине». Прокси-серверы имеют доступ к информации, связанной с безопасностью, личной информации об отдельных пользователях и организациях, а также частной информации, принадлежащей пользователям и поставщикам контента.
Операторы прокси должны защищать системы, на которых работают прокси, так же, как они будут защищать любую систему, которая содержит или передает конфиденциальную информацию.
Кэширующие прокси-серверы предоставляют дополнительные потенциальные уязвимости, поскольку содержимое кеша представляет собой привлекательную цель для злонамеренного использования. Следовательно, содержимое кеша следует защищать как конфиденциальную информацию.