Вопросы безопасности Bookmarklet, CSRF, хешированный ключ

Question

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

Теперь я хочу включить защиту CSRF для своего сайта и с тех порБукмарклет - это, по сути, не поддельный межсайтовый запрос, я подумал о том, как отличить его от поддельных.
Это не среда с высоким уровнем безопасности, но я также заинтересован в принципе.

Я думал, что у меня есть способ сделать это, выяснил, но потом понял, что у него были проблемы в изобилии.

Оригинальная идея

• создать случайный ключ, который включен в ссылку на букмарклет,Хеш ключа сохраняется в базе данных.Случайный ключ позволяет получить доступ ТОЛЬКО к привилегии вставки в эту коллекцию и не может использоваться где-либо еще.
• букмарклет загружает более длинный скрипт с моего сервера, поэтому я мог предоставить токен предотвращения CSRF таким образом
• требует, чтобы пользователь вошел в систему

Проблемы

• Если у меня есть ключ bookmarklet, нужны ли мне токены counter-CSRF?
• Можно ли как-нибудь защитить ключ букмарклета, если пользователь щелкнет его букмарклет на вредоносном веб-сайте?
• Я не хочу, чтобы имя пользователя и пароль сохранялись в ссылке на букмарклет, потому что любой, кто имееттогда доступ к компьютеру получал бы и пароль, поэтому я выбрал случайный ключ.
  • но если я храню только хэш, я не могу сгенерировать одну и ту же ссылку на букмарклет дважды, поэтому, когда пользователь хочет добавить букмарклет в другой браузер / компьютер, ему утомительно приходится импортировать ссылку из старого или прервать поддержкустарый.
  • но я не должен хранить ключ открытого текста, потому что тот, кто получает доступ к базе данных, может использовать этот ключ для вставки строк в учетные записи, которые ему не принадлежат.
  • Возможное решение Я мог бы попросить пользователя предоставить свой пароль в любое время, когда он создает букмарклет и хеширует пароль много раз, вставит этот хеш в URL и добавит хэш этого хеша.база данных.Но, конечно, это открывает гораздо худшие дыры в безопасности.
    • Вместо этого я мог бы сделать что-то вроде "Девичья фамилия матери"
    • Я не могу использовать bcrypt для хеширования из-за случайной соли, верно?Какая хеш-функция будет правильной?Или вы бы отклонили всю идею?
• Если я опущу ключ букмарклета, вредоносный веб-сайт может просто встроить букмарклет и извлечь из него действительный токен CSRF.Не так ли?

Лучшие идеи?Или у вас не может быть CSR без F?

---

Редактировать, указанный вариант использования

Одна вещь, о которой я просто не задумывался, - это использование iframe, предложенногоСрипати Кришнан.

Я не указал свой вариант использования, так что да, iframe - это правильное решение вышеупомянутой проблемы.

Однако на самом деле мой букмарклет в настоящий момент выполняет некоторые основные действия.с веб-сайтом во время выполнения (то есть форма уже существует, и пользователь может изменить свой выбор в DOM веб-сайта, который должен изменить форму).Я готов отклонить эту функциональность для моего варианта использования, если он окажется, что нет достаточно надежного способа отличить поддельные от не поддельных межсайтовых запросов - но я все еще заинтересован на теоретическом уровне.

Answer 1

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

Предположим, что ваш сервис позволяет пользователям добавлять закладки на любые страницы, которые он пожелает.Работа букмарклета заключается в сохранении {url, title} в базе данных.В то же время вы хотите запретить вредоносному веб-сайту автоматически сохранять URL-адреса для пользователя, вошедшего в систему.

Вот что я хотел бы сделать, чтобы решить эту проблему -

1. Создать страницуна вашем домене, который имеет стандартную форму HTML с регулярной защитой CSRF.Эта страница принимает параметры {url, pagetitle}, но сохраняет этот кортеж только тогда, когда пользователь явно нажимает кнопку «Сохранить».
2. Задача букмарклета - загрузить iframe
3. Onceiframe загружается, это обычный запрос того же источника

Это более или менее то, что Google reader делает как часть своего букмарклета.Вот код его букмарклета - обратите внимание, что у него нет никаких токенов

javascript:
var b=document.body;
var GR________bookmarklet_domain='http://www.google.com';
if(b&&!document.xmlVersion) {
  void(z=document.createElement('script'));
  void(z.src='http://www.google.com/reader/ui/link-bookmarklet.js');
  void(b.appendChild(z));
 }
 else{}

РЕДАКТИРОВАТЬ: вы все еще можете поддерживать взаимодействия с подходом iframe.Букмарклет выполняется в контексте веб-сайта, поэтому у него есть доступ к DOM.Вы можете взаимодействовать с сайтом как хотите.Когда вы будете готовы сохранить, откройте Iframe.Iframe будет своего рода экраном подтверждения только с одной кнопкой сохранения.

Хитрость заключается в задержке создания iframe.Вы создаете iframe только тогда, когда пользователь готов сохранить.

Answer 2

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

Если букмарклет исходит от стороннего сайта, то вы ничего не можете сделать. Это определение CSRF.