Самое главное, что в случае с phase secret исключается человеческий фактор в этом непростом процессе. Т.е. это скорее решение не технической проблемы, а людской
Вы бы не устали, если бы не растекались мыслью по дереву и не уходили от темы.
Я сейчас тезисно изложу, чтобы вы поняли, что именно вы делаете не так:
1. CSRF-токен не обязан защищать от воровства кук, он лишь защищает от CSRF-атак. Реализация: рандомный сессионный токен
2. От воровства кук защищаемся запоминая в сессии ip и браузер клиента (самый примитивный вариант).
Итого:
1. Это 2 разных способа защиты, которые между собой никак не связаны
2. Наличие одного не подразумевает наличие другого. Именно поэтому фраза «CSRF-токены защищают от воровства кук» некорректно. Не защищают они, защищают другие решения
3. 3 куки не нужны, 1 достаточно, чтобы иметь приложение защищённое как и ваше
Мы и не путали. Изначальный вопрос был «От кражи кук более-менее спасают CSRF токены»
Предполагается, что куки будут сворованы активным XSS. Если XSS есть, тогда CSRF-токены от кражи кук (и вообще чего бы то ни было) не спасают.
С этим вы согласны?
>> Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос
Я боюсь, что вы неправы. Кража куки — это «кража куки», в буквальном смысле получение данных куки другим лицом. Выполнение вредоносного запроса от лица пользователя это не кража, а, к примеру, упомянутая выше атака типа CSRF.
Зачем конкретно она нужна? Что именно с точки зрения безопасности вторая и третья куки добавляют? Что изменится, с точки зрения безопасности, если их не будет?
Если у вас есть кука, которая привязывается к паре браузер-ip, тогда вам не нужна вторая оконная. Она не добавляет к безопасности вообще ничего (только иллюзию, что чем больше кук, тем всё лучше защищено).
Собственно, то, о чём вы сейчас говорите — стандартная защита от session fixation (и ряда родственных атак), и это всё ни с CSRF, ни с CSRF-токеном никак не связано. Вы уверены, что вы продолжаете отвечать на заданный изначально вопрос? Всё таки, пересмотрите, пожалуйста, этот тредик с самого начала.
Про очереди — как только вы перестанете выдумывать термины на ходу, а использовать устоявшиеся, вас сразу начнут понимать.
Это всё прекрасно, но как всё-таки CSRF-токены спасают от кражи кук? (напомню, что в этой ветке мы обсуждаем «От кражи кук более-менее спасают CSRF токены»)
>> кроме случая, когда кража идёт в реальном времени.
Решения или работают, или не работают. Если для того, чтобы ваш клиент был защищён — он обязан бесконечно кликать и никогда не уходить с вашего сайта, то это не защита, а лишь иллюзия.
Прямость рук тут вообще ни при чём, это решение принципиально работает плохо (я уже несколько раз говорил о работе в нескольких вкладках, которые вы так упорно отрицаете).
>> сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере
Вы не путаете «авторизацию» с «аутентификацией»?
Так или иначе, расскажите как реализовать их «правильно», чтобы они работали на любом сферическом сайте, предположим, на хабре.
Защита от CSRF реализуется с помощью CSRF-токенов. Потому они и называются CSRF-токенами, что защищают от CSRF-атак. С помощью них НЕ защищаются от кражи кук.
В RIA, в свою очередь, тоже нет смысла изобретать что-то новое на коленке, потому что есть, как минимум, OAuth
RIA не панацея. Хабр — многостраничный. Если вы сделаете так, как вы предложили, на Хабре, то он сломается.
Про банковский софт — банкинг, которым я пользуюсь, позволяет работать в нескольких вкладках.
Когда я работал в банке и мы писали приклад для операционистов — он тоже работал в нескольких вкладках.
Перегенерация токенов на каждый запрос больше принесёт вреда, чем пользы.
С одной стороны она создаёт иллюзию защищённости (вы надеетесь, что текущий запрос клиента будет не последним, иначе «ой»). С другой стороны — проект перестанет работать, будучи открытым в нескольких вкладках одновременно. И решать эту проблему вы будете созданием не 1 токена, а кучи разных, по одному на форму, страницу, раздел, итд, на что фантазии хватит. И будете их со слезами поддерживать.
Т.е. я не говорю, что сделать в гите это будет сложно, я говорю, что оно защитит вас от ненарочного пуша.
Но, понятно, значит никакой магии
закладки же фактически создают ветвление в пределах одного бренча. Будет ли меркуриал ругаться о новых головах в этом случае? По идее должен.
Как эту проблему пользующиеся букмарками решают?
ps: лично мне ни разу такого не нужно было и я не совсем уверен, что это именно «киллерфича», просто это единственное, что придумывается
Вы бы не устали, если бы не растекались мыслью по дереву и не уходили от темы.
Я сейчас тезисно изложу, чтобы вы поняли, что именно вы делаете не так:
1. CSRF-токен не обязан защищать от воровства кук, он лишь защищает от CSRF-атак. Реализация: рандомный сессионный токен
2. От воровства кук защищаемся запоминая в сессии ip и браузер клиента (самый примитивный вариант).
Итого:
1. Это 2 разных способа защиты, которые между собой никак не связаны
2. Наличие одного не подразумевает наличие другого. Именно поэтому фраза «CSRF-токены защищают от воровства кук» некорректно. Не защищают они, защищают другие решения
3. 3 куки не нужны, 1 достаточно, чтобы иметь приложение защищённое как и ваше
Предполагается, что куки будут сворованы активным XSS. Если XSS есть, тогда CSRF-токены от кражи кук (и вообще чего бы то ни было) не спасают.
С этим вы согласны?
>> Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос
Я боюсь, что вы неправы. Кража куки — это «кража куки», в буквальном смысле получение данных куки другим лицом. Выполнение вредоносного запроса от лица пользователя это не кража, а, к примеру, упомянутая выше атака типа CSRF.
Собственно, то, о чём вы сейчас говорите — стандартная защита от session fixation (и ряда родственных атак), и это всё ни с CSRF, ни с CSRF-токеном никак не связано. Вы уверены, что вы продолжаете отвечать на заданный изначально вопрос? Всё таки, пересмотрите, пожалуйста, этот тредик с самого начала.
Про очереди — как только вы перестанете выдумывать термины на ходу, а использовать устоявшиеся, вас сразу начнут понимать.
Если вы не согласны — будьте немного более конкретны и укажите, в чём именно человек ошибся.
Как вы отличите «настоящего» клиента от злоумышленника, при том что и тот, и другой отправят вам одинаковые наборы куков?
Вы можете конкретно описать процесс, не юля и без прибауток про капитана?
Есть сайт — хабр. Ваше решение?
ps: каким боком тут «очереди» — непонятно (разве что вы опять, как и в случае с CSRF-токеном, термин использовали не к месту)
Решения или работают, или не работают. Если для того, чтобы ваш клиент был защищён — он обязан бесконечно кликать и никогда не уходить с вашего сайта, то это не защита, а лишь иллюзия.
Прямость рук тут вообще ни при чём, это решение принципиально работает плохо (я уже несколько раз говорил о работе в нескольких вкладках, которые вы так упорно отрицаете).
>> сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере
Вы не путаете «авторизацию» с «аутентификацией»?
Так или иначе, расскажите как реализовать их «правильно», чтобы они работали на любом сферическом сайте, предположим, на хабре.
В RIA, в свою очередь, тоже нет смысла изобретать что-то новое на коленке, потому что есть, как минимум, OAuth
Про банковский софт — банкинг, которым я пользуюсь, позволяет работать в нескольких вкладках.
Когда я работал в банке и мы писали приклад для операционистов — он тоже работал в нескольких вкладках.
С одной стороны она создаёт иллюзию защищённости (вы надеетесь, что текущий запрос клиента будет не последним, иначе «ой»). С другой стороны — проект перестанет работать, будучи открытым в нескольких вкладках одновременно. И решать эту проблему вы будете созданием не 1 токена, а кучи разных, по одному на форму, страницу, раздел, итд, на что фантазии хватит. И будете их со слезами поддерживать.