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

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

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

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

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

No ?

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

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


csrf csrf-protection
person Hormigas    schedule 23.08.2011    source источник
comment
вероятно, вам нужно зашифровать и передать данные   -  person kobe    schedule 23.08.2011
comment
@kobe ммм, да, это можно сделать, но тогда мне понадобится очень сильный алгоритм шифрования, не так ли? и поскольку его можно было бы расшифровать, если только это не что-то вроде md5, следовательно, это не будет очень безопасно - вот о чем я думал   -  person Hormigas    schedule 23.08.2011
comment
Ничего себе, вам нужно прочитать о CSRF, потому что вы понятия не имеете.   -  person rook    schedule 24.08.2011

Ответы (4)


arrow_upward
4
arrow_downward

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

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

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

person Amir Raminfar    schedule 23.08.2011
comment
Также верно, что вы должны уничтожать токен каждый раз. Но это только защищает от повторных атак. - person Amir Raminfar; 23.08.2011
comment
Некоторые бумаги не предлагают уничтожить его. Мы сделали его уничтожаемым после каждого запроса, чтобы клиент был доволен. Но на самом деле это сработает. Вам просто нужно убедиться, что секретный токен нельзя вывести из идентификатора файла cookie. - person Amir Raminfar; 23.08.2011
comment
Хорошее чтение shiflett.org/articles/cross-site-request-forgeries php, но та же идея. - person Amir Raminfar; 23.08.2011
comment
@Amir Raminfar: Большое спасибо за этот ответ: D Если я сделаю что-то простое, например, просмотр исходного кода для любого кода, создаст ли он новый сеанс: O? Потому что любой может легко просмотреть мой исходный код HTML. - person Hormigas; 23.08.2011
comment
@ Анант да, если ВЫ просматриваете источник, это так. Но мы не защищаемся от вас! Мы защищаемся от автоматического бота, который будет читать html-страницу. У этого бота будет другой сеанс. Зачем нам защищать ВАС, если вы авторизованы. - person Amir Raminfar; 24.08.2011
comment
@Amir Raminfar: Против ботов я понимаю, но что, если пользователь попытается использовать это для одного успешного вредоносного запроса? Спасибо - person Hormigas; 24.08.2011
comment
@ Анант, я думаю, ты должен объяснить мне, как кто-то это сделает. Если за вашим компьютером сидел злоумышленник, то он может делать что угодно. Дайте мне скан, где кто-то, кто не сидит за вашим компьютером, может сделать вредоносный запрос. - person Amir Raminfar; 24.08.2011
comment
@Amir Raminfar, значит, злоумышленник не может отправлять POST-запросы на мой сервер, не находясь на моем компьютере? - person Hormigas; 24.08.2011
comment
Если вы сидите за компьютером, вы можете делать все, что угодно. Если злоумышленник каким-то образом получит ваш токен, ему также понадобится ваш идентификатор сеанса. Даже тогда ваш токен будет отличаться от чужого токена, потому что это другой сеанс. Так что нет, никак. :) - person Amir Raminfar; 24.08.2011
comment
@Amir Raminfar В последний раз: предположим, что пользователь открывает страницу, щелкает правой кнопкой мыши и просматривает источник страницы. Затем он получает токен для текущего сеанса. Он открывает другую вкладку и использует токен со своим собственным вредоносным скриптом. Таким образом, сессия не повреждена, а токен тоже украден! Как это можно предотвратить? Спасибо за терпение. Я новичок в веб-безопасности! :) - person Hormigas; 24.08.2011
comment
@Anant, пользователь сидит за компьютером? Если так, то да, это возможно. Вы не можете защитить это. Если вы оставите свою электронную почту открытой, а я сижу за вашим компьютером, то это ошибка пользователя. Если вы по-прежнему используете токен с другого компьютера, он не будет работать, поскольку это ваш собственный сеанс. Я думаю, ты сбит с толку, потому что продолжаешь думать о ком-то, сидящем за твоим компьютером. Это не CSRF. - person Amir Raminfar; 24.08.2011

arrow_upward
3
arrow_downward

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

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

См. раздел Межсайтовый скриптинг и шпаргалка по профилактике

person Cheekysoft    schedule 24.08.2011
comment
ладно, кажется, я начинаю понимать. Спасибо большое за вашу помощь - person Hormigas; 24.08.2011

arrow_upward
1
arrow_downward

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

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

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

person Rahman Kalfane    schedule 23.08.2011
comment
Спасибо за ответ. Как уничтожить токен? Есть ли способ запустить скрипт, с помощью которого я мог бы уничтожить токен, как только моя веб-страница потеряет фокус? Меня больше всего беспокоит то, что токен можно легко скопировать и использовать снова, при этом сеанс не будет уничтожен каким-либо механизмом, как описано выше. - person Hormigas; 23.08.2011
comment
Ну, вы можете уничтожить токен, когда он используется. Например, когда вы получаете POST с токеном, вы удаляете его из сеанса, чтобы его нельзя было использовать снова. - person Rahman Kalfane; 23.08.2011
comment
Что, если человек просто видит код токена из моего запроса $.post() и использует его на какой-то другой вкладке. Таким образом, ни одна сессия не будет уничтожена, а токен тоже не будет поврежден :| - person Hormigas; 24.08.2011
comment
Если он использует токен на вашем сервере, он уничтожается. Хакер может просто получить еще один токен, обновив страницу, но это предотвратит автоматические атаки. - person Rahman Kalfane; 24.08.2011
comment
Зачем уничтожать токен при каждом запросе? Если вы создаете токен, который имеет те же свойства, что и идентификатор сеанса (безопасная случайная и правильная длина), то этот токен имеет те же свойства, что и идентификатор сеанса. Единственный способ, которым злоумышленник может получить токен в этом случае, — это либо сниффинг сети, либо через XSS, но если у вас есть XSS, CSRF-защита в любом случае не работает. И да, используйте SSL. Из приложения AJAX уничтожение токена каждый раз, когда он используется, может стать проблемой, так как вам придется отслеживать, какой текущий действительный токен, при выполнении нескольких одновременных асинхронных операций. Запросы. - person Erlend; 24.08.2011
comment
Кстати. вы можете поместить токен в заголовок вместо параметра POST, если вы используете jQuery: erlend .oftedal.no/blog/?blogid=118 - person Erlend; 24.08.2011
comment
Я чувствую себя в большей безопасности с одним токеном доступа. Потому что мы используем их для внешних вызовов API, которым мы не очень доверяем. Но я согласен, что это больно управлять. - person Rahman Kalfane; 24.08.2011

arrow_upward
0
arrow_downward

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

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

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

person kapex    schedule 24.08.2011