Понимание CSRF
Я не понимаю, как использование 'маркера проблемы' добавило бы любой вид предотвращения: какое значение должно по сравнению с какой?
От OWASP:
В целом разработчики должны только генерировать этот маркер однажды для текущей сессии. После начального поколения этого маркера значение хранится на сессии и используется для каждого последующего запроса, пока сессия не истекает.
Если я понимаю процесс правильно, это - то, что происходит.
Я вхожу в систему по http://example.com, и сессия/cookie создается содержащий этот случайный маркер. Затем каждая форма включает скрытый вход, также содержащий это случайное значение от сессии, которая является по сравнению с сессией/cookie после представления формы.
Но что это выполняет? Разве Вы не просто взятие данных сессии, помещение его на странице и затем сравнении его с теми же самыми данными сессии? Походит на круговое обоснование. Эти статьи продолжают говорить о следующем "политика того-же-источника", но это не имеет никакого смысла, потому что все нападения на CSRF ИМЕЮТ тот же источник как пользователь, просто обманув пользователя в выполнение действий, которые он не предназначал.
Действительно ли там кто-либо альтернативен кроме добавления маркера к каждому URL как строка запроса? Кажется очень ужасным и непрактичным, и делает установку закладки тяжелее для пользователя.
3 ответа
Злоумышленник не может получить токен. Следовательно, запросы не будут иметь никакого эффекта.
Я рекомендую этот пост от Gnucitizen. У него довольно приличное объяснение CSRF: http://www.gnucitizen.org/blog/csrf-demystified/
Вам нужно продолжать исследовать эту тему самостоятельно, но я думаю, именно поэтому вы пишете в SO :). CSRF - очень серьезный и широко распространенный тип уязвимости, о котором должны знать все разработчики веб-приложений.
Прежде всего, существует более одной одинаковой политики происхождения . Но самая важная часть заключается в том, что сценарий, размещенный на http://whatever.com , не может ЧИТАТЬ данные с http://victom.com , но он может ОТПРАВИТЬ данные через POST и получить. Если запрос содержит только информацию, известную злоумышленнику, то злоумышленник может подделать запрос в браузере жертвы и отправить его куда угодно . Вот 3 эксплойта XSRF , которые создают запросы, не содержащие случайный токен.
Если сайт содержит случайный токен, вам необходимо использовать XSS, чтобы обойти защиту, которую обеспечивает политика одного происхождения. Используя XSS, вы можете заставить javascript «исходить» из другого домена, затем он может использовать XmlHttpRequest для чтения токена и подделки запроса. Вот описанный мной эксплойт , который делает именно это.
Есть ли альтернатива, кроме добавления токена к каждому URL в виде строки запроса? Выглядит очень некрасиво и непрактично и усложняет создание закладок для пользователя.
Нет причин добавлять токен к каждому URL-адресу на вашем сайте, до тех пор, пока вы гарантируете, что все запросы GET на вашем сайте доступны только для чтения. Если вы используете запрос GET для изменения данных на сервере, вам придется защитить его с помощью токена CSRF.
Самое забавное в CSRF заключается в том, что, хотя злоумышленник может сделать любой HTTP-запрос к вашему сайту, он не может прочитать ответ.
Если у вас есть URL-адреса GET без случайного токена, злоумышленник сможет сделать запрос, но не сможет прочитать ответ. Если этот URL-адрес изменил какое-либо состояние на сервере, работа злоумышленников завершена. Но если просто сгенерировал какой-то html, злоумышленник ничего не получил, а вы ничего не потеряли.