Запрет CSRF (или подделка межсайтовых запросов / XSRF) для службы WCF с включенным Silverlight - PullRequest
Новая
       0

Запрет CSRF (или подделка межсайтовых запросов / XSRF) для службы WCF с включенным Silverlight

0 голосов
/ 08 августа 2011

Связь службы WCF с поддержкой Silverlight защищена с помощью USB-токена / смарт-карты.Первый доступ должен быть подтвержден путем ввода PIN-кода.После проверки подлинности вредоносный веб-сайт может запускать CSRF-запросы к службе WCF с использованием IMG-тегов и / или JavaScript.В соответствии с Руководством по безопасности при написании и развертывании приложений Silverlight , обычным способом здесь является использование (сеансовых) токенов или так называемого «nonce», хотя проверка заголовка HTTP Referrer оказалась небезопасной.

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

Есть ли у вас какие-либо советы, как я могудолжен защищать связь Silverlight с WCF для предотвращения CSRF-атак, гарантируя, что уже аутентифицированный вызывающий абонент запрашивает доверенный сайт?

1 Ответ

0 голосов
/ 16 августа 2011

Один из вариантов может быть:

  1. Предоставляет сервис, который при вызове создает одноразовый номер и сохраняет его в сеансе пользователей на сервере и возвращает его вызывающему приложению
  2. В каждом запросе после этого включайте одноразовый номер в качестве параметра URL или в тело запроса POSTed (или в любой другой тип используемого вами сообщения)
  3. Проверять этот одноразовый номер для каждого запроса к серверу

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

...