Дабл сабмит что это
Двойное Представление Образца Печенья
Дата публикации Oct 3, 2019
Нежелательным действием может быть изменение учетных данных пользователя, перевод средств или возможность получить полный доступ через учетную запись пользователя.
Чтобы предотвратить атаку CSRF, мы можем использовать либо шаблон Double Submit Cookie, либо Synchronizer Token Pattern.
В этом посте я собираюсь обсудить шаблон Double Submit Cookie.
Шаблон cookie с двойной передачей использует файлы cookie для сохранения токенов CSRF и не требует сохранения каких-либо записей токенов в памяти сервера.
При успешном входе пользователя в клиентское приложение сервер создает файл cookie, содержащий токен CSRF, и файл cookie отправляется клиенту вместе с ответом об успешном выполнении. После получения файла cookie клиент получает значение токена CSRF и вставляет его в скрытое поле. Затем клиент прикрепит это значение токена CSRF к каждому запросу, отправляемому на сервер. Для этого браузер клиента должен запомнить значение токена.
Запросы, сделанные клиентом, содержат токен как в файле cookie, так и в теле запроса. Таким образом, когда сервер получает запрос, он получает два значения токена из файла cookie, а также из тела. Затем он сравнит их, прежде чем предпринимать действия. Если оба значения совпадают, произойдут дальнейшие манипуляции и соответствующий ответ будет отправлен клиенту. В противном случае сервер выдаст ошибку.
Здесь у меня есть пример PHP-приложения, которое реализовано для демонстрации описанного выше процесса шаблона двойной отправки cookie.
Сначала пользователь должен войти в веб-приложение, используя свое имя пользователя и пароль. В моем коде я жестко закодировал учетные данные (username = «admin» / password = «admin123») для демонстрации.
После успешного входа в приложение оно перенаправит вас на страницу перевода денег (counter.php), где вы сможете перевести деньги на другой счет.
В то же время токен CSRF будет сгенерирован и сохранен в файле cookie в браузере. Также будет сгенерирован идентификатор сеанса и установлен как cookie.
Когда страница денежного перевода загружается, она считывает значение cookie, а также значение токена, которое находится в теле, и получает токен CSRF и устанавливает его значение для скрытого текстового поля в форме.
Затем полученные два значения будут сравниваться, если они совпадают друг с другом, будет отображаться сообщение об успехе. Если нет, появится сообщение об ошибке.
Методы защиты от CSRF-атаки
Что такое CSRF атака?
Ознакомиться с самой идеей атаки CSRF можно на классических ресурсах:
Выдержка из ответа на SO:
Как от нее защититься?
Эффективным и общепринятым на сегодня способом защиты от CSRF-Атаки является токен. Под токеном имеется в виду случайный набор байт, который сервер передает клиенту, а клиент возвращает серверу.
Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.
А что, собственно, защищать?
На Habrahabr опубликована статья от Yandex, в которой описано, почему писать свои сервисы нужно, руководствуясь стандартом.
Требования к токену:
На первом MeetUp’е PDUG Тимур Юнусов (руководитель отдела безопасности банковских
систем Positive Technologies) рассказывал, почему именно такие требования предъявляются к CSRF-Токену и чем грозит пренебрежение ими.
Требования к Web-Сервису и окружению:
Отсутствие XSS уязвимостей
Внедренный злоумышленником скрипт имеет возможность отправлять запрос к серверу от имени пользователя и читать его без каких-либо препятствий.
Таким образом, XSS уязвимости могут быть использованы для получения текущего токена.
Отсутствие malware на машине клиента
Если злоумышленник имеет возможность запускать софт на машине клиента, то он может получить любые данные, имеющиеся в браузере.
Методы защиты
Существует 3 метода использования токенов для защиты web-сервисов от CSRF атак:
Synchronizer Tokens
Простой подход, использующийся повсеместно. Требует хранения токена на стороне сервера.
При старте сессии на стороне сервера генерируется токен.
Токен кладется в хранилище данных сессии (т.е. сохраняется на стороне сервера для последующей проверки)
В ответ на запрос (который стартовал сессию) клиенту возвращается токен.
Если рендеринг происходит на сервере, то токен может возвращаться внутри HTML, как, например, одно из полей формы, или внутри тега.
В случае, если ответ возвращается для JS приложения, токен можно передавать в header (часто для этого используют X-CSRF-Token )
При последующих запросах клиент обязан передать токен серверу для проверки.
При рендере контента сервером токен принято возвращать внутри POST данных формы.
JS приложения обычно присылают XHR запросы с header ( X-CSRF-Token ), содержащим токен.
Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.
На выходе имеем:
Защита от CSRF на хорошем уровне
Токен обновляется только при пересоздании сессии, а это происходит, когда сессия истекает
Во время жизни одной сессии все действия будут проверяться по одному токену.
Если произойдет утечка токена, то злоумышленник сможет выполнить CSRF-Атаку на любой запрос и в течение долгого срока. А это не есть хорошо.
Бесплатная поддержка multi-tab в браузере.
Токен не инвалидируется после выполнения запроса, что позволяет разработчику не заботиться о синхронизации токена в разных табах браузера, так как токен всегда один.
Double Submit Cookie
Этот подход не требует хранения данных на стороне сервера, а значит, является Stateless. Используется, если вы хотите уметь быстро и качественно масштабировать свой Web-сервис горизонтально.
Идея в том, чтобы отдать токен клиенту двумя методами: в куках и в одном из параметров ответа (header или внутри HTML).
При запросе от клиента на стороне сервера генерируется токен. В ответе токен возвращается в cookie (например, X-CSRF-Token ) и в одном из параметров ответа (в header или внутри HTML).
В последующих запросах клиент обязан предоставлять оба полученных ранее токена. Один как cookie, другой либо как header, либо внутри POST данных формы.
Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.
На выходе имеем:
Stateless CSRF защиту.
Таким образом, если ваш сервис доступен на домене 3-го уровня, а злоумышленник имеет возможность зарегистрировать свой ресурс на вашем домене 2-го уровня, то устанавливайте cookie на свой домен явно.
Encrypted Token
Так же как и Double Submit, является Stateless подходом. Основная — если вы зашифруете надежным алгоритмом какие-то данные и передадите их клиенту, то клиент не сможет их подделать, не зная ключа. Этот подход не требует использования cookie. Токен передаётся клиенту только в параметрах ответа.
В данном подходе токеном являются факты, зашифрованные ключом. Минимально необходимые факты — это идентификатор пользователя и timestamp времени генерации токена. Ключ не должен быть известен клиенту.
При запросе от клиента на стороне сервера генерируется токен.
Генерация токена состоит в зашифровке фактов, необходимых для валидации токена в дальнейшем.
Минимально необходимые факты — это идентификатор пользователя и timestamp. В ответе токен возвращается в одном из параметров ответа (В header или внутри HTML).
В последующих запросах клиент обязан предоставлять полученный ранее токен.
Валидация токена заключается в его расшифровке и сравнения фактов, полученных после расшифровки, с реальными. (Проверка timestamp необходима для ограничения времени жизни токена)
Если расшифровать не удалось либо факты не совпадают, считается, что запрос подвергся CSRF-Атаке.
На выходе имеем:
Stateless CSRF защиту
Нет необходимости хранить данные в cookie
О реализации
Давайте генерировать новый токен на каждый запрос, не важно, каким HTTP-методом и с какой целью этот запрос сделан.
Таким образом мы получаем токен, который меняется постоянно.
Конечно, возникает вопрос организации multi-tab работы.
Синхронизация токенов между табами может быть реализована с использованием localStorage и его StorageEvent
Ограничиваем время жизни cookie, которое содержит токен, разумным значением. Например 30 минут.
Делаем cookie недоступной из JS (ставим HTTPOnly=true)
Используем TLS для предотвращения MITM
При этом отправляем cookie только по HTTPS (ставим Secure=true)
Размер токена не менее 32 байт.
Генерируем токен криптографически стойким генератором псевдослучайных чисел.
Для этого можно использовать системные функции:
Что еще нужно знать?
Токены — обязательная защита от CSRF.
Проверяйте, но не полагайтесь только на X-Requested-With: XMLHttpRequest
Не передавайте токены в URL
Same Site
Сейчас идет работа над спецификацией атрибута «Same-Site» у cookies (последняя версия на момент написания статьи).
Такой атрибут даст возможность разработчикам явно указывать, что cookie не нужно передавать, если запрос идет с сайта, отличного от того, на котором cookie была установлена. А, значит, у нас появится возможность защищать ресурсы от CSRF без использования дополнительных инструментов.
Браузер Chrome уже сейчас поддерживает эту возможность.
Чуть больше информации о том, как и почему доступно на Stack Exchange.
Множественные submit для формы
С приходом HTML5 формы сталее более универсальными. Элемент input теперь может содержать электронные адреса, даты и много другое, их можно отмечать как обязательные не прибегая к javascript – и это всего лишь некоторые из наиболее ценных возможностей. Также теперь для одной формы можно задействовать несколько submit кнопок, а также теперь есть возможность вынести кнопку submit за пределы формы.
Несколько submit внутри одной формы
До недавнего времени в форму можно было вставить только одну кнопку submit, в противном случае форма обрабатывала только последнюю кнопку. Добавляя method=»post» и url к элементу формы «form» мы получали рабочую форму.
Теперь ситуация изменилась – в HTML добавили новые свойства «formmethod» и «formaction». Они позволяют добавить метод post и url непосредственно в кнопку «submit», таким образом к form ничего дописывать не нужно. Имея эти параметры, прикрепленные к кнопке «submit», а не к form – все это добавляет больше гибкости форме. Теперь можно сделать столько кнопок, сколько будет необходимо для формы.
Теперь каждая кнопка «submit» относится к разным url и все это избавляет от того, что при верстке необходимо писать javascript код. Все это отлично работает и теперь по нажатии на какую-нибудь кнопку форма получит formmethod и formaction, которые перезапишут стандартные параметры method и action. Если в форме будет присутствовать обычная кнопка «submit» без новых параметров, то он вернет форме значения, установленные для элемента form.
Свойства formmethod и formaction поддерживаются всеми популярными браузерами
Элементы формы (input, select, textarea) за пределами формы
Общепринятый факт, что все элементы формы, принадлежащие ей должны находится внутри элемента
На сегодняшний день аттрибут form поддерживается всеми популярными браузерами, за исключением Internet Explorer (вплоть до 10й версии).
Подскажите защиту от двойного сабмита или от «даблклика» в формах
Привет. У меня такая проблема, да и не только у меня, а у многих: некоторые пользователи отправляя данные через форму (submit) жмыкают эту кнопку по нескольку раз, следовательно данные отправляются тоже по нескольку раз. Искал в интернете решения этой проблемы, но не нашел точного ответа. ( Надеюсь на вашу помощь 🙂 Заранее спасибо
Вот кусочек кода для наглядности
Ответа пока нет
4 комментария
Похожие вопросы
Не могу отыскать вредоносный код!
Изменение кодировки отправляемого через PHP сообщения
Почему, если обновить страницу после отправки формы, то форма отправляется заново?
Как проверить несколько полей сразу на содержание только чисел
Помогите до-составить ЧПУ 2
Что при блокировке submit скриптом форма не отправляется
Вывод мультикатегорий через
Нет не подскажу, в самом редакторе это нужно копаться в его плагинах и искать (или в документации искать ответы, но я сомневаюсь, что такие настройки будут).
А если для вставки из загрузчика то опять же искать код отвечающий за вставку и смотреть как и куда там добавлять отступы.
Это уже сами ищите, никто искать за вас это не будет.
doom45,
Добрый, а где написано, про протокол IndexNow?, прочитайте внимательно
>1. Отправка уведомлений в Google, с помощью Google Indexing API
Да, можно. Пишите в telegram: @skylab_spb
Добрый день, а с каких пор Google поддерживает Indexing Now?
Второй вопрос: можно и у вас заказать модификацию модуля?
Например: у меня есть плагин который меняет alt_name некоторых новостей через cron. Так вот надо будет совместить ваш плагин с моим плагином.
Должно получиться так: cron запускается и alt_name меняется, сразу после этого отправляем запрос Index Now в Google. Такое потянете?
Вышло отдельное дополнение к модулю:
1. Отправка уведомлений в Google, с помощью Google Indexing API
2. Для тех у кого стоят грабберы и новости добавляются напрямую в БД, теперь скрипт решает данную проблему и отправляет уведомления на эти новости
Акция продлиться до 10 января (включительно)
furdarius / csrf-tutorial.md
Что такое CSRF атака?
Ознакомиться с самой идеей атаки CSRF можно на классических ресурсах:
Выдержка из ответа на SO:
Как от нее защититься?
Эффективным и общепринятым на сегодня способом защиты от CSRF-Атаки является токен. Под токеном имеется в виду случайный набор байт, который сервер передает клиенту, а клиент возвращает серверу.
Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.
А что, собственно, защищать?
На Habrahabr опубликована статья от Yandex, в которой описано, почему писать свои сервисы нужно, руководствуясь стандартом.
Требования к токену:
На первом MeetUp’е PDUG Тимур Юнусов (руководитель отдела безопасности банковских систем Positive Technologies) рассказывал, почему именно такие требования предъявляются к CSRF-Токену и чем грозит пренебрежение ими.
Требования к Web-Сервису и окружению:
Отсутствие XSS уязвимостей
Внедренный злоумышленником скрипт имеет возможность отправлять запрос к серверу от имени пользователя и читать его без каких-либо препятствий.
Таким образом, XSS уязвимости могут быть использованы для получения текущего токена.
Отсутствие malware на машине клиента
Если злоумышленник имеет возможность запускать софт на машине клиента, то он может получить любые данные, имеющиеся в браузере.
Существует 3 метода использования токенов для защиты web-сервисов от CSRF атак:
Простой подход, использующийся повсеместно. Требует хранения токена на стороне сервера.
При старте сессии на стороне сервера генерируется токен.
Токен кладется в хранилище данных сессии (т.е. сохраняется на стороне сервера для последующей проверки)
В ответ на запрос (который стартовал сессию) клиенту возвращается токен.
Если рендеринг происходит на сервере, то токен может возвращаться внутри HTML, как, например, одно из полей формы, или внутри тега.
В случае, если ответ возвращается для JS приложения, токен можно передавать в header (часто для этого используют X-CSRF-Token )
При рендере контента сервером токен принято возвращать внутри POST данных формы.
JS приложения обычно присылают XHR запросы с header ( X-CSRF-Token ), содержащим токен.
Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.
Защита от CSRF на хорошем уровне
Токен обновляется только при пересоздании сессии, а это происходит, когда сессия истекает
Во время жизни одной сессии все действия будут проверяться по одному токену.
Если произойдет утечка токена, то злоумышленник сможет выполнить CSRF-Атаку на любой запрос и в течение долгого срока. А это не есть хорошо.
Бесплатная поддержка multi-tab в браузере.
Токен не инвалидируется после выполнения запроса, что позволяет разработчику не заботиться о синхронизации токена в разных табах браузера, так как токен всегда один.
Double Submit Cookie
Этот подход не требует хранения данных на стороне сервера, а значит, является Stateless. Используется, если вы хотите уметь быстро и качественно масштабировать свой Web-сервис горизонтально. Идея в том, чтобы отдать токен клиенту двумя методами: в куках и в одном из параметров ответа (header или внутри HTML).
При запросе от клиента на стороне сервера генерируется токен. В ответе токен возвращается в cookie (например, X-CSRF-Token ) и в одном из параметров ответа (в header или внутри HTML).
В последующих запросах клиент обязан предоставлять оба полученных ранее токена. Один как cookie, другой либо как header, либо внутри POST данных формы.
Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.
Stateless CSRF защиту.
Таким образом, если ваш сервис доступен на домене 3-го уровня, а злоумышленник имеет возможность зарегистрировать свой ресурс на вашем домене 2-го уровня, то устанавливайте cookie на свой домен явно.
Нюансы зависят от реализации
Так же как и Double Submit, является Stateless подходом. Основная — если вы зашифруете надежным алгоритмом какие-то данные и передадите их клиенту, то клиент не сможет их подделать, не зная ключа. Этот подход не требует использования cookie. Токен передаётся клиенту только в параметрах ответа.
Генерация токена состоит в зашифровке фактов, необходимых для валидации токена в дальнейшем.
В последующих запросах клиент обязан предоставлять полученный ранее токен.
Валидация токена заключается в его расшифровке и сравнения фактов, полученных после расшифровки, с реальными. (Проверка timestamp необходима для ограничения времени жизни токена)
Если расшифровать не удалось либо факты не совпадают, считается, что запрос подвергся CSRF-Атаке.
Stateless CSRF защиту
Нет необходимости хранить данные в cookie
Нет нюансов с поддоменами.
Давайте генерировать новый токен на каждый запрос, не важно, каким HTTP-методом и с какой целью этот запрос сделан.
Таким образом мы получаем токен, который меняется постоянно.
Конечно, возникает вопрос организации multi-tab работы.
Синхронизация токенов между табами может быть реализована с использованием localStorage и его StorageEvent
Ограничиваем время жизни cookie, которое содержит токен, разумным значением. Например 30 минут.
Делаем cookie недоступной из JS (ставим HTTPOnly=true)
Используем TLS для предотвращения MITM
При этом отправляем cookie только по HTTPS (ставим Secure=true)
Размер токена не менее 32 байт.
Генерируем токен криптографически стойким генератором псевдослучайных чисел.
Для этого можно использовать системные функции:
Что еще нужно знать?
Проверяйте, но не полагайтесь только на X-Requested-With: XMLHttpRequest
Не передавайте токены в URL
Защищайте все запросы.
Сейчас идет работа над спецификацией атрибута «Same-Site» у cookies (последняя версия на момент написания статьи: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00).
Такой атрибут даст возможность разработчикам явно указывать, что cookie не нужно передавать, если запрос идет с сайта, отличного от того, на котором cookie была установлена. А, значит, у нас появится возможность защищать ресурсы от CSRF без использования дополнительных инструментов.
Браузер Chrome уже сейчас поддерживает эту возможность.