На самом деле, OWASP подтверждает, что такая защита имеет место быть (раздел: Protecting REST Services: Use of Custom Request Headers)
Но есть уточнение, что такой вид защиты был уязвим с использованием Flash. И прилагается ссылка на репорт об уязвимости на Vimeo: https://hackerone.com/reports/44146
Таким образом, по версии OWASP, для обеспечения необходимого уровня защиты необходимо дополнительно проверять заголовки Origin и Referer (впрочем, как и при любом другом методе).
Т.е., на сегодняшний день, при условии наличия у пользователя новейшего софта, этот вид защиты действительно хорош. Он включает в себя все плюсы stateless и при этом требует минимум усилий на реализацию.
В интернетах можно увидеть разные мысли на тему такой защиты.
А по поводу CORS, нужно понимать, что сам по себе он не предоставляет защиты от CSRF. Вот, например, ответ на SO о том, почему CORS не совсем верно интерпретируют: http://security.stackexchange.com/a/97938
Еще раз уточню: защищать необходимо небезопасные методы, к которым относятся: POST, PUT, DELETE, PATCH.
В целом, всё сводится к тому, что, кроме данных в сookies, необходимо послать данные о текущем CSRF-токене вторым путём. Это может быть post-data (для форм) или доп. заголовок.
Если вы говорите о подходе Synchronizer Tokens, то тут токен-эталон просто храним на сервере (в данных сессии), а токен-валидатор посылаем клиенту например в header или, если шаблон генерируется на сервере, прямо в html'e.
Т.е. при таком подходе явно хранить в cookie CSRF-токен не нужно.
Таким образом, в запросе с другого ресурса будет ID сессии, но не будет самого CSRF-токена, так как он не должен приходить внутри cookies.
P.S. Если не очень понятна идея, то говорите, не стесняйтесь, я попытаюсь написать подробнее.
Да, всё верно. Поэтому, надо четко понимать, где и что использовать. В случае подхода Encrypted Token шифрование обязательно. В остальных случаях нужно просто подписать данные. Для этого, может быть использован механизм HMAC.
Используемая хеш-функция — дело личное. От её выбора будет зависеть скорость генерации токена.
Конечно, при прочих равных, подписать быстрее, чем зашифровать.
В статье предложил, как можно синхронизировать:
Но есть уточнение, что такой вид защиты был уязвим с использованием Flash. И прилагается ссылка на репорт об уязвимости на Vimeo: https://hackerone.com/reports/44146
Таким образом, по версии OWASP, для обеспечения необходимого уровня защиты необходимо дополнительно проверять заголовки Origin и Referer (впрочем, как и при любом другом методе).
Т.е., на сегодняшний день, при условии наличия у пользователя новейшего софта, этот вид защиты действительно хорош. Он включает в себя все плюсы stateless и при этом требует минимум усилий на реализацию.
Другой вопрос, а у всех ли пользователей софт действительно новейший… (http://caniuse.com/#search=CORS)
В интернетах можно увидеть разные мысли на тему такой защиты.
А по поводу CORS, нужно понимать, что сам по себе он не предоставляет защиты от CSRF. Вот, например, ответ на SO о том, почему CORS не совсем верно интерпретируют: http://security.stackexchange.com/a/97938
В целом, всё сводится к тому, что, кроме данных в сookies, необходимо послать данные о текущем CSRF-токене вторым путём. Это может быть post-data (для форм) или доп. заголовок.
Если вы говорите о подходе Synchronizer Tokens, то тут токен-эталон просто храним на сервере (в данных сессии), а токен-валидатор посылаем клиенту например в header или, если шаблон генерируется на сервере, прямо в html'e.
Т.е. при таком подходе явно хранить в cookie CSRF-токен не нужно.
Таким образом, в запросе с другого ресурса будет ID сессии, но не будет самого CSRF-токена, так как он не должен приходить внутри cookies.
P.S. Если не очень понятна идея, то говорите, не стесняйтесь, я попытаюсь написать подробнее.
Используемая хеш-функция — дело личное. От её выбора будет зависеть скорость генерации токена.
Конечно, при прочих равных, подписать быстрее, чем зашифровать.