Используете токен сеанса или одноразовый номер для защиты от подделки межсайтовых запросов (CSRF)? - PullRequest
10 голосов
/ 03 августа 2011

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

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

Однако здесь все еще чувствуется какая-то уязвимость. Хотя я понимаю, что ничто не на 100% безопасно, у меня есть несколько вопросов:

  • Не мог ли потенциальный злоумышленник просто запустить действительный сеанс, а затем включить идентификатор сеанса (через cookie) в каждый из своих запросов?
  • Кажется, nonce будет лучше, чем маркер сеанса . Каков наилучший способ генерировать и отслеживать nonce ?
  • Я сталкивался с некоторыми моментами, когда эти решения были только одним окном. Может ли кто-нибудь уточнить этот момент?
  • Эти решения всегда требуют сеанса? Или эти токены могут быть созданы без сеанса? ОБНОВЛЕНИЕ , эта конкретная страница представляет собой одностраничную форму (без входа в систему). Так что запуск сеанса только для генерации токена кажется чрезмерным.
  • Существует ли более простое решение (не CAPTCHA), которое я мог бы реализовать для защиты от этой конкретной атаки, которая не использовала бы сеансы.

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

1 Ответ

9 голосов
/ 03 августа 2011

Насколько я понимаю, вам нужно сделать три вещи: сделать все действия с изменяющимися данными доступными только с помощью запроса POST, запретить запросы POST без действительного реферера (он должен быть из одного домена) и проверять токен аутентификации в каждомPOST-запрос (значение POST-токена должно совпадать с токеном в cookie-файле).

Первые два затруднят выполнение любого вредоносного запроса CSRF, поскольку они обычно являются скрытыми изображениями в электронных письмах, на других сайтах и ​​т. Д., И выполнение междоменного запроса POST с действующим реферером должно быть невозможным / трудным для выполнения.делаю в современных браузерах.Благодаря этому совершенно невозможно совершить какое-либо вредное действие без кражи файлов cookie пользователя / перехвата его трафика.

Теперь о ваших вопросах:

  1. Этот вопрос действительно смущает меня: если выпри правильном использовании токенов аутентификации злоумышленник должен знать токен пользователя из файла cookie, чтобы отправить его вместе с запросом, так почему запуск собственного сеанса действительного злоумышленника может принести вред?
  2. Одноразовые ссылки сделают все ваши ссылки уродливыми - я никогда не виделкто-нибудь их больше использует.И я думаю, что ваш сайт можно дозировать, используя его, поскольку вы должны сохранять / искать все существительные в базе данных - много запросов на создание существительных может очень быстро увеличить размер вашей базы данных (и поиск их будет медленным).
  3. Если вы разрешите только одно существительное для каждого user_id, чтобы предотвратить (2) Dos-атаку, то если пользователь откроет страницу, затем откроет другую страницу и затем отправит первую страницу - его запрос будет отклонен, так как было создано новое существующее и староеуже недействительно.
  4. Как еще вы можете идентифицировать уникального пользователя без идентификатора сеанса, будь то cookie, переменная GET или POST?

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

  1. Скрытые поля формы, которые не должны заполняться (боты обычно заполняют большинство полей формы, которые, как они видят, имеют хорошие имена, даже если они действительно скрыты для пользователя)
  2. трекеры мыши Javascript (вы можете анализировать записанные мышиvements для обнаружения ботов)
  3. Анализ журналов запросов файлов (при загрузке страницы javascript / css / images в большинстве случаев следует загружать тоже, но у некоторых (действительно редких) пользователей это отключено)
  4. Изменения формы Javascript (когда к форме добавляется скрытое (или нет) поле с javascript, который требуется на стороне сервера: боты обычно не выполняют javascript)
  5. Инструменты анализа трафика, такие как Snort, для обнаруженияШаблоны ботов (странные пользовательские агенты, слишком быстрая отправка форм и т. Д.).

и более, но в конце дня некоторые современные боты используют полную эмуляцию поведения реального пользователя (используя настоящий браузерAPI-вызовы) - так что если кто-то действительно хочет атаковать ваш сайт, никакая защита не поможет вам.Даже CAPTCHA сегодня не очень надежна - помимо сложных алгоритмов распознавания изображений вы можете теперь купить 1000 CAPTCHA, решенных человеком, для любого сайта всего за 1 доллар (такие услуги можно найти в основном в развивающихся странах).Так что на самом деле нет 100% защиты от ботов - каждый случай индивидуален: иногда вам придется создавать сложную систему защиты самостоятельно, иногда поможет небольшая настройка.

...