Множественные CSRF уязвимости в крупнейших порталах Рунета

Простите мне заголовок в стиле Securitylab, но факт остается фактом.

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

Т.к. уязвимости ещё рабочие, я напишу только где их нашёл и как их можно использовать. Через неделю обещаю выложить работающие примеры для чайников — чтобы воспользоваться смогли школьники и домохозяйки. Кто не спрятался — я не виноват.

Нагнетаю интригу: я искал уязвимости в Яндексе, Рамблере, Mail.ru, Вконтакте, ЖЖ и на других популярных ресурсах. Если не терпится узнать где и какие уязвимости я нашел — сразу переходите к разделу «Список уязвимостей».

Для понимания обнаруженных уязвимостей понадобятся хотя бы базовые знания о том, что такое CSRF. Если их нет — не расстраивайтесь, ниже я попробовал доступно это объснить (правда, по-моему, не получилось). Если вы и так в курсе, что это такое, или же наоборот, не собираетесь в этом разбираться — смело переходите к результатам моего поверхностного аудита.

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

UPD: главный разработчие Liveinternet.ru не верит в существование CSRF. Раскрываю его уязвимости раньше обещанной недели. Здесь пример использования. Будьте внимательны, если у вас есть аккаунт в LiRu.

UPD 2: Работа уязвимости продемонстрирована, пример пока убрал.

UPD 3: Неделя прошла. Выкладываю работающие/работавшие примеры. Времени мало, поэтому пока не проверяю, что работает, а что нет. Буду признателен, если отпишете об этом в комментариях. Все вопросы, пожелания, предложения — в ответах к этому комментарию.
Рамблер, Mail.Ru, Liveinternet, Яндекс


Что такое CSRF?


Для выполнения каких-либо действий с Web приложением пользователи отправляют HTTP запросы. Для того, чтобы определить, от имени какого пользователя выполняется действие, обычно используются сессии, данные о которых хранятся в Cookie. Сервер получает запрос, смотрит Cookie, убеждается в том, что сессия связанная с данными Cookie существует и выполняет действие от имени пользователя, связанного с этой сессией. Для того, чтобы пользователь мог оставаться залогиненым на своем любимом ресурсе, браузеры автоматически отправляют Cookie тому серверу, который их установил. Таким образом, если из браузера пользователя отправить запрос, то вместе с ним отправятся и Cookie. И сервер будет думать, что имеет дело с залогиненым пользователем ресурса и действия выполнит от его имени. А заставить браузер отправить запрос можно и со сторонней страницы. И если сервер такие запросы будет обрабатывать так же, как и запросы со своих страниц — это и есть уязвимость.

Как воспользоваться?


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

Чтобы удалить свой профиль из популярной социальной сети Васе нужно кликнуть по ссылке «Удалить профиль», которая ведет на страницу http://vulnerable.site/delete_profile.php?sure=yes. Петя размещает на своей странице картинку, которая должна загружаться по этому адресу (понятное дело, что никакой картинки по этому адресу нет, но браузер заранее этого не знает). Когда Вася заходит на страницу Пети, браузер Васи пытается загрузить эту картинку. Картинки он не находит и успокаивается. Но популярная социальная сеть получила от имени Васи команду удалить профиль. И профиль Васи был благополучно удален. Возможно вам все равно непонятно — поменяйте Васю и Петю на Alice и Bob и прочитайте еще раз. От этих Васи с Петей всегда сплошная путаница.

Итак, для использования придется заманить пользователя на собственноручно созданную страницу (или же на страницу с XSS, на которой через XSS размещен ваш код — но для данной статьи разницы нет). На этой странице должно быть что-то, что отправит запрос. Самый простой способ — разместить картинку:

<img src="http://vulnerable.site/delete_profile.php?sure=yes"/>

Можно взломать популярный блог и разместить там скрытый iframe — результат будет потрясающим.

А в моём приложении все действия выполняются через POST запросы

Почему-то многие разработчики уверены, что невозможно воспользоваться CSRF уязвимостью, требующей отправки POST запроса. Обычно они мотивируют это тем, что через JS нельзя отправить POST запрос на другой домен. Это действительно так (по крайней мере при обычных условиях). Но почему-то всегда забывают о корне мирового зла теге iframe. Во-первых, он может быть скрытым (display:none) и при этом всё равно загрузится. Во-вторых, загрузить его можно откуда угодно (со своего сервера в том числе). И, в-третьих, в нем может быть уже заполненная форма с method=«POST» и action=«http://vulnerable.site/delete_profile.php», а по onload вызываться submit этой формы. Для демонстрации нижеперечисленных уязвимостей я использовал именно такой метод.

Я пользователь — как мне защититься?


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

UPD: Для FF есть addon — RequestPolicy, спасибо Vanav

Я разработчик — как мне позаботиться о своих пользователях?


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

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

Сразу скажу, что способы взял из английской Википедии и, по моему личному мнению, многие из них никакой защитой не являются.
  1. Одноразовый токен для каждого действия — самый надёжный способ, лично я выбираю его
  2. В каждом запросе требовать передачи логина и пароля — тоже надежно, но если используется не HTTPS, то пароль можно украсть из любого запроса с помощью сниффера
  3. Ограничение времени жизни сессии — ни от чего не защищает, просто сокращает время, в течение которого можно воспользоваться уязвимостью
  4. Проверка заголовка Referer — неплохо, но этот заголовок устанавливается не всегда, первый способ всё же предпочтительнее
  5. Убедиться, что clientaccesspolicy.xml и crossdomain.xml (для Silverlight и Flash соответственно) не позволяют запросы из непроверенных источников — это как сначала снять замок с двери и разрешить ходить кому угодно, а потом для защиты повесить его обратно
  6. Проверять наличие X-Requested-With — поможет для AJAX запросов да и то не всегда

Практика


В принципе, поиск CSRF — очень простое занятие. Просто заводим аккаунт на интересующем нас ресурсе, включаем Firebug/Chrome Developer Tools и делаем всё то, что делает обычный пользователь — настраиваем почтовый ящик, читаем, пишем, удаляем письма, пишем в блоги и т.д. При этом не забываем смотреть на отправленные запросы. Если запрос не содержит непонятно как сформированных данных (различные одноразовые токены) — это потенциальная уязвимость. Повторяем этот запрос с локальной страницы и смотрим на результат. Если действие произошло — уязвимость обнаружена. Пишем страничку с формой, загружаем на свой сервер и грузим эту страницу в скрытом iframe с какой-нибудь другой своей страницы — просто для демонстрации работы (или для промышленного использования). Можно ещё каким-нибудь своим знакомым показать и на них проверить. Только трезво оценивайте уязвимость и свои отношения со знакомыми — вряд ли одноклассник Петя обрадуется, если с его счета будет переведено 300 тысяч долларов.

