У меня есть сайт, на котором будет отображаться конфиденциальная информация. Я использую токены Anti Forgery и т. Д. Для защиты от XSRF в POSTS. Однако меня беспокоит, что кто-то сможет просматривать конфиденциальную информацию из GET. Какова рекомендуемая практика для защиты данных только для чтения, отправленных через GET в .Net MVC 2?
Защита XSRF GET .net mvc
Ответы (2)
Если вы уверены, что GET запросы доступны только для чтения, то вам не о чем беспокоиться по поводу XSRF. Невозможно украсть информацию с другого веб-сайта, используя только XSRF, и поэтому вам не нужно защищать URL-адреса с помощью токена. Фактически, использование токенов в URL-адресе сделает невозможным использование закладок.
При этом вы должны быть на 100% уверены, что в вашем приложении нет XSS-уязвимостей. Если есть, злоумышленнику не нужно беспокоиться о XSRF и непредсказуемых токенах.
person
Sripathi Krishnan
schedule
13.09.2010
Если это форма submit, которая изменяет данные, то это должен быть POST, за которым следует перенаправление на URL-адрес GET. Если это форма submit, которая действует только как своего рода фильтр, она все равно может быть GET, и нет причин жертвовать URL-адресами для закладок.
- person Sripathi Krishnan; 13.09.2010
Меня беспокоит следующий сценарий. Другой сайт уязвим для XSS (или это вредоносный сайт, доступ к которому осуществляется через социальную инженерию). Пользователь вошел на мой сайт и переходит на вредоносный сайт, это делает запрос GET javascript, например, для учетных записей / индекса и теперь имеет копию списка учетных записей, которую он может незаметно отправить обратно на другой веб-сервер.
- person Matthew Hood; 14.09.2010
Злоумышленник всегда может сделать GET-запрос со своего сайта, но он не может прочитать ответ благодаря той же политике происхождения в браузере. Это справедливо независимо от того, какую клиентскую технологию он использует - XmlHttpRequest, тег формы, Flash, Silverlight или любой из нескольких других способов сделать запрос GET. Если вы не создаете банковское приложение, вам не нужно ничего делать для запросов GET, которые не имеют побочных эффектов.
- person Sripathi Krishnan; 14.09.2010
Спасибо, что прояснили это, я буду читать больше о той же политике происхождения. Кажется, паника зря: D
- person Matthew Hood; 14.09.2010
Защита XSRF для данных POST (с использованием токенов, как вы сказали) должна работать и с данными GET. С точки зрения хакера подделка GET намного проще, чем подделка POST (сначала вы публикуете только ссылку, а во втором - вам нужно указать на вредоносный веб-сайт со скрытыми формами iframe и autosubmit), но оба они терпят неудачу, если токены проверяются.
Пример: размещение такой ссылки:
www.domain.tld / page.aspx? get = data & token = token_given_to_hacker
не должен ничего возвращать, или просто ошибка для тех, у кого есть другие токены. Таким образом, в отношении неправильных людей не производится никаких деликатных действий.
Это xsrf, с его помощью вы не можете украсть информацию, но заставите других отправлять формы и предпринимать действия, о которых знают только хакеры. Например: изменение адреса электронной почты в форме электронной почты на электронную почту хакера. Предположим, у вас есть форма GET с одним полем: новый адрес электронной почты (для простоты). При отправке URL-адрес выглядит так:
www.domain.tld/[email protected]
Теперь, если хакер разместит ссылку на вашем форуме с URL-адресом:
www.domain.tld/[email protected]
Каждый, кто нажмет на нее, получит новое письмо от хакеров. Но если вы поместите туда токен и будете проверять его каждый раз, действие будет выполняться только для тех, кому тот же токен был указан при запросе страницы, в этом случае ссылка будет работать только для пользователя, который ее разместил, и никто другой.
Вы также можете защитить конфиденциальные формы, такие как изменение электронной почты, пароля и т. Д., С помощью поля пароля. Обратите внимание, что капча здесь не очень помогает.
person
Máthé Endre-Botond
schedule
13.09.2010
