![Каковы векторы атак для паролей, отправляемых по протоколу http?](https://rvso.com/image/515032/%D0%9A%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%20%D0%B2%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%8B%20%D0%B0%D1%82%D0%B0%D0%BA%20%D0%B4%D0%BB%D1%8F%20%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D0%B5%D0%B9%2C%20%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D0%BC%D1%8B%D1%85%20%D0%BF%D0%BE%20%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%83%20http%3F.png)
Я пытаюсь убедить клиента заплатить за SSL для веб-сайта, требующего входа. Я хочу убедиться, что правильно понимаю основные сценарии, в которых кто-то может увидеть отправляемые пароли.
Насколько я понимаю, на любом из остановок по пути можно использоватьанализатор пакетовчтобы просмотреть, что отправляется. Похоже, это требует, чтобы любой хакер (или его вредоносное ПО/ботнет) находился в той же подсети, что и любой из переходов, которые пакет совершает, чтобы достичь своего пункта назначения. Это верно?
Если предположить, что некоторые аспекты этого требования к подсети верны, мне нужно беспокоиться обо всех переходах или только о первом? О первом я, очевидно, могу беспокоиться, если они находятся в публичной сети Wi-Fi, поскольку кто угодно может их прослушивать. Стоит ли мне беспокоиться о том, что происходит в подсетях, по которым будут передаваться пакеты за пределами этой сети? Я не очень разбираюсь в сетевом трафике, но предполагаю, что он проходит через центры обработки данных крупных операторов, и там не так много перспективных векторов атак. Но, пожалуйста, поправьте меня, если я ошибаюсь.
Есть ли другие векторы, о которых следует беспокоиться, помимо прослушивания с помощью анализатора пакетов?
Я новичок в сетевых технологиях и безопасности, поэтому, пожалуйста, поправьте меня, если я использую неправильную терминологию.
решение1
Стоит отметить, что другие не упомянули здесь, что некоторые браузеры кэшируют данные вашей формы. Поведение по умолчанию на сайтах SSL обычно заключается в том, чтобы ничего не кэшировать, если вы не выбрали «сохранить мой пароль». Обычно поля паролей вообще не кэшируются, но я видел некоторые странности (обычно это касается информации о кредитной карте, которая, как я знаю, не является темой вопроса).
Другое, что следует отметить, это то, что SSL-шифрование начинается с TCP-рукопожатия. После SSL вы не сможете отличить HTTP через SSL от FTP через SSL (кроме предположений, сделанных через номер порта).
Вы также не сможете отличить запрос на вход в систему от запроса «Я просто просматриваю страницу», это скрывает поток страниц от потенциальных хакеров, а также гарантирует безопасность не только ваших паролей, но и истории просмотров / данных cookie и любой личной информации, связанной с вашей учетной записью.
В общем, если вы устранитечеловек посерединеатаки из спектра вы сокращаете множество потенциальных атак, но это не значит, что ваш сайт «безопасен». Также политика зонированиядолженпоможет защитить вас от XSS-атак, поскольку вам придется менять зону, если пользователь будет перенаправлен с вашего сайта.
решение2
Данные уязвимы на любом этапе маршрута, а не только на первом или последнем этапе. Вполне возможно, что система, участвующая в передаче, ищет имена пользователей, пароли и другие конфиденциальные данные. Из этого следует, что конфиденциальные данные должны передаваться только по каналу, который защищен на всем пути, и, конечно, именно для этого и нужен SSL. В зависимости от того, какие данные задействованы, вполне могут существовать местные законы, которые предписывают SSL.
решение3
Существуют прокси-серверы, которые могут хранить данные.
Но есть также обязательство хранить пароли пользователей в безопасности. Многие пользователи используют ограниченный набор паролей, поэтому небезопасный сайт может скомпрометировать их пароль Homebank, например.
решение4
Я могу согласиться с размышлениями KevinM по поводу ответов на его собственные вопросы, и Джон Гарденьерс указывает в правильном направлении. Я также должен согласиться с тем, что сказал silky, в "в идеале - широкая публика никогда не будет входить на сайт, на котором нет экрана входа на основе SSL", и указать, что это, однако, совсем не современный случай.
Я не согласен с тоном silky (вероятно, непреднамеренным), который приводит к повсеместному восприятию того, что «широкая общественность» глупа. Клиент KevinM явно не имеет понятия о необходимости SSL, и это ваш среднестатистический человек в двух словах. Они не глупые, они просто не знают. Сказать «тебе это нужно» означает получить ответ «Я прожил x лет без этого, и я проживу еще x лет просто отлично», или, возможно, даже худший ответ: «Ненавижу, когда мне говорят, что мне нужно». Так что будьте осторожны!
Ваше беспокойство обосновано, Кевин. Вашему клиенту действительно нужен SSL-сертификат. Я думаю, что ваша настоящая забота должна заключаться в том, как продать им один. Не только о входах пользователей следует беспокоиться, но и оадминистраториоператорлогины, которые также выиграли бы от защиты с помощью SSL.
Да, в этом отношении есть и другие вещи, о которых следует беспокоиться, даже более серьезные, чем перехват пакетов, например:XSS. Их много, ихорошо документированы.