Восемь «забавных» вещей, которые могут с вами произойти, если у вас нет защиты от CSRF-атак

Введение

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

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

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

В этом заключается суть подделки межсайтовых запросов (CSRF). Если злоумышленник может заманить вашего пользователя на свой вебсайт, пока этот пользователь авторизован на вашем сайте, злоумышленник может подделывать запросы на ваш сайт, используя идентификационные данные такого пользователя. То есть теоретически злоумышленник может активировать любые функции, доступные этому пользователю. И хотя большинство браузеров и серверов учитывают такую возможность, готовые решения по снижению рисков не являются абсолютно надежными. Именно авторы приложений отвечают за то, чтобы обрабатывались только предполагаемые запросы.

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

Однако с помощью CSRF-уязвимостей умный злоумышленник может сделать очень многое. Вот восемь очевидных действий для разных ситуаций:

1. Сделать слепой произвольный запрос по любому маршруту в качестве пользователя

В общем-то, это неинтересная и абстрактная угроза. И все же посмотрите на любое веб-приложение. Ведь непременно должно быть что-то неприятное, что можно сделать с помощью CSRF? Например, отправить компрометирующее сообщение от лица незадачливого пользователя или забронировать кому-нибудь билеты на рейс в Таджикистан? А если жертвой является администратор, возможно, злоумышленники могут присвоить себе статус привилегированного пользователя?

2. Сделать запрос и узнать его продолжительность

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

Однако никто серьезно не защищается от атак по времени, скажем, при поиске. Например, предположим, что у вас есть сайт службы знакомств, а злоумышленник делает запрос через браузер жертвы, скажем, Сары, по маршрутам messages/search?query=kevin%20mitchell и messages/search?query=blurghafest. Если достоверно известно, что первый запрос занимает больше времени, чем второй (причем необязательно намного), может пролиться кровь. Или, как минимум, где-то далеко произойдет неприятность и появится недовольный клиент.

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

3. Заставить пользователя выйти из системы

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

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

4. Заставить пользователя выйти из системы и снова войти

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

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

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

5. Изменить адрес электронной почты пользователя и запросить восстановление пароля

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

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

6. Превратить уязвимость Self-XSS в XSS

CSRF-атака может превратить уязвимость self-XSS, которая является мелкой проблемой, в XSS, которая является огромной проблемой.

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

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

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

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

К сожалению, в системе также отсутствовала защита от CSRF-атак, следовательно, злоумышленник мог бы вставить скрипт Javascript на страницах с описанием курса с помощью CSRF: Надо всего лишь попросить любого преподавателя проверить вашу курсовую и можно быть уверенным, что и преподаватель, и злоумышленник вошли в систему и просматривают страницу с вашей вредоносной CSRF-страницей. Затем в течение 20 миллисекунд вы можете пройти все курсы с высшим баллом.

7. Замести следы

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

Если пользователь не обладает по-настоящему глубоким пониманием, он никогда не узнает, откуда пришел этот CSRF-удар.

8. Распространять вредоносное ПО

Позволяет ли ваш сервис пользователям хранить файлы? Многие типы файлов, такие как .docx, pdf, jpeg и другие исторически используются для сокрытия вредоносного ПО из-за багов программ, которые их читают.

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

Заключительные замечания

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