Руководство по HTTP. Безопасность.

HTTP широко используется для передачи данных по сети Интернет, поэтому разработчики, провайдеры и пользователи должны быть знакомы с ограничениями HTTP/1.1, которые связаны с безопасностью.


Утечка личной информации

Часто, клиенты HTTP хотят скрыть различные личные данные, такие как имя, местоположение, пароль, кодировку, email и т.д. Поэтому мы должны быть крайне осторожны с целью предотвращения утечки данной информации при работе с протоколом HTTP.

  • Вся секретная информация должна храниться на сервере в закодированной форме.
  • Прокси, которые используются как портал, через защитную систему сети, должны принимать меры предосторожности, касающиеся передачи заголовков, определяющих хосты за защитной системой.
  • Раскрытие версий специфичного ПО сервера может сделать сервер подверженным атакам.
  • Информация, которая передаётся через поле “From” может конфликтовать с личными интересами пользователей или их политикой безопасности. Она не должна передаваться без возможности активации или деактивации пользователем.
  • Клиент не должен включать поле заголовка “Referer” в небезопасные запросы HTTP, в случае, если страница, на которую ссылаются, была передана через безопасный протокол.
  • Авторы сервисов, которые используют протокол HTTP не должны использовать формы, основанные на GET для подтверждения важных данных, так как это может стать причиной кодирования данных в Request-URI.

Атаки, основанные на именах файлов и путях

Документирование должно быть ограничено документами, которые возвращаются HTTP запросами и должны быть доступны только администраторам.

Например, такие операционные системы, как Windows или UNIX используют “..” как компонент, указывающий уровень директории над текущим положением. На таких системах протокол HTTP должен запретить такие конструкции в запросах Request-URI. Но позволять доступ к ресурсам, которые должны быть доступны через HTTP сервер.


Аутентификация

Обычно, существующие HTTP клиенты и агенты пользователей сохраняют информацию об аутентификации на неопределённый срок. HTTP не предоставляет средств для того, чтобы удалить эти данные, что является большим риском для безопасности.

Существует ряд проблем, связанных с этим аспектом, поэтому настоятельно рекомендуется использовать защиту паролей в screen savers, устанавливать время тайм-аута на ноль и т.д.


Прокси и Кэширование

HTTP прокси дают возможность для атаки на сервер, так как они имеют доступ к информации, касающейся безопасности, личным данным и т.д.

Операции с прокси должны защищать систему  на которой они выполняются.

Прокси кэширования являются причиной дополнительной подверженности атакам. Так как содержимое кэша является привлекательной целью для заинтересованных лиц. Именно поэтому кэш должен быть надёжно защищён.

На этом мы заканчиваем обсуждение безопасности при работе с HTTP.

В следующей статье мы рассмотрим примеры HTTP сообщений.