CSRF атаки: что это такое и как с ними бороться?

На рубеже тысячелетия, всего несколько сайтов были «динамическими». Большинство из них содержат в основном статические html-файлы. С тех пор сеть превратилась в полную противоположность. На современных веб-сайтах часто используются скрипты на сервере и на стороне клиента, которые взаимодействуют в скрытой симфонии ajax (асинхронный Javascript и XML — акроним в аббревиатуре!). Это просто то, как работает веб-сайт — особенно Web 2.0

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

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

Я получил Spearfished

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

Ну, оказалось, что взлом был осуществлен, используя уязвимость CSRF Cross Site Request Forgery (произносится как морской прибой) в системе управления контентом. Раньше в тот же день я получил электронное письмо с поддельным адресом электронной почты, который якобы был у моего клиента. Он выглядел подлинным и содержал ссылку на веб-сайт, на который я нажал. В то время на открывшемся веб-сайте просто появилась пустая страница, и я ничего не думал об этом, закрыв окно браузера и продолжил свою работу, сделав заметку, чтобы потом спросить моего клиента об этом.

Оказалось, что я был копье-фишингом, которым был нацелен кто-то, кто знал, для кого я работаю, и отправил отравленное письмо.

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

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

Жертвы CSRF

Если вы еще не догадались, CSRF возникает, когда вы обманываете отправку запроса на веб-сайт, на который вы уже вошли (банк, социальные сети и т. Д.), Чтобы что-то сделать от имени злоумышленника. Все, что должен сделать злоумышленник, это обмануть вас в том, что вы делаете ложный запрос. Обычно это означает, что вы можете посетить фиктивный веб-сайт, содержащий вредоносный код.
Вы, должно быть, заметили клик-приманку «вы не поверите, что выходит из глазного яблока этого парня» на Facebook. Многие атаки основаны на легковерных / любопытных людях, которые слишком охотно видят что-то ужасное высказывание из чьей-то головы — так остерегайтесь в следующий раз, когда вас соблазнят эти виды ссылок.

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

Пользователи Facebook уже стали жертвами атак CSRF, и хотя Facebook значительно увеличил свою игру (хотя, возможно, и не полностью), в море больше рыбы (phish?).

Только за последние несколько недель уязвимости CSRF были зарегистрированы в популярном беспроводном маршрутизаторе, что потенциально подвергает беспроводные сети несанкционированному доступу. Проблема с уязвимостью CSRF заключается в том, что все время есть новые, ожидающие обнаружения.

Остановка CSRF

С точки зрения владельца веб-сайта одним из решений является создание одноразового маркера безопасности для внутренней ссылки на ваш сайт — этот токен затем принимается вместе с каждым запросом, так что ваше программное обеспечение веб-сайта может определить, что запрос был получен от уполномоченного источник. Это подход, предпринятый Facebook, но это не всегда практично — однако, защита самого веб-приложения не является фокусом моей статьи, а как защитить себя от небезопасных.

Чтобы понять, как защитить себя от атак CSRF, важно понять, как работает веб-аутентификация. Когда вы регистрируетесь в своем онлайн-банке, вы обычно отправляете имя пользователя и пароль (или, возможно, еще один коэффициент аутентификации из брелока, ключа и т. Д.). В ответ веб-сайт отправляет обратно файл cookie, содержащий криптографически защищенный токен (надеюсь), идентифицирующий ваше соединение как который уже прошел проверку подлинности.

HTTP, язык в Интернете, является апатридом — поэтому этот файл cookie избавляет вас от необходимости повторной аутентификации при каждом посещении другой страницы в вашем банке.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *