Предотвращение подделки межсайтовых запросов - никогда не полагайтесь на идентификатор SessionID, отправленный на ваш сервер в заголовке cookie

Question

Я читаю учебник на

http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

В нем говорится

Помните - вы никогда не должны полагаться на sessionID отправляется на ваш сервер в заголовок cookie; смотреть только на sessionID, который отправляет ваше приложение GWT явно в полезной нагрузке сообщений на ваш сервер.

Используется ли для предотвращения http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

С этой мифологией достаточно ли этого, чтобы предотвратить атаку выше?

Answer 1

Да, этого достаточно, чтобы предотвратить подделку межсайтовых запросов.

Идентификатор сеанса в файле cookie нельзя доверять. Допустим, пользователь вошел на mysite.com, а идентификатор сеанса находится в файле cookie. Теперь пользователь нажимает на ссылку на evilsite.com. evilsite.com имеет такой код

<img src="http://mysite.com/transfermoney.jsp?amount=1000.." />

Браузер отправит запрос на mysite.com, и , а также отправит файл cookie с идентификатором сеанса. Здесь нужно понять, что evilsite.com не может прочитать cookie, но он все еще может выполнить свою работу.

Политика браузера того же происхождения запрещает evilsite.com читать идентификатор сеанса, независимо от того, находится ли он в файле cookie или встроен в HTML-страницу. Но поскольку браузер автоматически отправляет cookie на ваш сервер , даже если ресурс был запрошен из HTML-кода в другом домене , у вас есть XSRF.

Для предотвращения этого рекомендуется указывать идентификатор сеанса в качестве параметра запроса. Если его добавить в качестве параметра запроса, evilsite.com не сможет получить доступ к идентификатору и, следовательно, не сможет поместить его в атрибут img src.

Однако помните, что если на вашем сайте есть уязвимости XSS, ничто не может помешать вам XSRF. Другими словами, если у вас есть уязвимости XSS, злоумышленник даже не захочет делать XSRF.