Токены и подделка межсайтовых запросов

Question

Я сталкивался с несколькими другими вопросами о CSRF, но ни один, кажется, не отвечает на мой вопрос. Такое ощущение, что мне чего-то не хватает в том, как работает CSRF.

Пожалуйста, прочитайте весь пост, прежде чем отвечать.

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

Однако, в первую очередь упоминается использование Nonce / One Time Key, встроенного в сеть. page как скрытый параметр формы, поэтому на этом я и фокусируюсь.

Чтобы было ясно, я понимаю, что пытается сделать Nonce, но это также глупо легко победить. Конечно, если злоумышленник может отправить запрос POST на другой сайт, он также может выполнить запрос GET, очистить токен со страницы и просто включить его в свой запрос?

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

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

Пожалуйста, дайте мне знать, где Я не прав.

Спасибо!

Answer 1

CSRF о удаленном злоумышленнике, использующем сеанс, который пользователь проводит с веб-сайтом.

Во-первых, неудачный пример. Вы делаете сеанс с вашим банком (войдите). Войдя в систему, злоумышленник заставляет вас посетить его вредоносный веб-сайт. На вредоносном веб-сайте вы нажимаете удивительную ссылку, чтобы увидеть то, что вам действительно нужно. Однако вредоносный веб-сайт размещает на URL правильные данные для перевода денег злоумышленнику. Вы не хотели этого делать, и веб-сайт, который вы использовали, казалось, не имел никакого отношения к вашему банку. Тем не менее, на сайт банка поступил запрос от вас перевести деньги злоумышленнику. Это работает, потому что у вас уже был сеанс с вашим банком, ваш идентификатор сеанса был сохранен в Cook ie, и куки отправляются на основе целевого URL, независимо от того, где пользователь нажимает (см. Ниже). Это своего рода базовый случай csrf.

Так что, если злоумышленник заставит вас посетить свой вредоносный сайт, почему он не может javascript просто загрузить банковскую страницу в первую очередь и получить токен csrf, когда вы предложено?

Ну, почему он не может просто прочитать ваши банковские реквизиты, номер счета, ваш баланс? По той же причине та же политика происхождения (SOP) веб-браузеров. Если злоумышленник javascript на веб-сайте злоумышленника отправляет запрос на адрес банка, источник запроса отличается от пункта назначения. Вопреки распространенному мнению, запрос будет все еще выполнен, сервер банка получит и обработает его, а также отправит ответ. Однако ваш браузер не позволит вызывающему javascript получить доступ к ответу из другого источника (если только заголовки CORS не отправлены, но это несколько иное, хотя и связанное с этим topi c).

Итак, злоумышленник на его вредоносном веб-сайте нет возможности получить доступ к странице, загруженной пользователем-жертвой из другого источника, и это предотвращает описанную вами атаку. Злоумышленник может, конечно, go опередить и загрузить страницу банка сам, но токен csrf, конечно, будет другим в своей собственной сессии с банком. Но он не может получить токен в сеансе пользователя-жертвы.

Другими словами, токен csrf, созданный на странице и «запомненный» на сервере, позволяет серверу проверять, поступает ли запрос со страницы, которая был фактически сгенерирован сервером. Этот токен не может быть доступен другим веб-сайтам через междоменные запросы из-за SOP.

Обратите внимание, что утверждение выше о том, что куки отправляются независимо от источника запроса, не всегда верно. Атрибут cookie-файлов new-i sh SameSite дает некоторый контроль над тем, куда и куда следует отправлять cookie-файлы, и этот атрибут может эффективно смягчать CSRF в совместимых браузерах с некоторыми последствиями для UX.

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