Обработка сеансов во время входа в систему с защитой от XSRF (межсайтовый запрос-подделка) в GWT - PullRequest
Новая
       20

Обработка сеансов во время входа в систему с защитой от XSRF (межсайтовый запрос-подделка) в GWT

6 голосов
/ 13 июня 2011

Я реализовал простое приложение GWT, включающее службу входа в систему (LoginService) и службу работника (WorkerService). Оба GWT-RPC. Я защитил все службы от XSRF, внедрив последнюю версию GWT XsrfProtectedServiceServlet (см. GWT Xsrf-Безопасный пример проекта ).

При реализации этого примера идентификатор сеанса создается в файле JSP сразу после загрузки страницы. В этом случае, даже если пользователь не входит в систему.

Это правильный подход? Или я должен создать идентификатор сеанса (установка cookie) в сервисе LoginService? Но при такой реализации не будет ли сам LoginService уязвим для атаки XSRF?

Спасибо, Pascal

1 Ответ

6 голосов
/ 13 июня 2011

Сначала краткий обзор XSRF:

  • Пользователь переходит на some-attacker.com/evil.html
  • evil.html содержит, например, тег <img> (или некоторый JavaScript, который отправляет форму POST, ...) с URL "www.your-nice-site.com/doSomeAction"
  • Это позволяет браузеру пользователя автоматически отправлять на ваш сайт запрос GET или POST и выполнять действие от имени пользователя. К сожалению, файлы cookie пользователя для www.your-nice-site.com также отправляются автоматически вместе с запросом, поэтому (и вот в чем проблема) , если пользователь вошел в систему, запрос приходит как полностью авторизован пользователем на вашем сервере (то есть, если вашему серверу не требуется дополнительный токен анти-XSRF).

Теперь легко увидеть, что XSRF нельзя использовать для атаки на саму службу входа в систему, потому что в этот момент пользователь еще не авторизован - злоумышленник должен знать учетные данные пользователя для входа в систему. (Если пользователь уже вошел в систему, то вызов службы входа в систему ничего не должен делать! [*])

Примечание. Конечно, злоумышленник может использовать другие методы для атаки на учетные данные пользователя, в частности: фишинг. Анти-XSRF меры не могут защитить вас от этого.

[*] Если у вас есть сервисы, которые нельзя защитить токеном анти-XSRF (например, сервисом входа в систему), то особенно всегда следите за тем, чтобы они не возвращали valid JSON / JavaScript, содержащий какие-либо ценная информация!

Если вам абсолютно необходимо, всегда оберните ответ в комментарии JavaScript (/* */), как описано в http://code.google.com/webtoolkit/articles/security_for_gwt_applications.html#json. Или даже лучше: добавьте в ответ while(1);, как объяснено в Почему есть «while (1);» в ответе XmlHttpRequest? . В любом случае, это хорошая практика.

...