Некоторые запросы не получилось отследить ни через Firebug, ни через Chrome Developer Tools — сначала отправляется AJAX запрос, а после получения ответа на него с помощью JS открывается следующая страница. В этом случае интересующий нас запрос видно только несколько секунд. Но от Wireshark все равно никому не скрыться.

UPD: Умные люди в комментариях подсказывают, что в FireBug есть кнопка «Не очищать» а в Chrome Developer Tools — «Preserve Log upon Navigation»

При поиске уязвимостей нельзя забывать о дополнительных сервисах (вроде календарей Яндекс) и мобильных версиях.

Список уязвимостей


Я не ставил перед собой задачу найти все CSRF узявимости на определенном портале. На каждый ресурс выделялось не больше 2х часов. Проверял только русские порталы — Google.ru, Facebook.com и им подобные остались в стороне. На некоторых порталах за отведенное время я не обнаружил ничего, но в список внес, чтобы оставить общий отзыв об их способе защиты. Некоторые порталы из списка я не считаю крупнейшими в Рунете, но так считает рейтинг, которым я пользовался.

Liveinternet.ru

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

Rambler.ru

Защита от CSRF по методу №1 — одноразовый токен. Казалось бы никаких CSRF быть не может. Но, во-первых, эта защита есть не везде. А, во-вторых, токен не проверяется — можно отправить любой токен (и даже пустой) и все равно нужно действие выполнится. В качестве дополнительной защиты в одной из форм увидел скрытое поле «referer» с адресом текущей страницы. Даже прослезился немного.
Создается впечатление, что разработчикам Рамблера в один прекрасный день сказали, что есть такая уязвимость CSRF и что для защиты от нее нужно с каждым запросом отправлять уникальный токен. Но забыли сказать, что его еще и проверять надо.

Что можно сделать
  1. В Рамблер.Друзьях (да кто ими вообще пользуется?) можно создать группу друзей с произвольным названием, добавить или удалить произвольного друга, изменить настройки уведомлений о действиях друзей/добавлении в друзья
  2. В настройках аккаунта можно добавить или удалить пользователя из черного списка, изменить подпись, изменить местоположение, изменить список своих интересов, разрешить/запретить отображать список своих друзей и своё ФИО
  3. В почте можно отправить произвольное письмо от имени пользователя, включить безусловную переадресацию на произвольный e-mail (без сохранения), изменить настройки почты (особенно ценно включить отображение изображений со сторонних серверов), удалить все письма из папки (на самом деле они переместятся в корзину) и очистить корзину
  4. Также в почте можно удалить письмо, пометить письмо как прочитанное и переслать письмо на произвольный почтовый ящик. Правда для этого нужно знать id письма и имя папки, в которой оно хранится. 2 папки известны — «Входящие» и «Отправленные». id письма — номер письма в текущей папке, так что брутфорс никто не отменял

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

Это далеко не весь перечень, т.к. защиты нет (вернее она есть, но не работает, что равносильно).

Mail.ru

На почте защита от CSRF по методу №2 — ввод пароля. Т.е. изначально это не от CSRF защита, но там, где требуется ввод пароля, CSRF тоже не работает. На других сервисах есть и нормальная защита.

Итак, какие узявимости найдены в популярнейшем почтовом сервисе СНГ
  1. Отправка от имени пользователя письма с любым текстом и темой на любой почтовый ящик. Письмо с уникальным кодом может быть отправлено на почтовый ящик злоумышленника и тогда он узнает email посетителя. Этот email через AJAX попадет на страницу, на которой пользователь уже находится — это пригодится для использования уязвимостей №2, №7
  2. Отправка копии письма на любой адрес (письмо не сохраняется в отправленных, пользователь об этом никак не может узнать). Для использования этой уязвимости нужно было знать id письма — 20 цифр, из которых первые 10 — timestamp, а вторые 10 — номер письма среди обработанных сервером в эту секунду (это только мое личное предположение конечно же). По моим наблюдениям это число не превышает 1000. Можно попросить сервер отправить сразу 1000 писем и тогда он отправит те из них, которые действительно есть у пользователя в почтовом ящике, хотя в интерфейсе pro.mail.ru (а именно там находится эта уязвимость) сказано, что переслать больше 3х писем одновременно нельзя. Использовать можно брутфорсом — переслать письма полученные за 10 секунд, запрашивая пересылку каждый раз по 1000 штук. Чтобы пробрутфорсить письма за день надо 2.5Гб исходящего трафика, но для кражи письма с паролем это и не нужно — на почтовый ящик пользователя (он уже может быть известен из №1) запускается восстановление пароля на стороннем ресурсе и время прихода письма уже приблизительно известно. Можно использовать вместе с уязвимостью №3
  3. Удаление письма — опять же по id. Опять же брутфорсом. Запускаем восстановление пароля, крадем письмо с паролем и удаляем его
  4. Подключение и отключение СМС уведомлений — тут вообще всё просто. Некоторые настройки почтового ящика можно изменить не вводя пароль. Можно отключить уведомления, а можно включить их на свой телефон, привязанный в пункте №7
  5. Отключить сохранение отправленных писем и включить Web mail-агент на страницах почты — эти галочки находятся на одной странице в настройках и так же (как и предыдущая уязвимость) не требовали пароля для изменения состояния. Отключать сохранение отправленных понятно зачем. А включить Web mail-агент имеет смысл, если в нем тоже есть CSRF
  6. Отключить уведомления о приближении лимита размера почтового ящика — суть та же, что и в 2х предыдущих. Отключаем уведомления и заваливаем ящик большими письмами
  7. Привязать/удалить номер телефона — с этим всё немного интереснее. Для всех действий требуется email пользователя (вернее username и domain) которые можно получить из пункта №1. Также требуется указывать номер телефона, так что удалить у пользователя его собственный номер телефона не получится (по крайней мере если его не узнать заранее — например, он отображается авторизованным контактам в mail агенте — а как авторизоваться, это уже другой вопрос). Чтобы привязать свой номер телефона надо отправить соответствующий запрос. После этого на телефон придет СМС с кодом. На этом этапе понадобится софт, который будет код из СМС доставать и по AJAX запросу его сообщать. JS же на страничке получив этот код создаст еще один iframe, который выполнит подтверждение привязки номера телефона. Удалить этот номер телефона можно таким же образом. Тут правда есть одна особенность — если номер телефона единственный, то удалится он только через 15 дней, а не сразу. Удалить его сразу можно только зная код из СМС (он тот же самый, что и для привязки)

