Security

Какие существуют векторы атак на пароли, передаваемые по http?

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

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

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

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

Ответ 1

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

Еще одна вещь, которую следует отметить, это то, что SSL шифрование начинается с TCP квитирования. Попав под SSL, вы не сможете отличить HTTP по SSL от FTP по SSL (кроме предположений, сделанных по номеру порта). Вы также не сможете отличить запрос на вход в систему от запроса «Я просто просматриваю». Это позволяет скрыть поток страниц от потенциальных хакеров, а также гарантирует безопасность не только ваших данных пароля, но и истории просмотров, данных cookie и любой другой личной информации, связанной с вашей учетной записью. В целом, если вы исключите атаки типа «человек посередине» из спектра, вы сократите количество потенциальных атак, но это не означает, что ваш сайт «безопасен». Также политика зонирования должна помочь защитить вас от XSS-атак, поскольку вы будете производить смену зоны, если пользователь будет перенаправлен с вашего сайта.

Ответ 2

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

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

Ответ 3

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

Но использование HTTP для простого текста это все равно, что пригласить даже начинающих n/w детей подсмотреть пароли.

Ответ 4

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

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

Схожие статьи

Киберпреступления в банковской сфере: самые известные случаи
Security

Киберпреступления в банковской сфере: самые известные случаи

SOAP: система безопасности и персонализации, службы каталогов
Security

SOAP: система безопасности и персонализации, службы каталогов

Security

Нужен ли моему администратору баз данных Oracle root-доступ?

Security

Насколько полезен mounting/tmp noexec?

×