SSL для входа, обычный http после этого ... Насколько уязвимы данные, передаваемые из базы данных?

Question

Я бродил по сайту по этому вопросу с помощью поисковой системы, и я не думаю, что он там. Если это так, заранее прошу прощения и не стесняйтесь указывать мне на это.

Вот мой сценарий:

Я настраиваю веб-приложение, Moodle, если кто-то с ним знаком, с Apache, MySQL и php в Windows. Moodle поддерживает включение SSL для входа в систему, но затем возвращается к обычному http после входа в систему. Это работает во внутренней сети без связи с внешним миром, поэтому нет доступа в Интернет через эту сеть. Все пользователи, использующие сеть, имеют логины, однако есть некоторые общие логины гостевого типа с определенными ограниченными привилегиями. В настоящее время база данных MySQL не зашифрована.

Мой вопрос такой:

Если мои пользователи выполняют вход в систему по протоколу SSL, а затем система возвращается к http для оставшейся части сеанса, насколько уязвимы данные, которые передаются назад и вперед между интерфейсом браузера и базой данных?

Возможно, я бы предпочел, чтобы все данные были зашифрованы, но я не уверен, насколько негативно это скажется на производительности, поэтому любые предложения по этому поводу также будут оценены. Хотя я буду расширять функциональность в Moodle, мне не обязательно менять его, чтобы шифровать все, если это уже сделано.

Я новичок в мире ИТ-безопасности, и мои навыки администратора базы данных ржавые, поэтому, если вы дадите мне ответ, печатайте медленно, чтобы я мог понять! ;)

Заранее спасибо! Карвелл

Answer 1

Меня беспокоит, как будут распространяться ваши аутентифицированные сеансы.

Обычно сеанс работает путем установки файла cookie или добавления идентификатора сеанса к любым URL-адресам, представленным веб-сайтом. Как только вход в систему установлен, часто учетные данные больше не нужны, поскольку сеанс затем связывается с пользователем и считается аутентифицированным, а само существование сеанса является доказательством успешной аутентификации.

Однако, как упоминалось ранее, местный сетевой трафик может быть доступен для прослушивания. Если кто-то прослушал идентификатор сеанса, он мог воссоздать cookie или URL-адреса, используя идентификатор сеанса, и просто получить доступ к сайту как пользователь сеанса, даже изменив пароль пользователя, если этот параметр был доступен.

Я бы сказал, что ваше решение здесь зависит от безопасности ваших сессий. Если у вас есть некоторые смягчающие факторы, которые затрудняют репликацию сеансов, даже если идентификатор сеанса скомпрометирован (например, сравнение с IP-адресами и т. Д.), Или ваши учетные записи пользователей относительно защищены от скомпрометированного сеанса (например, требуется текущий пароль изменить настройки учетной записи), то, возможно, SSL после входа в систему не требуется. Однако, если у вас есть сомнения и вы можете позволить себе снижение производительности, то наличие SSL на всем сайте гарантирует, что ваши сеансы не будут скомпрометированы (насколько вы можете гарантировать SSL в любом случае).

Answer 2

Несколько вещей.

1. Тот факт, что данные на сервере БД никоим образом не зашифрованы, является фактором связи между пользователем и веб-сервером. Это очевидно для связи между веб-сервером и сервером базы данных.

2. Ваша точка риска между пользователем и веб-сервером заключается в том, что пакеты можно было бы прослушать, если бы кто-нибудь смог выполнить их в середине коммуникационной цепочки. Однако этот риск снижается благодаря тому, что вы находитесь во внутренней сети.

Поэтому, если вы ОЧЕНЬ не обеспокоены другими людьми в вашей организации, вы, скорее всего, в порядке. Однако, если это действительно конфиденциальные данные, вы можете осуществлять ВСЕ коммуникации через SSL, чтобы обеспечить их безопасную передачу. Если вы обеспокоены этим, то я бы также посмотрел на безопасность БД и обмен данными между БД и веб-сервером.

Answer 3

Не так много, чтобы добавить к выше правильным ответам. Но одна вещь, которую вы можете сделать, это использовать Инструмент моделирования угроз для вашего приложения. Это сообщит вам о типах угроз, которым вы подвергаете свои данные, не используя шифрование транспортного уровня (TLS / SSL). После того, как вы поймете угрозы, вы сможете выбрать подходящий план по снижению рисков.

Answer 4

Любой в вашей сети сможет видеть трафик всех остальных с помощью анализатора сетевых пакетов, такого как WireShark. Соединение между вашим веб-сервером и MySQL также в открытом тексте. MySQL может не отправлять пароли в открытом виде; это может быть хеш, например.

Если вы действительно пытаетесь быть параноиком, вам может не понадобиться запускать ваше приложение по HTTPS. Есть и другие возможности более низкого уровня, такие как IPSec. Поскольку это внутренняя сеть, вы, вероятно, сможете реализовать ее на всех рабочих станциях.

Answer 5

Поскольку данные не зашифрованы, любой, имеющий достаточный доступ к сети (то есть физический доступ), может читать данные, передаваемые взад и вперед от сервера к браузеру и обратно. Если у каждого, кто имеет физический доступ к сети, есть разрешение на чтение данных, вы, вероятно, в порядке. Если какая-либо информация является конфиденциальной и должна ограничиваться просмотром группой людей, имеющих физический доступ к сети, вам необходимо зашифровать ее.

Answer 6

Все конфиденциальные данные должны быть зашифрованы при передаче по небезопасному проводу. Если вы просто передаете данные для входа через SSL, все ваши данные по-прежнему уязвимы для прослушивания.

Answer 7

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

Как минимум, вам следует зашифровать данные в вашей базе данных.

Answer 8

При отсутствии доступа к этой сети через Интернет единственное, что может произойти, - это кто-то еще (кто уже находится во внутренней сети) отслеживает HTTP-трафик другого пользователя. Если бы кто-то действительно сделал это, а вы не используете SSL, он мог бы прочитать все данные, которые ваш сайт отправляет / получает от этого пользователя. Но действительно ли это вызывает озабоченность?