Вопрос уязвимости/куки CSRF

Question

Просто хочу получить информацию от людей, которые знают. Я рассматривал уязвимости CSRF и, по-видимому, самый популярный метод, который я знаю, чтобы бороться с ним. Этот метод заключается в создании маркера в возвращаемом html и добавлении файла cookie с тем же значением. Поэтому, если скрипт пытается сделать сообщение, для него это будет have to guess the token thats embedded in the web page.

Но если они ориентации на определенный веб-сайт, почему они не могут просто использовать сценарий, который

1. Вызывает получить на странице (куки будут возвращены, даже если скрипт не может получить к нему доступ)
2. Анализирует HTML и получает маркер
3. Вызывает сообщение с этой лексемы в нем (печенье, который вернулся, будут отправлены обратно)
4. Они успешно представили форму без ведома пользователей

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

Что мне здесь не хватает? Разве это невозможно? Я думаю, что это довольно страшно, если вы думаете об этом.

Ниже этой линии не требуется чтение, чтобы ответить на этот вопрос :)

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

Еще одно решение, которое я могу придумать, - сделать аутентификацию на уровне страницы. Таким образом, , когда они войдут в возвращенный html, будут иметь этот токен. каждая ссылка, которую они нажимают, содержит этот токен, поэтому, когда веб-сервер получает запрос, у него есть способ идентифицировать пользователя/сеанс. Проблема заключается в том, что если они используют какую-либо навигацию, кроме того, что они будут «неаутентифицированы» (например, введите URL-адрес), также он не выглядит красивым в URL-адресе, потому что он, вероятно, будет выглядеть примерно так:

https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3

Но я понимаю, что если безопасность важнее, то привлекательным URL-адресом является второе место.

Я не знаю все о куках, но что, если пользовательские агенты были немного более осторожны с их куки?

Например, что, если отправленные файлы cookie зависят от вкладки? Теперь мы все используем вкладки, верно? так что, если объем файла cookie был вкладкой? поэтому, если у меня откроется мой банковский сайт на вкладке 1, и я занимаюсь серфингом на вкладке 2, любые вызовы скриптов на/ на вкладке 2 отправят только куки, набранные на вкладке 2.

Или что делать, если куки были сохранены/домен. Поэтому, пока я на example.com, любые файлы cookie, которые возвращаются, попадают в коллекцию cookie example.com. а затем, когда я на www.mybankingsite.com, все куки попадают в коллекцию mybankingsite.com. Поэтому, если я перейду на example.com, и он запускает скрипт, который вызывает get/post, пользовательский агент отправляет только куки example.com. Это отличается от отправки файлов cookie запрашиваемого домена. Например. если скрипт вызывает получение mybankingsite.com на веб-странице example.com, пользовательский агент не отправит куки mybankingsite.com.

Я знаю, что я не имею никакого контроля над тем, что пользователем агентов делают, но я просто изучаю возможность

Answer 1

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

Answer 2

Итак, проблема в том, что проблема заключается в попытке злоумышленника получить содержимое страницы. Чтобы получить страницу аутентифицированного пользователя, злоумышленник должен иметь возможность отправлять запрос от их имени и. AJAX не будет отправлять междоменные запросы, iframe не позволит вам прочитать ответ. Я изо всех сил пытаюсь подумать о других способах, которыми злоумышленник получит содержимое в первую очередь.

Более вероятный взлом - это использование clickjacking, чтобы пользователь просто отправил форму. Этот метод не кажется слишком вероятным. (предостережение: это безопасность, мы всегда можем ошибаться.)

Answer 3

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

В: www.badguy.com/ написать следующий HTML

IMG SRC = "www.goodguy.com/secure/user/delete/5">

Что это значит Итак, администратор отправляется на сайт www.badguy.com/, и изображение отправляет запрос на www.goodguy.com/secure/user/delete/5 из браузера пользователей, поэтому администратор не зная, просто удаленный пользователь. Если вы создадите цикл, вы в какой-то беде. Ожидайте, что я никогда не удаляю данные, просто изменяю свой статус :), но мне все равно не нравится внешний вид этого.