Yandex

Защита от CSRF есть. Но т.к. Яндекс — это не только поиск или почта, то и защита везде разная. А где-то что-то пропущено. Яндекс в течение 3х дней ответили на моё письмо и обещали проверить информацию. И они единственные, кто исправил хотя бы одну уязвимость.

Что же можно (было) сделать
  1. Можно было перенастроить поиск — включить сохранение поисковых запросов и результатов в сервисе «Находки», изменить уровень фильтрации поиска (например, запретить искать порнографию коллеге по работе — просто так, из вредности). Эта уявимость на данный момент закрыта
  2. Можно изменить местоположение пользователя — и будут ему показываться результаты поиска, реклама и пробки в Херсоне вместо Питера. А можно изменить всем посетителям местоположение на какое-нибудь не очень популярное и гнать туда рекламу из Директа по ценам значительно ниже московских
  3. Можно создать в календаре пользователя ToDo-list с произвольным именем и добавить в него произвольные дела. Для добавления дел нужно знать id списка, но можно ведь сначала создать список у себя, затем у пользователя, а потом снова у себя и перебрать id между двумя своими списками (а, с учетом количества создаваемых списков, скорее всего даже перебирать ничего не придется). Уязвимость в мобильной версии Яндекс.Календарь
  4. Можно из Яндекс.Паспорта удалить телефон. Нужно знать его id, но зная примерную дату добавления можно его и брутфорсом подобрать
  5. В Яндекс.Маркете можно добавить произвольный товар в список сравнения. Или удалить его оттуда.
  6. В Яндекс.Маркете можно подписать пользователя на уведомление о снижении цены на конкретный товар ниже определенного уровня. Или отписать пользователя от уведомлений. Например, недобросовестный интернет-магазин закупил партию серых iPhone и планирует акцию по их распродаже. Перед самой акцией он устраивает какую-нибудь PR-кампанию и всех посетителей подписывает на уведомление о снижении цены ниже 8000 рублей. А затем в Яндекс.Маркет экспортируется iPhone по цене 7999 рублей и все пользователи получают от Яндекса спам с предложением купить этот самый iPhone
  7. Глобальный логаут. Можно завершить все сессии пользователя на всех компьютерах. Можно пользоваться как мелкой пакостью. Конкуренты могут на своих сайтах размещать iframe, который будет завершать все сессии Яндекса, пользователи будут раздражаться. Вообще, единственный сайт на котором такой проблемы нет — Вконтакте. Там с неправильным токеном даже из аккаунта не выйдешь. Не уверен, можно ли считать это уязвимостью вообще, но похоже Вконтакте считает

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

А как же Вконтакте и ЖЖ?


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

Вконтакте

Токены на любые действия пользователя. Похоже добавляются автоматически, поэтому о них не забывают. Точно такая же защита и в мобильной версии. Один сервис, одна команда разработчиков, нет таких проблем, как, например, у Яндекса. Смущает меня только одно — токен для конкретного действия у конкретного пользователя всегда один и тот же. Т.е. это некая смесь способов защиты №1 и №2 — токены не одноразовые, но известны только пользователю. Можно считать их паролем для выполнения действия — на каждое действие свой пароль. Что-то мне в такой организации не нравится, но я пока не понял, что именно.

ЖЖ

Защита по методу №1 — одноразовые токены. В мобильной версии защита немного проще, но все же есть. Вот на кого можно смотреть в качестве примера. Стоит правда заметить, что сервис-то не очень и русский. Так что он вне конкурса.

Одноклассники

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

Вывод


