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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

По адресу: www.badguy.com/ написать следующий html

img src = "www.goodguy.com/secure/user/delete/5">

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

Answer 3

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