Сомнение в профилактике CSRF

Question

У меня было одно сомнение по поводу профилактики CSRF. Многие сайты говорят, что CSRF можно предотвратить с помощью «токенов», которые генерируются случайным образом за сеанс.

Теперь я сомневаюсь, Предположим, у меня есть такая функция:

$.post("abcd.php",{'fbuid':userid,'code':'<?php echo  md5($_SESSION['randcode']); ?>'}

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

Нет?

Или мое представление о токенах неверно?

Спасибо за вашу помощь: D

Answer 1

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

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

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

Answer 2

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

Следует обратить особое внимание на то, что токен виден любому javascript, запущенному на вашей странице, поэтому, как только у вас появится уязвимость межсайтового скриптинга (XSS), ваша защита CSRF будет побеждена.

См. Межсайтовый скриптинг и таблицу предупреждений

Answer 3

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

1. Создайте токен и сохраните его в сеансе.
2. Передать токен клиенту.
3. Выполнить действия.
4. Уничтожь жетон.

Токен безопаснее и его нельзя использовать более одного раза.

Answer 4

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

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

Это может быть проблема безопасности, если вы отправляете этот токен по незащищенному http. Затем его можно легко украсть, контролируя сеть клиентов.