В общем, картина совершенно нерадостная. Если такие монстры допускают такие ошибки в своих проектах, то всем остальным разработчикам стоит еще раз проверить свои ресурсы. Первое место по скорости закрытия уязвимостей занимает Яндекс со скоростью 1 уязвимость в полтора месяца. Остальные ресурсы занимают почетное второе место.
Поделиться публикацией
Комментарии 150
    +13
    Как пользователь, от этой уязвимости можно защититься при помощи аддона RequestPolicy.
      0
      Спасибо, добавил в пост
        0
        Для Chrome аналогов не существует?
          –1
          хотя, подозреваю, что гугл бы это не очень приветствовал
            +3
            Быстрый поиск говорит что в Хроме с начала 2010 года защита от CSRF уже есть:

            3. CSRF Protection via Origin Header
            This feature was inserted to prevent cross-site request forgery attacks, making it impossible to trick the server into carrying out an action «requested» by a malicious site.

            www.net-security.org/secworld.php?id=8800
              +1
              Это не защита, а всего лишь дополнительный заголовок. Пользователя он ни от чего не защищает. А разработчику бесполезен, поскольку поддерживается пока только в Chrome.

              Сейчас разрабатываются спецификации на эту тему: черновик от W3C, черновик RFC.
                0
                В чем отличие от Referer? По идее можно брать инфу из него.
                  0
                  Наверное тем что referer может подделываться.
                    0
                    Ну, не в этом случае. Ведь CSRF эксплуатируется через браузеры других пользователей, а они, как правило, честно отсылают реферер.
              0
              А как же старый добрый NoScript? Я им уже около 3-ех лет пользуюсь, всегда предупреждает и о XSS, и о CSRF.
                +4
                NoScript не обеспечивает защиты от CSRF.

                Единственное, что он делает, это POST запросы с non-whitelisted сайтов превращает в GET.

                Либо нужно писать правила для его встроенного фаервола ABE. Правила по умолчанию защищают только локальные сайты.
                  +1
                  Да, и правда, нашел строчку про CSRF на оф. сайте. Но в любом случае, NoScript не помешает как дополнительная защита.
              –5
              Ох, все же не надо выкладывать для чайников, ибо действительно может начаться эпидемия.
              Ибо именно чайники-то и сидят на мейлрушечке и будут друг над другом измываться. На компанию это никак не повлияет, а люди пострадают (хотя бы морально).
                +14
                А чего ж Хабр не потестили?
                  –1
                  Вы меня напугали. Подумав о том, что этот топик является тестом хабра, я начал судорожно рыскать в исходниках страници.
                    +31
                    А без аккаунта на хабре это сделать трудно
                      +17
                      Добро пожаловать на хабр.
                      Ждем апдейт статьи.
                        +43
                        > Ждем апдейт статьи

                        «Как получить приглашение на Хабр с помощью CSRF уязвимости» :-)
                          +3
                          Вот вы шутите, а исходный код топика читали?
                          +4
                          А чего ждать? Все знают, что на Хабре токенов нет :). (Все, кто интересовался формой отправки комментариев и другими.) Ну, по крайней мере, в аджакс-методах гарантирую, а отправку статьи — не смотрел.
                        +8
                        вы забыли о черном властилине на главной хабра? пару лет назад хабр исправил эти уязвимости.
                        в своих проектах все важные действия делаю постом (для ссылок ajax постом), а пост проверяю на реферер.
                          0
                          Вы читали статью? Как показал автор, что пост, что реферер — фигня.
                            +2
                            POST — фигня. Referer — не совсем. Он может не передаваться и тогда у добросовестного пользователя могут быть проблемы. Но если ложные срабатывания для вас не проблема — можно отсеивать и по Referer'у.
                              0
                              Как у добросовестного пользователя может не передаваться Referer?
                              Значит он установил себе на комп какую-то хрень, которая режет заголовки — значит это его проблемы.
                                +2
                                Вариант, что человек через проксю на работе сидит, тоже его вина?
                                  0
                                  Нет это вина его сисадмина :)
                              0
                              статью читал, практиковал. если приходит пост без рефака или с реферером не моего домена, значит это левый запрос. а если рефак моего домена и пост, то я на 100% уверен, что запрос сделал мой пользователь и csrf тут не при чём
                                +17
                                Что за фак-рефак ?! Пишите понятно
                                  +1
                                  рефак==реферер, http_referer
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                  +6
                                  Вообще, насколько мне известно, браузеры не посылающие реферер встречаются еще реже чем браузеры с отключенным JS…
                                  Если реферер не приходит а юзер-агент современный нормальный, то возможно это просто чей-то бот с поддельным User-agent.
                                  Так что я тоже считаю защиту на основе Referer вполне действенным методом.
                                    +1
                                    Современная Опера имеет привычку не посылать реферер. Ставится в настройках браузера для конкретного сайта.
                                    Сталкивался с этим на одном своем проекте.
                                      +2
                                      Это не проблема. Точнее, эта проблема не разработчиков сайта а пользователей. Точно так же индивидуально для сайта пользователи могли отключить куки или js, что тоже сломает абсолютное большинство сложных сайтов.

                                      Так что IMHO проверять Referer более чем достаточно для защиты от CSRF.
                                        0
                                        > что тоже сломает абсолютное большинство сложных сайтов

                                        если отключение куков откроет доступ к какому-то приватному функционалу, это ненормально…
                                          +1
                                          Вы это к чему? Отключение Referer никакого дополнительного доступа не откроет, наоборот, с отключенным referer сайт перестанет работать — точно так же, как и с отключенными куками.
                                            0
                                            Ещё можно отключить картинки и ругаться, что не видишь капчу.
                                            Есть люди, которые думают о своей безопасности, а есть параноики ) не принимайте близко к сердцу
                                        0
                                        Значит она настроена криво — то есть с нарушением стандарта.
                                        Если это сделал пользователь — то пусть смело идет лесом.
                                        0
                                        То есть реферер подделать нельзя?
                                          +5
                                          в случае CSRF — нет
                                          +3
                                          На основе чего статистика?
                                          По логам моего сайта, без реферера или с кривым реферером (типа «Field blocked by Outpost Firewall») довольно много пользователей.
                                            –1
                                            Пусть правильно настраивают фаервол.
                                            +1
                                            Метод действенный, но только если применять его с умом. Как-то видел реализацию в виде
                                            if(strpos($_SERVER["HTTP_REFERER"], $_SERVER["SERVER_NAME"])) { /*OK*/ } else { /*Err*/ } 


                                            что ниразу не мешало использовать уязвимость со страницы
                                            _http://attacker.site/vulnerable.site/exploit.html
                                              +2
                                              Эта уязвимость называется «Я вообще нихуя не понимаю, что происходит, но кто-то в интернете делал что-то похожее вооооот этой функцией.»
                                                0
                                                самое смешное — потом исправили на
                                                if(strpos($_SERVER["HTTP_REFERER"], 'http://'.$_SERVER["SERVER_NAME"])==0)
                                                

                                                PS. динамическая типизация играет злую шутку, всего-то === надо
                                                  +1
                                                  Хех, уже давно работаю с PHP только через haXe, начал забывать о таких тонкостях, не сразу даже понял, в чем подвох.
                                                0
                                                Вы это назвали «использовать с умом»?
                                                  0
                                                  а вы таки прочитайте комментарий до конца. видимо пустая строка имеет свойство вас сбивать с толку.
                                                    0
                                                    Ну да.
                                            +8
                                            Поставил я как-то аддон к моззиле — Change Refferer Button. :)
                                            А потом полтора месяца не мог залогиниться на хабре — думал, последствия бана.
                                          0
                                          Обычно они мотивируют это тем, что через JS нельзя отправить POST запрос на другой домен. Это действительно так (по крайней мере при обычных условиях).
                                          Всё же, как показывает пример с фреймом, POST запрос на другой домен отправить-то можно, но вот ответ получить не получится.
                                            +8
                                            А для CSRF это и не нужно. Когда приходит ответ все зло уже свершилось.
                                              0
                                              Именно. Вот об этом и нужно говорить тем, кто считает, что за стеной ограничений кроссдоменных запросов, они в безопасности.
                                                +1
                                                Кстати говоря, это дает возможность защиты в виде 2-ступенчатых автоматических подтверждений.

                                                Посылается запрос на действие с помощью ajax, в ответ приходит некий ключик, который должен взять скрипт и отправить назад — только после этого действие совершится.
                                              +10
                                              Некоторые запросы не получилось отследить ни через Firebug, ни через Chrome Developer Tools — сначала отправляется AJAX запрос, а после получения ответа на него с помощью JS открывается следующая страница

                                              В firebug'е есть кнопка «Не очищать». Если она нажата, запросы не пропадают из списка.
                                                +3
                                                Аналогично в Chrome Developer Tools есть «Preserve Log upon Navigation».
                                                  0
                                                  еще для фаерфокса было расширение, позволяющее получить записанные запросы в удобном виде
                                                  +1
                                                  Вот почему столько спама с приличных на вид мейлрушных ящиков посыпалось.
                                                    +1
                                                    А еще подобной уязвимостью грешат многие голосовалки. Размещая картинку в комментариях у популярных топиков, можно нехило накрутить счетчик.
                                                      +7
                                                      Быть может я что-то упускаю, но скажите, пожалуйста, а банальное hidden-поле с session_id в форме и последующее его сравнение с session_id из куки не поможет? Есть ли смысл замарачиваться с одноразовым токеном?
                                                        +9
                                                        Поможет. Это будет такой же токен, просто не одноразовый, а действующий в течение одной сессии.
                                                        Способы защиты я брал из английской Википедии и на полноту они не претендуют…
                                                          0
                                                          а если скриптом в айфрейме перед отправкой формы вставлять туда это hidden-поле из куки?
                                                            +10
                                                            iframe не получит доступа к кукам другого домена. И токен не узнает и нечего будет в форму подставлять.
                                                            0
                                                            А если аналогично скриптом, перед отправкой формы, вставлять этот токен из куки в hidden-поле?
                                                              +5
                                                              iframe не получит доступа к кукам другого домена. И токен не узнает и нечего будет в форму подставлять.
                                                                +5
                                                                А вы большой оригинал =)
                                                                  0
                                                                  Зато сделает запрос к серверу, который примет куки и вернет страничку со вставленной сессией в hidden-поле. Сессию достаём и выполняем основной запрос.
                                                                    0
                                                                    Значит по полочкам.
                                                                    Загружаем iframe со своего сервера. В полученном фрейме наш JS. Мы имеем полный доступ к DOM и кукам своего домена. Теперь отправляем запрос на атакуемый сервер. Ответ приходит от этого сервера. В полученном ответе уже не наш JS и мы не имеем никакого доступа к DOM или кукам.
                                                            –1
                                                            Потенциальная опасность токенов во вконтакте это подключение сторонних сайтов к api. Если сайт получит от пользователя разрешения (на которые никто не смотрит обычно), то он получит возможность фактически рулить аккаунтом юзера.
                                                              +2
                                                              Ну эти разрешения и так дают сайту такую возможность. Другое дело, что отобрать эту возможность уже не получится (если API получает тот же постоянный токен).
                                                                0
                                                                Угу. В принципе это не уязвимость, т.к. требует подтверждения пользователя, но только единицы знают чем им грозит отдача постоянного токена от своего аккаунта постороннему ресурсу.
                                                                  0
                                                                  Это может быть уязвимостью, если с помощью уязвимости стороннего сайта можно получить доступ к API вконтакте
                                                                0
                                                                что значит «рулить» аккаунтом? можно поподробнее? очень интересно, ну с точки зрения изменить/удалить.
                                                                  0
                                                                  Откровенно говоря нужно сделать исследование, однако я могу точно сказать, что при наличии денег / голосов на вашем счете во «Вконтакте» и наличии у меня вашего id и токена я в любое могу создать от вашего имени к примеру собственную рекламную кампанию. Так-же возможно добавление любых записей на собственной стене / стенах друзей.
                                                                +2
                                                                У меня на тестовом вебсервере лежит файлик /var/www/html/csrf.html, датированный Июл 29 2008. Тогда эта уязвимость работала у социальной сети с буковочкой В, к примеру такой безобидный пример — меняет скин и язык:
                                                                <script>
                                                                function doit() {
                                                                var html;
                                                                html = '<img src="httр://vkоntаktе.ru/settings.php?act=change_language&language=777>';
                                                                window.frames["frm"].document.body.innerHTML = html;
                                                                }
                                                                </script>
                                                                <iframe name="frm" onload="doit()" width="0" height="0"></iframe>



                                                                Но эта соц.сеть пожалуй чаще других штудируется огромной армией на предмет поиска уязвимостей вебинтерфейса, я не отслеживал когда её закрыли.
                                                                +3
                                                                Смущает меня только одно — токен для конкретного действия у конкретного пользователя всегда один и тот же. Т.е. это некая смесь способов защиты №1 и №2 — токены не одноразовые, но известны только пользователю.

                                                                Довольно распространённая практика, в частности интегрирована в некоторые популярные фреймворки. Теоретически менее надежно чем одноразовые токены, но вот как реализовать атаку в голову не приходит.
                                                                  0
                                                                  Мне тут подсказывают, что у токенов есть еще одна задача — предупреждение повторных действий (двойные клики по кнопкам и т.п.). Хотя моя паранойя просит использования только одноразовых токенов. Не требует пока и не настаивает, но все же.
                                                                    +1
                                                                    если я не ошибаюсь, у многоразовых токенов относительно одноразовых есть преимущество: допустим открыл пользователь случайно в двух вкладках страницу редактирования профиля. и ему теперь не надо вспоминать, какую он открыл последней.
                                                                      +1
                                                                      а двойные клики в простейшем виде легко убиваются жаваскриптом (если ставить disabled на сабмиты сразу после клика)
                                                                        0
                                                                        Ну, у этого способа тоже есть недостатки. Например, пользователь нажал на submit, а потом увидел, что у него отключился Интернет. И реально запрос никуда не отправился. А потом у пользователя включился Интернет, но второй раз он нажать «submit» уже не может — теперь ему придётся копировать все заполненные в форме поля и открывать страницу заново, и только тогда он сможет отправить форму снова.
                                                                          +1
                                                                          Я на чистом javascript/jQuery давно не писал, но в Rails Unobtrusive jQuery есть такая штука, как $(form).bind('ajax:error'), который срабатывает в случае ошибки сервера или таймаута соединения. туда можно засунуть убирание с формы и инпутов атрибута disabled.
                                                                            0
                                                                            Угу, если вот так делатЬ, то вариант хороший. :)
                                                                            0
                                                                            В FireFox я юзал Web Developer tools. Попадались такие тупые сайты, где повторно нельзя отправить форму, но если некоторые поля не заполнены — вылезает ошибка «неправильно заполнено или не заполнено поле» (обработка яваскриптом на стороне клиента). Исправляешь ошибки, а засабмитить второй раз не можешь. В Web Developer Tools была отличная возможность Enable form Fields — она и спасала (возможно, и сейчас есть, но уже давно не «девелоплю» и перешел на Chrome)
                                                                        0
                                                                        Скорее всего токен является хэшем адреса и сессии пользователя. Опасность здесь только в том, что если алгоритм хэширования подобрать (а как правило там просто md5(sessionId + URL + secret)), то можно вычислять правильный токен и проходить защиту.
                                                                          0
                                                                          как вычислить токен? как минимум нужно знать secret и sessionId. узнать sid можно утянув куку, а как узнать secret? ну разве что брутфорсить :)
                                                                            0
                                                                            Именно, но secret не длинный статичный для всех пользователей. Опять же — обычно.
                                                                              0
                                                                              md5(secret(sessionId+URL)) решает. Это настолько просто, что не исопльзует только совсем-совсем ленивый.
                                                                              +1
                                                                              Если есть кука, то уже никакой secret и никакой csrf не нужен.
                                                                                0
                                                                                не всегда. если кука привязана к ip и UserAgent то использовать ее гораздо сложнее
                                                                          +3
                                                                          Можно считать их паролем для выполнения действия — на каждое действие свой пароль. Что-то мне в такой организации не нравится, но я пока не понял, что именно.
                                                                          Можно их наснифить и пользоваться.
                                                                            +1
                                                                            Ну вот это конечно же приходит в голову в первую очередь. Только если наснифить токены, то можно ведь и куки наснифить, что полезнее.
                                                                            Вторая мысль — можно токен переписать находясь за компьютером пользователя. Но аналогично — если есть физический доступ к компьютеру потенциальной жертвы, то использовать CSRF уже бессмысленно.
                                                                            Есть еще третья мысль — токен в GET ссылках можно выманить у пользователя (попросить дать ссылку, а в ней будет личный токен)
                                                                            Но в любом случае такая атака будет персонализированной, а не массовой, как в случае с отправлением почты.
                                                                              0
                                                                              По идее в GET ссылках не должно быть токенов.

                                                                              Потому что:
                                                                              — если это токен на чтение чего-то, то он должен быть в куке — иначе он утечет через яндекс-метрику.
                                                                              — если это токе на какое-то действие — то это не долженбыть GET
                                                                                0
                                                                                Я не спорю, что токена не должно быть в GET запросах. Но у контакта (а речь именно о нем) логаут ссылка содержит токен и отправляет GET запрос. Может еще где-то есть такое.
                                                                                Но, опять же, является ли логаут без токена уязвимостью — вопрос очень и очень спорный.
                                                                            –2
                                                                            Спасибо, интересно. Жду продолжения =)
                                                                              +1
                                                                              Да, а вот помню когда-то вконтакте не всюду были токены и можно было идентифицировать например всех посетителей любой подконтрольной странички :)

                                                                              Ну а причина множественных CSRF уязвимостей — низкий уровень разработчиков, особенно на PHP, многие из которых до сих пор учатся по допотопным книжкам с примерами на PHP4. Может, после этой статьи хоть кто-то задумается.
                                                                                +4
                                                                                Лучше пример запостите, «как правильно использовать токены на PHP»
                                                                                  +10
                                                                                  все правильно, во всём виноват php )))
                                                                                    0
                                                                                    Вы преувеличиваете вину PHP разработчиков.

                                                                                    Технология не виновата в том, что она популярна и заманивает в свои сети много тех кто не стремится развиваться и становится программистом как таковыми. Если взять эту толпу и сравнить с опытными Python разработчиками, то конечно первые будет «низкого уровня». А вот если набрать кучу новичков (полных новичков, а не тех кто переходит с С++), то их уровень будет примерно одинаковым.

                                                                                    P.S. Просто ИМХО!
                                                                                      +3
                                                                                      знание C++ здесь не очень поможет

                                                                                      это же уязвимость на уровне HTTP
                                                                                        0
                                                                                        Да, в данном случае никакой язык не поможет. Тут нужно не костыли, как сейчас, а что-то иное придумывать на стороне web сервера, что ли…
                                                                                          0
                                                                                          во всех распространённых CMS и фреймворках эта дырка закрыта, остальные — сами себе злобные буратины
                                                                                    –3
                                                                                    «В Рамблер.Друзьях (да кто ими вообще пользуется?) можно создать группу друзей с произвольным названием, добавить или удалить произвольного друга, изменить настройки уведомлений о действиях друзей/добавлении в друзья»

                                                                                    Автор, вы когда были последний раз на этом сервисе?
                                                                                      0
                                                                                      наверное, около полутора месяцев назад, судя по тексту…
                                                                                        0
                                                                                        Не совсем. Еще раз заходил дня 3 назад, когда проверял информацию для статьи.
                                                                                      0
                                                                                      Киньте, пожалуйста, почитать про токены что-нибудь полезное для тех, кто не знает, что это.
                                                                                      0
                                                                                      Может gmail проверите?
                                                                                      +10
                                                                                      Неплохо для «песочницы» — добро пожаловать! :)
                                                                                        0
                                                                                        В общем, картина совершенно нерадостная.

                                                                                        На php.com.ua была статья, так вот там картина была ещё хуже, на чуть ли не большинстве проверенных сайтов (брался список из Яндексовского каталога вроде) были элементарные SQL и XSS дыры (статья старая, сейчас может и не так всё плохо)

                                                                                        Более того, администрация проверенных сайтов в ответ на сообщение о дырах, чаще всего (чуть ли не в 99%) только ругалась и кричала что-то типа «нефик в адресную строку пихать что попало, кулхацкеры хреновы» (и не пыталась ничего исправить, словно это не их проблема)
                                                                                          –2
                                                                                          Для защиты же от сабжа, предпочитаю подход как в phpBB2 и прочих форумах (передачу id-сессии в url для тех действий которые делаются для «залогиненного пользователя...»)
                                                                                            0
                                                                                            Минусующих данное сообщение прошу разъяснить, что же такого глупого сказал Vladson?

                                                                                            Я тоже считаю, что по крайней мере заместо ОДНОРАЗОВОГО токена можно использовать тот же id сесси. В post-формы его можно вставлять в hidden-поле, а для get-запросов придется вставлять в url.

                                                                                            В чем преимущество отдельного одноразового токена перед id сессии?
                                                                                              0
                                                                                              ответ уже был выше от автора поста вот тут
                                                                                                0
                                                                                                Просто видимо не все поняли о чём речь. Я сказал практически тоже самое (просто они видимо не поняли что имелось в виду, не все же знают как там оно в рнрВВ2, движок то старый)
                                                                                          0
                                                                                          В проектах написанных на ASP.NET достаточно включить event validation. Правда если вы меняете содержимое контролов на стороне клиента, ваш код сломается (придется чинить), но зато вы гарантированно убережетесь от CSRF атак.
                                                                                            0
                                                                                            А для ASP.NET MVC достаточно добавить в форму вывод AntiForgeryToken, а экшены помечать таким же атрибутом [AntiForgeryToken]
                                                                                              0
                                                                                              Зато негодующие на марше. :)
                                                                                              0
                                                                                              Для полной гарантии необходимо в базовом классе страницы задать свойство ViewStateUserKey.
                                                                                              Например, ViewStateUserKey = Session.Id (получается один токен на всю сессию)
                                                                                              Если паранойя, то можно каждый раз во ViewStateUserKey одноразовый токен, например Guid
                                                                                              0
                                                                                              По поводу токенов кстати, кто не понял или не знает как работать — есть отличная статья, правда на английском: shiflett.org/articles/cross-site-request-forgeries

                                                                                              В кратце все просто — для каждой формы или опасного действия грубо делается следующее (PHP):

                                                                                              <?php
                                                                                              session_start();

                                                                                              if ( @$_SESSION['token'] && @$_POST["token"] ) {
                                                                                               if ( $_SESSION["token"] == $_POST["token"] ) {
                                                                                                обработка формы
                                                                                               }
                                                                                              }

                                                                                              $token = md5(uniqid(rand(), TRUE));
                                                                                              $_SESSION['token'] = $token;

                                                                                              ?>
                                                                                              <form ...>
                                                                                              ....
                                                                                              <input type="hidden" name="token" value="<?php echo( $token ); ?>"
                                                                                              </form>
                                                                                                0
                                                                                                Я не знаю PHP, но, предполагая что содержимое $_SESSON автоматически сохраняется в куках, этот код сломается как только юзер откроет сайт в двух табах/окнах параллельно. Корректно реализовать одноразовые токены не так просто, поэтому на мой взгляд лучше (и достаточно) проверять Referer.
                                                                                                  +1
                                                                                                  Содержимое сессии хранится на сервере, а в куках только идентификатор сессии и передается каждый раз.
                                                                                                  А код действительно сломается, если делать только один ключ «toket» в сессии. Что бы избежать этой проблемы в данном примере, нужно хранить не один ключ, а массив ключей с таймштампом их создания, периодически проходится по массиву и удалять старые ключи (скажем, старше 1 часа), что бы не засирать сессиюю. А проверку токена на стороне сервера заменить на array_key_exists. Тогда можно будет открывать хоть 100500 вкладок и все они будут рабочими со своими уникальными токенами в hidden полях, и куча токенов будет на сервере.

                                                                                                  Ну это так, как вариант :)
                                                                                                    0
                                                                                                    Опередили )))
                                                                                                    0
                                                                                                    содержимое $_SESSION не хранится в куках, в куках хранится лишь id сессии, к тому-же это всеголишь пример. Чтобы ничего не ломалось в тойже статье описан способ когда токен выдается на определнное время — что делает этот способ вполне корректным.

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

                                                                                                        «резаться проксями» — первый раз слышу. это голая теория, или кто-то с этим сталкивался на практике? все варианты настройки прокси на вырезание Referer, о которых я читал, относились к категории «поставь себе локальный проксик на 127.0.0.1 который добавит тебе анонимности» — это ничем не отличается от отключения Referer в браузере, тоже всё происходит под полным контролем пользователя и с его ведома.
                                                                                                          0
                                                                                                          Это если локально то да, просто ИМХО когда любой пользователь необходим ресурсу начинаешь задумываться об этом.

                                                                                                          Из практики про непользовательские прокси могу рассказать что знаю контору у которых стоит Squid режущий все заголовки кроме базовых — с точки зрения админа это типа «безопасно» + «многие дурацкие сайты не работают» :-D

                                                                                                          На самом же деле вопрос намного сложнее, чем ответ.
                                                                                                          Разные способы — разные риски.
                                                                                                          На мой взгляд самое надежное — запрашивать пароль перед какойлибо «опасной» процедурой.
                                                                                                          И в случае если пользователь очень важен ресурсу то больше не проверять ничего. ИМХО.
                                                                                                    +7
                                                                                                    Мне кажется, проблемы начинаются тогда, когда защищенный код написать сложнее, чем дырявый (например, это так на «голом» php). В таких случаях нужно постоянно держать уязвимости в голове, легко что-то упустить. Это если вообще задумываться.

                                                                                                    C этой точки зрения очень нравится подход явного отключения защиты, а не включения (когда дырявый код написать сложнее, чем защищенный). Например, это так в django и tornado — в шаблонах все экранируется по умолчанию (когда нужно вывести голый html, экранирование нужно явно отключать); orm экранирует sql; если забыли в POST-запрос включить csrf-токен (например, тегом при рендеринге формы, или заголовком браузера для ajax), то по умолчанию все упадет с ошибкой 403 (когда проверка на csrf не нужна — хук для api, например, то ее нужно явно отключать).

                                                                                                    Короче говоря, лучше всего для таких штук пользоваться фреймворками, а не изобретать велосипеды, безопасность — штука тонкая, там очень легко ошибиться, реализовать неправильный вариант, забыть о чем-то и тд.
                                                                                                      +2
                                                                                                      простите оффтоп, но про Alice и Bob понравилось — традиции есть традиции;-)
                                                                                                      да и статья хорошая, теперь знаю название этого метода.
                                                                                                        0
                                                                                                        Спасибо, порадовали)
                                                                                                        Сам стараюсь уделять этому внимание и вообще с формами аккуратно быть, все везде перепроверять.
                                                                                                        И крайне удивлен, что такая лажа на таких сайтах случается
                                                                                                          –1
                                                                                                          > Некоторые запросы не получилось отследить ни через Firebug, ни через Chrome Developer Tools — сначала отправляется AJAX запрос, а после получения ответа на него с помощью JS открывается следующая страница. В этом случае интересующий нас запрос видно только несколько секунд. Но от Wireshark все равно никому не скрыться.

                                                                                                          А вот эту кнопочку Вы не заметили? ;)

                                                                                                          clip2net.com/clip/m91347/1313548708-clip-87kb.png

                                                                                                          Сделайте UPD.
                                                                                                            0
                                                                                                            Положительная тенденция — все больше и больше люди обращают внимания на безопасность веб. Отрицательная сторона всего этого — то что разработчики должны быть заинтересованы в написании безопасного сайта, что очень трудно мотивировать в небольших и средних организациях. В данной уязвимости от самого пользователя и его осведомленности мало что зависит!
                                                                                                              –1
                                                                                                              Ы, мне понравилось. Я таким немножко игрался, но вот до ифрейма не додумался.
                                                                                                                0
                                                                                                                Хорошая статья, но 1 месяц всё-таки не такой большой срок для исправления уязвимостей. Ну да ничего, там где кому-то было надо, все уже и так всё нашли. Пачка хомячков никому вреда не наделают.
                                                                                                                  0
                                                                                                                  Здравствуйте, я Валентин Любимов из LiveInternet.ru

                                                                                                                  Критическая масса людей, которые прочитали это и волнуются за наш сайт, набралась, и я таки отвечу.
                                                                                                                  1) Да, у нас нет токенов на каждое действие
                                                                                                                  2) Но у нас также нет возможности вставить ифрейм, а все перечисленные автором действия, которые он конечно смог сделать, спора нет, делаются через POST-запрос.

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

                                                                                                                    Для начала хотел бы обратить ваше внимание на то, что специально для таких, как вы, в статье есть раздел «А в моём приложении все действия выполняются через POST запросы». А про вас написан первый абзац раздела «Я разработчик — как мне позаботиться о своих пользователях?». Вчитайтесь, пожалуйста, во фразу «Вон из профессии». Вас она касается в первую очередь.

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

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

                                                                                                                    Жду от вас публичных извинений.

                                                                                                                    P.S. Передавайте привет своему отделу скрипткиддис-тестирования
                                                                                                                      0
                                                                                                                      Приношу публичные извинения, если мой комментарий выглядел для Вас агрессивным, он и правда резок.

                                                                                                                      Действительно, если заставить пользователя перейти по странной ссылке — то можно сделать с ним нехорошие вещи. И действительно с этим надо срочно что-то делать.
                                                                                                                    0
                                                                                                                    Извините, возможно я тоже перегнул палку. Все же очень не люблю, когда меня необоснованно обвинят во лжи, не удосужившись разобраться в сути проблемы.
                                                                                                                      0
                                                                                                                      Без проблем, иногда полезна небольшая встряска:)

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

                                                                                                                      Сделал, чтобы у всех важных форм была проверка реферера, если нет реферера — проверяется по токену. Это быстрое решение буквально в три строчки. Конечно надо защитить еще и GET запросы, конечно токены должны быть более одноразовые, чем я сделал сейчас. Но это лучше делать хорошо обдумав и не с помощью костылей.
                                                                                                                        0
                                                                                                                        Буду благодарен, при надобности — публично, если найдете в сделанном только что решении конкретные недостатки или же как-то еще поможете нашему сайту быть более устойчивым к менее доброжелательным атакам. Пойду делать другие дела, удачи всем!
                                                                                                                        0
                                                                                                                        Насколько я понимаю у всех крупных CMS/Framework'ов защита от csrf встроена.
                                                                                                                        Крупные конторы пошли ещё дальше и встроили защиту прямо в http-сервер.

                                                                                                                        Начинать писать собственное решение не ознакомившись с уже существующими реализациями, как минимум, не профессионально.
                                                                                                                        Как говорится: Those Who Forget History Are Doomed to Repeat It
                                                                                                                          0
                                                                                                                          Выложил архивы с примерами. Внутри html, который автоматически использует уязвимость. Для использования нужно поместить в iframe на своем сайте. Для изучения — скачать, распаковать и ни в коем случае не открывать в браузере.
                                                                                                                          Если не работает или непонятно, что есть что в запросах — вопросы задавайте в ответах к этому комментарию, постараюсь ответить.
                                                                                                                          Во многих местах встречаются непонятные цифры. Обычно это число заведомо меньше или заведомо больше текущего timestamp'а. Если нет — спрашивайте.
                                                                                                                          Если вы что-то проверили и оно работает/не работает — пишите в ответах к комментарию.
                                                                                                                          Для Liveinternet примеров мало (только создание поста, отправка комментария и личного сообщения), т.к. времени мало и ValeZ писал, что уязвимости закрыл.
                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                              +2
                                                                                                                              Вы топик читали?
                                                                                                                              С чего вы взяли, что я не сообщил о проблемах разработчикам?
                                                                                                                              С чего вы взяли, что от использования этих уязвимостей уже не страдают люди? Загляните, например, сюда
                                                                                                                              И почитайте первые 3 абзаца. Специально ведь первым делом написал об этом.
                                                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                  +1
                                                                                                                                  О, замечательно, вы работаете в Рамблере.
                                                                                                                                  Расскажите, какую судьбу постигло письмо от 20го июня на адрес mailsupport@rambler-co.ru, тема письма — «CSRF уязвимости»
                                                                                                                                  Заодно расскажите, как же я должен был удостовериться, что меня услышали.
                                                                                                                                  И с каких пор сделать так, чтобы багрепорт был получен, задача пользователя, а не компании? Объясните, почему я должен тратить пару дней изобретая способы достучаться до отвечающих за это людей, а потом еще как-то убеждаться, что они письмо получили?
                                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                      0
                                                                                                                                      Во-первых, ни одного ответа не было.

                                                                                                                                      Во-вторых, здесь было бы о чем говорить, если бы вы были единственными, кого я оповещал. А мы же имеем четыре компании, из которых 3 получили и не стали ничего делать (Яндекс все-таки закрыл одну уязвимость, но это почти не считается) и вас, которые даже нормальных способов сообщить о проблеме не предоставили.

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

                                                                                                                                      В общем, мне с вами говорить не о чем, пока не расскажете, куда делось письмо от 20го июня. Их там на самом деле 2, но первое ушло недописанным — не перечислил баги и только 16 дырок написал.
                                                                                                                                        0
                                                                                                                                        Что-то мне подсказывает, вас сейчас забанят, а топик снесут.
                                                                                                                                          0
                                                                                                                                          Антон, а скажите, пожалуйста — от Mail.Ru на Ваше сообщение пришел ответ? К разработкичам-то Ваше сообщение попало, а вот ответили ли Вам благодарностью — хочу на всякий случай уточнить ;-)
                                                                                                                              0
                                                                                                                              Лучше поздно, чем никогда.

                                                                                                                              Хочу сообщить, что мы закрыли описанные CSRF-уязвимости в Почте Mail.Ru — «самым правильным способом», описанном в данном посте — с помощью токена. Надо сказать, что токен уже применялся во многих критичных местах, но далеко не во всех. Теперь механизм токенов применяется во всех модифицирующих (то есть меняющих или отправляющих что-то) запросах, а также в важных запросах на получение данных (прошу прощения, если ваши боты от этого сломались).

                                                                                                                              Еще раз спасибо автору топика за замечания.

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

                                                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                              Самое читаемое