Назад | Перейти на главную страницу

Каковы направления атаки паролей, отправляемых через http?

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

Насколько я понимаю, на любом из прыжков по пути можно использовать анализатор пакетов для просмотра того, что отправляется. Похоже, для этого требуется, чтобы любой хакер (или его вредоносное ПО / бот-сеть) находился в той же подсети, что и любой из переходов, по которым пакет достигает места назначения. Это правильно?

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

Есть ли другие векторы, о которых следует беспокоиться, помимо тех, кто слушает с помощью анализатора пакетов?

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

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

Следует отметить, что другие не упомянули здесь, что некоторые браузеры кэшируют данные вашей формы. По умолчанию на сайтах SSL ничего не кэшируется, если вы не выбрали «сохранить мой пароль». Обычно поля пароля все равно не кешируются, но я видел некоторые странности (обычно информация о кредитной карте, которая, как я знаю, на самом деле не является темой вопроса).

Также следует отметить, что шифрование SSL начинается с установления связи TCP. Находясь под SSL, вы не можете отличить HTTP через SSL от FTP через SSL (кроме предположений, сделанных через номер порта).

Вы также не можете отличить запрос на вход в систему от запроса «Я просто просматриваю», это скрывает поток страниц от потенциальных хакеров, а также гарантирует, что не только ваши пароли в безопасности, но и ваша история просмотров / данные cookie / и все личная информация, связанная с вашей учетной записью.

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

Есть прокси-серверы, которые могут хранить данные.

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

Я могу согласиться с размышлениями KevinM относительно ответа на его собственные вопросы, и Джон Гарденир указывает правильное направление. Я также должен согласиться с тем, что сказал шелковистый: «в идеале - широкая публика никогда не будет входить на сайт, на котором нет экрана входа на основе SSL», и указать, что это, однако, не современный случай. вообще.

Я не согласен с тоном шелковистого (вероятно, непреднамеренным), который ведет к повсеместному мнению, что "широкая публика" - это глупо. Клиент KevinM явно не понимает необходимости SSL, и это в двух словах ваш средний человек. Они не глупы, они просто не знают. Сказать "вам это нужно" приведет к незаконному ответу "Я прожил x лет без этого, и я проживу еще x просто отлично" или, возможно, даже хуже, "я ненавижу, когда мне говорят, что мне нужно. . " Так что будьте осторожны!

Ваше беспокойство законно, Кевин. Вашему клиенту нужен сертификат SSL. Я думаю, ваша настоящая забота должна заключаться в том, как продать им один. Следует беспокоиться не только о логинах пользователей, но и о администратор и оператор логины, которые также выиграют от защиты SSL.

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

Ваш анализ разумен, ИМХО.

Я полагаю, что следует отметить, что на вашем пути могут быть кеши. Так что, возможно, запрос где-то регистрируется (особенно, если вход в систему завершен GET, что было бы ужасно).

Вероятно, следует учитывать то, что большая часть доступа к сети происходит в области, где есть много других людей в той же сети. Работа / Университет / Школа - главные примеры. Дома вы можете утверждать, что это менее рискованно, потому что вам нужно беспокоиться только о путях вверх.

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

Но давайте будем реалистами. Почти наверняка этот вектор атаки не приведет к компрометации его системы или пользователей.

HTH.

на всем маршруте, за которым следует пакет, если его можно прослушать через HTTP и можно увидеть данные ... даже если вы используете HTTP в прокси, например TOR ... используя сбор-атаку и т. д. можно обмануть прокси для утечки пакетов данных ... поэтому, если есть что-то близкое к конфиденциальному (пароли, личные данные, личные изображения и т. д.) ... это подходит только для передачи их через HTTPS.

Это тоже, даже HTTPS уязвим из-за неправильной реализации, и к нему применимы несколько SSL-атак ... тем не менее, их можно избежать при тщательной реализации.

Но использовать HTTP для простого текста - все равно что приглашать даже новичков, н / б, вынюхивать пароли.