Во времена Британской империи у англичан возникла маленькая проблема на Индийском субконтиненте — кобры. Оказалось, что повсюду чертовски много этих рептилий. А ещё выяснилось, что они ядовиты. Это не нравилось колонистам, некоторые из них умирали. Поэтому британские власти придумали отличный выход. За каждую убитую кобру индийским туземцам стали выплачивать небольшое вознаграждение. Казалось бы, проблема решена.
К сожалению, индусы иначе интерпретировали условия выплаты вознаграждений. Они посчитали это отличной причиной, чтобы разводить ядовитых змей и сдавать их за деньги. Осознав проблему в изначальной логике, британские власти отменили выплату вознаграждений. Ну, а индийцам ничего не оставалось, кроме как выпустить огромное количество кобр на свободу. В результате, их количество в индийских лесах выросло многократно.
Оттуда пошло выражение эффект кобры. Ситуация, когда принятое для исправления проблемы решение не исправляет эту проблему, а ведёт к прямо противоположному результату.
Об эффекте кобры приходится вспоминать, глядя на некоторые меры безопасности, которые реализуются для защиты пользователей на отдельных сайтах. Например, сайты заставляют использовать пароли со специальными символами и цифрами, тем самым отсекая максимально надёжные парольные фразы 40-50 символов с наибольшей энтропией. Или ещё более странная «мера безопасности» — запрет на копипаст в поле ввода пароля.
Запрет на копипаст в поле ввода пароля
Судя по всему, таким способом сайт защищается от хакеров, которые копипастом вставляют чужие пароли из базы с украденными паролями.
Объяснение несуразное, но в реальности многие сайты уже запретили копипаст в поле ввода пароля. Например, на сайтах GE Capital невозможно скопировать пароль в поле ввода при авторизации. Разумеется, это сделано для безопасности. Но пользователям не объясняются причины. Не появляется никаких сообщений «Ради вашей безопасности» или тому подобных. Пароль просто исчезает.
На сайте PayPal аналогичная блокировка действует на странице изменения пароля (кстати, вместе с драконовским и совершенно ненужным ограничением на длину пароля в 20 символов).
Ну здесь хотя бы объясняют, ради чего всё затеяно.
Самое интересное, что блокировка ввода пароля часто реализована с помощью onpaste — нестандартного ивента, которое когда-то придумала компания Microsoft для своего браузера Internet Explorer.
<input type="password" name="j_password" class="DataPasive"
maxlength="14" size="23" onkeypress="return logonWithEnter(event)"
autocomplete="off" onpaste="return false">Удивительно, но этот нестандартный ивент до сих пор работает, причём не только в Internet Explorer, но ещё и в Chrome, и в Safari, и в Firefox. Да и если бы он не работал, есть другие светлые идеи, как «хакнуть» функциональность Ctrl+V (Shift+Ins) в браузерах.
Такая «защита от хакеров» просто абсурдна, считает известный специалист по безопасности Трой Хант (Troy Hunt), потому что единственный по-настоящему безопасный пароль — это такой, который вы не можете запомнить (без учёта длинных парольных фраз, которые и так заблокированы другими парольными ограничениями). Соответственно, для генерации пароля с максимальной энтропией лучше использовать специализированные генераторы паролей и парольные менеджеры вроде 1Password, KeePass или LastPass. Смысл в том, что вы делегируете функцию «запоминания» пароля своему парольному менеджеру, а десятки сгенерированных уникальных паролей храните в надёжном месте под защитой одного мастер-пароля.
Запрещая копипаст пароля, сайты фактически пытаются помешать использованию парольных менеджеров, то есть де-факто они снижают уровень безопасности пользователей (хотя некоторые парольные менеджеры умеют обходить такую блокировку копипаста).
Кейлоггер eBay
Ещё один интересный пример, как сайты заботятся о безопасности своих пользователей — функция кейлоггера в форме переустановки пароля на сайте eBay.
В консоли браузера можно убедиться, что при вводе пароля браузер отправляет десятки POST-запросов на серверы eBay.
Хорошо ещё, что кейлоггер работает по HTTPS.
При каждом нажатии клавиши в окне ввода пароля отправляется запрос. Судя по тому, что они уходят на /PWDStrength, можно предположить, что таким своеобразным образом работает модуль проверки надёжности пароля, который оценивает его энтропию и сообщает пользователю результат: «хороший» у него пароль или «плохой».
В принципе, этот JavaScript-модуль обычно работает на стороне клиента, и тогда необходимость в таком кейлоггере и POST-запросах на каждое нажатие клавиш отпала бы.
Вот что совершенно непонятно — так это зачем с каждым POST-запросом на каждое нажатие клавиш в тело POST добавляется имя пользователя и адрес электронной почты.
В принципе, такой кейлоггер не очень опасен, ведь вся информация отправляется по защищённому соединению HTTPS, хотя как-то странно чувствовать, что с каждым нажатием отправляется запрос с твоим адресом электронной почты и именем пользователя.
В компании eBay действует программа выплаты вознаграждений за найденные уязвимости. Когда один из хакеров сообщил о баге, сотрудник компании прислал официальный ответ:
Здравствуйте, Дэвид!
Спасибо за ваше письмо. Есть некоторые причины, из-за которых работает текущая реализация, но я не смогу предоставить вам дополнительную информацию об этом.
Спасибо,
eBay Security Research
Остаётся только догадываться о причинах, зачем с каждым символом передавать адрес электронной почты.
Но это ладно. Хуже другое: в некоторых других местах на сайте eBay при смене пароля кейлоггер отправляет уже не POST-запросы, а GET-запросы на каждое нажатие клавиши.
Хотя здесь в теле запроса нет адреса электронной почты и имени пользователя, но это уже опаснее, потому что GET-запросы могут кэшироваться на прокси-серверах и сохраняются в логах.
В общем, разработчикам всегда желательно помнить об опыте британских колонизаторов в Индии — они тоже хотели как лучше…
Автор: alizar
