Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать.
Кто-нибудь может объяснить в чем риск и с чем это связано?
Здравствуйте, __SPIRIT__, Вы писали:
__S>Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать. __S>Кто-нибудь может объяснить в чем риск и с чем это связано?
В том, чтобы если скрипт с какого-нибудь левого сайта придет от вашего имени на gmail.com или вконтактик, его там не приняли бы с распростертыми объятиями.
Здравствуйте, Pzz, Вы писали:
__S>>Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать. __S>>Кто-нибудь может объяснить в чем риск и с чем это связано?
Pzz>В том, чтобы если скрипт с какого-нибудь левого сайта придет от вашего имени на gmail.com или вконтактик, его там не приняли бы с распростертыми объятиями.
проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA.
Здравствуйте, __SPIRIT__, Вы писали:
__S>>>Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать. __S>>>Кто-нибудь может объяснить в чем риск и с чем это связано?
Pzz>>В том, чтобы если скрипт с какого-нибудь левого сайта придет от вашего имени на gmail.com или вконтактик, его там не приняли бы с распростертыми объятиями.
__S>проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA.
Я отвечал на ваш вопрос, "в чем риск и с чем это связано", а не на вопрос "как бы вы решоли эту проблему, если бы вы были золотой рыбкой"
Здравствуйте, Pzz, Вы писали:
__S>>>>Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать. __S>>>>Кто-нибудь может объяснить в чем риск и с чем это связано?
Pzz>>>В том, чтобы если скрипт с какого-нибудь левого сайта придет от вашего имени на gmail.com или вконтактик, его там не приняли бы с распростертыми объятиями.
__S>>проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA.
Pzz>Я отвечал на ваш вопрос, "в чем риск и с чем это связано",
спасибо за ответ
Pzz>а не на вопрос "как бы вы решоли эту проблему, если бы вы были золотой рыбкой"
проблема не выглядит супер не решаемой, удивляет что сверхполезная тема с общедоступным REST API упирается в такую мелочь.
Здравствуйте, __SPIRIT__, Вы писали:
Pzz>>а не на вопрос "как бы вы решоли эту проблему, если бы вы были золотой рыбкой"
__S>проблема не выглядит супер не решаемой, удивляет что сверхполезная тема с общедоступным REST API упирается в такую мелочь.
Ну не то, чтобы совсем упирается. CORS позволяет выразить доверие между доменами.
Жаль, что нет способа послать HTTP-запрос, в котором я мог бы прописать любые поля, в обмен на отсутствие доступа (в процессе формирования запроса и обработки ответа) к не-моему контексту (кукам и проч).
Здравствуйте, __SPIRIT__, Вы писали:
__S>Для REST API по умолчанию сейчас кросдоменные запросы блокируются броузером и их нужно отдельно включать. __S>Кто-нибудь может объяснить в чем риск и с чем это связано?
Проблема в том, что если можно что-то прочитать, то это "что-то" можно потом отправить дальше. Для бытового использования в этом нет проблемы. В корпоративной среде проблема может быть.
Вот допустим у нас есть intranet и внешняя сеть. К *.intranet доступ есть только изнутри. Но при этом из intranet возможен и выход в интернет. Без наличия cross-domain security мой скрипт с моей домашней страничке в интернете может сделать GET-запрос к https://fileserver.intranet/company_achievements.pdf (потому что выполняется на вашей машине в intranet) и потом отправить финансовый отчет на мой сервер в Интернет. Так можно достать данные, не предназначенные для публичного использования.
При наличии интранета часть ресурсов в нем может быть без авторизации но оставаться при этом для служебного пользования. Или может использоваться какая-нибудь схема с доменной аутентификацией (достаточно аутентификации машины в сети, нет никаких дополнительных кук). В отличие от классического CSRF, запрос у нас GET. Далеко не все защищаются от GET-запросов. А если защищаться, это не слишком красиов выглядит, плохо влияет на кэширование и т.п.
Вот в следующей ссылке есть "кросс-доменный доступ" при условии, что строчка где-то в интернете размещена.
При этом в браузере есть и ограничения на доступ к содержимому страницы из скрипта. Внешней скрипт не получит доступа к элементам, загруженным из другого домена. С вызовами из js-кода примерно та же история.
Есть и еще одно приниципиальное отличие cross-domain requests от CSRF. CSRF существовал с самого появления form и post-запросов. Это изначально известная проблема и все приложения разрабатывались (ну или должны были) с учетом ее. А вот xmlhttprequest появился гораздо позже. Если бы кросс-доменные запросы были разрешены, многие приложения или сетевые конфигурации стали бы уязвимы для утечки данных наружу. Заставлять админов обновлять все приложения (добавлять дополнительную авторизацию и бороться с CSRF на get) — очень тяжело и далеко не всегда возможно (могут быть уже не поддерживаемые приложения). Поэтому первый же браузер с подобной фичей был бы запрещен корпоративной политикой. В подходе "запрещать по-умолчанию" такой проблемы нет. При необходимости разработчики разрешат кросс-доменный доступ (раньше jsonp, сейчас — cors).
Подобная ситуация не только в js. Flash-песочница тоже требует кросс-доменных разрешений на загрузку данных (доступных из кода flash). Внешние флешки можно грузить и отображать без ограничений, а вот отрисовать програмно в битмапку без разрешений уже не получится.
Здравствуйте, __SPIRIT__, Вы писали: __S>проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA.
я зашел как-то на anekdot.ru, а потом смотрю — у меня новая группа вконтактике добавилась какая-то левая вообще. офигеть удобно.
Здравствуйте, __kot2, Вы писали:
__S>>проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA. __>я зашел как-то на anekdot.ru, а потом смотрю — у меня новая группа вконтактике добавилась какая-то левая вообще. офигеть удобно.
А где я сказал что нужно игнорировать проблему CSRF? Но лечить можно не только отрубанием головы
Здравствуйте, __kot2, Вы писали:
__S>>проблему csrf, как и любую другую, можно решить отрубанием головы. Но выход ли это? Тем более что та же самая проблема встает перед SPA. __>я зашел как-то на anekdot.ru, а потом смотрю — у меня новая группа вконтактике добавилась какая-то левая вообще. офигеть удобно.
разлогиниваться нужно. да. каждый раз жать logout и завершать сессию.
Здравствуйте, Stanislaw K, Вы писали: SK>разлогиниваться нужно. да. каждый раз жать logout и завершать сессию.
смеетесь, чтоли. неудобно же.
у меня свой метод — я хожу только на те сайты, куда уже ходил раньше
для всего остального интернета у меня есть виртуальная машина с линупсом
