Смотрите, тут дело несколько в другом. CSRF атака нужна не для того, чтобы эмулировать действия пользователя и оставлять всякие рекламные сообщения на сайте. CSRF предназначена для того, чтобы выполнить от имени пользователя (злоумышленник не имеет доступа к его аккаунту) запрос на сайт (этот запрос пользователь тоже не хочет выполнять). Подобные методы не защитят вас от спамеров. Но помогут защитить ваших пользователей от CSRF, чтобы те не лишились своих аккаунтов.
1) Как и говорили выше, логичнее делать такие запросы через POST, а пользователям не давать возможность вставлять необработанный HTML в сообщения. И, конечно, стоит использовать токен.
2) С формальной точки зрения, данный пример опровергает бесспорность первого пункта. Если же подходить менее формально, то ситуация несколько другая: хотя токен и не был одноразовым, при выходе с сайта он стал таковым: когда пользователь покинул сайт, его старый токен должен стать недействительным, а новый он получит при следующем входе на сайт. В данном конкретном случае раскрытие такого токена не позволяет провести атаку с его использованием.
Я не спорю, что эти недостатки можно обойти. Но эти методы я бы отнес к разряду лучших практик для достаточно крупных сайтов. Например, для многих сайтов, расположенных на shared-хостинге, использование балансера, реверс прокси или фильтрации на уровне сервера весьма затруднительно. А добавление токенов значительно проще.
Или пример на основе реального проекта вашей компании. Речь идет о LOTRO. Когда на сайте этой игры всплыли возможности для CSRF, разработчики сначала добавили проверку на Referer, так они поступили с каждой новой CSRF, которая была найдена. Потом им сообщили о возможности использования одного токена для разных пользователей (что-то вроде токена применялось в некоторых формах, алгоритм выбора которых я так и не понял). Через некоторое время они применили несколько попыток сделать защиту от кликджекинга. А уже после этого они, наконец-то, добавили токены во все критичные запросы на сайте. Как вы понимаете, речь про замену метода запросов на отличный от GET/POST даже не шла.
Сама идей, на мой взгляд, довольно интересная. Но у нее есть два недостатка:
1) Повышается сложность разработки: вместо того, чтобы добавить новое скрытое поле в форму, генерировать токен и проверять его на стороне сервера (реализация всех этих действий требует не очень много кода и совсем небольшое вмешательство в уже существующий), вам необходимо написать посредника для получения данных из формы (чем сложнее форма, тем больше кода и потенциальных ошибок) и отправки их на сервер. На серверной стороне вам надо будет переписать код, отвечающий за прием данных и их валидацию. И необходимо убедиться, что не происходит обработки POST/GET запросов, изменяющих данные пользователя. Я наблюдал много схожих ошибок у тех, кто активно использует AJAX на сайте: на сервере нет проверки, пришли ли данные через AJAX или обычную отправку формы. Это просто рай для любителя CSRF.
2) Вам надо следить за возможными обновлениями браузеров: я видел некоторое количество предложений разрешить использовать тот же PUT в обычных формах. Если же вы правильно реализовали механизм токенов, то вам не надо этого боятся. Проверку токена на серверной стороне не сможет отменить ни один браузер.
Я не уверен, что статья бесполезна. Но, по-моему, на подавляющем большинстве сайтов есть гораздо более серьезные проблемы в дизайне и юзабилити, нежели неудобные и вредные плейсхолдеры. Возможно, кто-то уже поборол все другие проблемы и вопрос удобства плейсхолдеров стал весьма критичным, но я не видел ни одного такого сайта.
Поделюсь похожей историей, произошедшей со мной и очень известной финансовой организацией (не банк, но будет поизвестнее многих).
Долгое время пользовался их услугами, все было хорошо. Однажды я нашел на их сайте CSRF, позволяющую добавить дополнительный полноправный адрес электронной почты и спокойной получить доступ к аккаунту пользователя. А там полный список финансовых операций, паспортные данные, части номеров карт и всякие неприятные мелочи. Сразу же написал об этом в техподдержку. После долгого молчания написал второе письмо, получил ответ, что разработчик не считает эту уязвимость серьезной. На мой вопрос о том, считают ли они нормальным доступ постороннего к такому количеству личных данных, я получил ответ, что данная уязвимость не позволяет получить доступ к аккаунту пользователя. На этом пока наше общение прервалось. С нетерпением жду продолжения.
Если кому-то будет интересно, могу написать подробнее о том, как все закончилось, когда (и если) эта уязвимость будет закрыта.
Я бы не был таким оптимистичным. Ибо я почти уверен, что большая часть родителей, которые заведут такие аккаунты, и сейчас сами более-менее контролируют то, что смотрят их дети. Если вы поищите в комментариях к посту причины, почему родители рады этому нововведению, то увидите, что их дети смотрят вполне безобидные мультики и передачи. Я же знаком с теми, чьи далеко еще не тринадцатилетние дети смотрят далеко не детские ролики. Если из пересадить на новые аккаунты, то они первым делом будут искать способы обойти ограничения. И не стоит забывать, что современный интернет — срез общества. Просто многие вещи в нем гораздо лучше видно.
Безусловно, я рад, что Гугл идет по пути адаптации своих сервисов для детей. Но опасаюсь того, что все может закончиться на детских аккаунтах для пай-мальчиков и версии Ютуба для них.
Абсолютно согласен, что материальные стимулы очень важны. Другое дело, что надо определить, насколько большими они должны быть. В одной статье и комментариях к ней, если я не ошибаюсь, пришли к выводу, что разница в зарплатах должна достигать 20% в пользу текущего места работы, чтобы человек работал в менее комфортных для него условиях. Так что, как мне кажется, бонусы должны составлять не менее 20% от зарплаты, плюс обязательно покрывать разницу между зарплатами в вашей и конкурирующей фирме. Только тогда можно отказаться от других стимулов. А это требует больших затрат, которые не всегда позволительны для маленьких фирм.
Я всегда считал, что у подобных руководств есть общая большая проблема: они предлагают способы удержать сотрудника от ухода, но не объясняют, почему он уходит. Мне кажется, что это самый главный вопрос.
И я бы выделил две основные причины:
1) Ожидания сотрудника не соответствуют действительности.
2) У него изменились жизненные обстоятельства.
Возникновение первой причины надо контролировать с первого собеседования: если соискателю сказали, что через месяц он будет старшим программистом в группе, через год — начальником нового отдела, а он уже полгода сидит и оживляет промо-странички сайта супер-проекта, используя однотипные скрипты, то очень вероятно, что он скоро захочет уйти. Чтобы этого избежать, не надо врать и приукрашивать реальность на собеседованиях. Да, будет меньше кандидатов, вы не получите звезд в команду. Но и коллектив не разбежится так быстро.
Вторая причина прозаичнее: если у сотрудника прибавление в семье, сгорела квартира или дача требует ремонта, то ему не нужен ни горизонтальный карьерный рост, ни близость к руководству, ни открытость начальника. Ему просто нужна высокая зарплата. Можете ее дать? Отлично. Не можете? Тогда либо попрощайтесь с сотрудником, либо помогите ему решить его проблемы.
А уже после того, как вы искоренили причины, можно применять все советы из подобных статей.
Я согласен с тем, что дизайн ВК надо менять очень осторожно, либо вообще не трогать.
Но категорически не согласен с тем, что обновление дизайна Хабрахабра — пример для подражания: если посмотреть комментарии к новости о редизайне, то можно увидеть огромное количество негатива и критики. И многие комментаторы довольно аргументированно обосновали свою позицию.
Мне кажется, что такая инфраструктура из взаимодействующих устройств и web-приложений может быть удобна, когда надо что-то быстро сделать один раз, а вопрос надежности вообще не стоит. Приведу примеры того, что я имею ввиду:
Вы поставили что-то на плиту на кухне, а сами ушли в комнату. Нет нужды бегать и смотреть, не убежало ли что. Достаточно направить камеру планшета в сторону плиты, а видео смотреть с телефона. Это одно из возможных применений передачи видео с одного устройства на другое.
Вы можете оставить планшет в машине, а сами пойти в магазин или на работу. Если гироскоп определит изменение положения планшета, то веб-приложение уведомит вас об этом. Пора бежать к машине и смотреть, что случилось.
Как мне кажется, примеров использования такой технологии в чем-то очень сложном будет немного. Но появится много простых и удобных сервисов. Другое дело, что для этого требуются стандарты и их поддержка всеми браузерами и устройствами. И я бы не доверил что-то важное таким приложениям. Например, точно не стал бы использовать для замены радионяни.
1) Как и говорили выше, логичнее делать такие запросы через POST, а пользователям не давать возможность вставлять необработанный HTML в сообщения. И, конечно, стоит использовать токен.
2) С формальной точки зрения, данный пример опровергает бесспорность первого пункта. Если же подходить менее формально, то ситуация несколько другая: хотя токен и не был одноразовым, при выходе с сайта он стал таковым: когда пользователь покинул сайт, его старый токен должен стать недействительным, а новый он получит при следующем входе на сайт. В данном конкретном случае раскрытие такого токена не позволяет провести атаку с его использованием.
Или пример на основе реального проекта вашей компании. Речь идет о LOTRO. Когда на сайте этой игры всплыли возможности для CSRF, разработчики сначала добавили проверку на Referer, так они поступили с каждой новой CSRF, которая была найдена. Потом им сообщили о возможности использования одного токена для разных пользователей (что-то вроде токена применялось в некоторых формах, алгоритм выбора которых я так и не понял). Через некоторое время они применили несколько попыток сделать защиту от кликджекинга. А уже после этого они, наконец-то, добавили токены во все критичные запросы на сайте. Как вы понимаете, речь про замену метода запросов на отличный от GET/POST даже не шла.
1) Повышается сложность разработки: вместо того, чтобы добавить новое скрытое поле в форму, генерировать токен и проверять его на стороне сервера (реализация всех этих действий требует не очень много кода и совсем небольшое вмешательство в уже существующий), вам необходимо написать посредника для получения данных из формы (чем сложнее форма, тем больше кода и потенциальных ошибок) и отправки их на сервер. На серверной стороне вам надо будет переписать код, отвечающий за прием данных и их валидацию. И необходимо убедиться, что не происходит обработки POST/GET запросов, изменяющих данные пользователя. Я наблюдал много схожих ошибок у тех, кто активно использует AJAX на сайте: на сервере нет проверки, пришли ли данные через AJAX или обычную отправку формы. Это просто рай для любителя CSRF.
2) Вам надо следить за возможными обновлениями браузеров: я видел некоторое количество предложений разрешить использовать тот же PUT в обычных формах. Если же вы правильно реализовали механизм токенов, то вам не надо этого боятся. Проверку токена на серверной стороне не сможет отменить ни один браузер.
Долгое время пользовался их услугами, все было хорошо. Однажды я нашел на их сайте CSRF, позволяющую добавить дополнительный полноправный адрес электронной почты и спокойной получить доступ к аккаунту пользователя. А там полный список финансовых операций, паспортные данные, части номеров карт и всякие неприятные мелочи. Сразу же написал об этом в техподдержку. После долгого молчания написал второе письмо, получил ответ, что разработчик не считает эту уязвимость серьезной. На мой вопрос о том, считают ли они нормальным доступ постороннего к такому количеству личных данных, я получил ответ, что данная уязвимость не позволяет получить доступ к аккаунту пользователя. На этом пока наше общение прервалось. С нетерпением жду продолжения.
Если кому-то будет интересно, могу написать подробнее о том, как все закончилось, когда (и если) эта уязвимость будет закрыта.
Безусловно, я рад, что Гугл идет по пути адаптации своих сервисов для детей. Но опасаюсь того, что все может закончиться на детских аккаунтах для пай-мальчиков и версии Ютуба для них.
И я бы выделил две основные причины:
1) Ожидания сотрудника не соответствуют действительности.
2) У него изменились жизненные обстоятельства.
Возникновение первой причины надо контролировать с первого собеседования: если соискателю сказали, что через месяц он будет старшим программистом в группе, через год — начальником нового отдела, а он уже полгода сидит и оживляет промо-странички сайта супер-проекта, используя однотипные скрипты, то очень вероятно, что он скоро захочет уйти. Чтобы этого избежать, не надо врать и приукрашивать реальность на собеседованиях. Да, будет меньше кандидатов, вы не получите звезд в команду. Но и коллектив не разбежится так быстро.
Вторая причина прозаичнее: если у сотрудника прибавление в семье, сгорела квартира или дача требует ремонта, то ему не нужен ни горизонтальный карьерный рост, ни близость к руководству, ни открытость начальника. Ему просто нужна высокая зарплата. Можете ее дать? Отлично. Не можете? Тогда либо попрощайтесь с сотрудником, либо помогите ему решить его проблемы.
А уже после того, как вы искоренили причины, можно применять все советы из подобных статей.
Но категорически не согласен с тем, что обновление дизайна Хабрахабра — пример для подражания: если посмотреть комментарии к новости о редизайне, то можно увидеть огромное количество негатива и критики. И многие комментаторы довольно аргументированно обосновали свою позицию.
Вы поставили что-то на плиту на кухне, а сами ушли в комнату. Нет нужды бегать и смотреть, не убежало ли что. Достаточно направить камеру планшета в сторону плиты, а видео смотреть с телефона. Это одно из возможных применений передачи видео с одного устройства на другое.
Вы можете оставить планшет в машине, а сами пойти в магазин или на работу. Если гироскоп определит изменение положения планшета, то веб-приложение уведомит вас об этом. Пора бежать к машине и смотреть, что случилось.
Как мне кажется, примеров использования такой технологии в чем-то очень сложном будет немного. Но появится много простых и удобных сервисов. Другое дело, что для этого требуются стандарты и их поддержка всеми браузерами и устройствами. И я бы не доверил что-то важное таким приложениям. Например, точно не стал бы использовать для замены радионяни.