Внедрение нового способа работы, который затрагивает много людей всегда дело политически сложное. В целом «лампочка должна хотеть вкрутиться». Мне это казалось очевидным, но за идею спасибо, такое на самом деле происходит сплошь и рядом.
Да, DevOps официально movement/движение, методологией тут назван время от времени чтобы не повторять одно и то же слово. По поводу нераскрытых мифов буду признателен если укажете какие и в каком смысле, это мне действительно будет полезно. Спасибо!
Тут терминологическая путаница.
«Self-XSS» — это, строго говоря, не совсем XSS, это гораздо больше и вообще о другом. Это выполнение произвольного кода в консоли. Этот код может, например, выполнять GET, а затем POST-запрос. С точки зрения вектора атаки на приложение — это будет CSRF. Да, можно было бы попытаться провести XSS самого сайта (но сложнее т.к. проще поместить «рекомендации» по действиям с консолью на другой сайт). Ваш сайт даже может выводить предупреждение в консоль, как Фейсбук, ему это не поможет.
TL;DR; Мой пример не про XSS.
Я привёл примеры именно способов осуществления CSRF-атаки, у самого приложения собственных XSS-уязвимостей может и не быть. А для CSRF javascript и social engineering применять не запрещено.
Но постить-то заполненную сможет, при помощи специальных утилит, например. Или вот заходит пользователь на какой-то сайт, а там появляется popup с формой, и форма отправляется, за долю секунды. Или даже такое.
Ну например на форме скрытое поле с anti-CSRF-токеном, выданным сервером. И делать shareable полузаполненную форму смысла большого нет, и проблема с CSRF постинга форм решена.
Вот не в первый раз встречаю утверждение, что приложения на токенах не нужно защищать от CSRF.
Тут внезапно не всё так очевидно. Вообще говоря, приложения, которые получают доступ к ресурсу на основе Bearer-токенов обычно защищённее, т.к. атакующий не может полагаться на стандарт раз, и access_token'ы обычно делают живущими недолго два. Однако, если у вас SPA с восстановлением текущего состояния из URL, при атаке через CSRF может так случится, что приложение прекрасно восстановит контекст из URL и localStorage, а затем сделает нужный хакеру запрос.
Так что такие приложения, вообще говоря, труднее атаковать — да, но защищать именно от CSRF-атак их тоже нужно.
В принципе, ощущение игрушечности существующих туториалов и было одной из мотиваций того, что я написал yet another. По моей задумке, он должен быть в этом смысле лучше.
Вы в любом случае будете делать пентесты, скорее всего ещё и будете использовать автоматические.
Ну во-первых, ни моя статья, ни мои комментарии не содержат предложений использовать JWT для сессий.
Во вторых, статью я читал, она ИМХО построена по старому-доброму принципу "вначале хорошенько передёрнуть, потом всё эмоционально развенчивать". Нормальное обсуждение статьи тут. Если любите такой жанр, можете почитать ещё эту.
Спасибо за замечание. Статья писалась в свободное от прочей работы время, затем некоторое время болталась на модерации, я не заметил, что Брок запушил апдейт Quickstart UI в сентябре.
Меня смутило «Я уже писал, от XSS не спасает ничего.» по поводу CSRF-примера.
«Self-XSS» — это, строго говоря, не совсем XSS, это гораздо больше и вообще о другом. Это выполнение произвольного кода в консоли. Этот код может, например, выполнять GET, а затем POST-запрос. С точки зрения вектора атаки на приложение — это будет CSRF. Да, можно было бы попытаться провести XSS самого сайта (но сложнее т.к. проще поместить «рекомендации» по действиям с консолью на другой сайт). Ваш сайт даже может выводить предупреждение в консоль, как Фейсбук, ему это не поможет.
TL;DR; Мой пример не про XSS.
Но постить-то заполненную сможет, при помощи специальных утилит, например. Или вот заходит пользователь на какой-то сайт, а там появляется popup с формой, и форма отправляется, за долю секунды. Или даже такое.
Есть такое.
По остальному согласен. Ну и anti-CSRF-токены различные.
Тут внезапно не всё так очевидно. Вообще говоря, приложения, которые получают доступ к ресурсу на основе Bearer-токенов обычно защищённее, т.к. атакующий не может полагаться на стандарт раз, и access_token'ы обычно делают живущими недолго два. Однако, если у вас SPA с восстановлением текущего состояния из URL, при атаке через CSRF может так случится, что приложение прекрасно восстановит контекст из URL и localStorage, а затем сделает нужный хакеру запрос.
Так что такие приложения, вообще говоря, труднее атаковать — да, но защищать именно от CSRF-атак их тоже нужно.
Ну во-первых, ни моя статья, ни мои комментарии не содержат предложений использовать JWT для сессий.
Во вторых, статью я читал, она ИМХО построена по старому-доброму принципу "вначале хорошенько передёрнуть, потом всё эмоционально развенчивать". Нормальное обсуждение статьи тут. Если любите такой жанр, можете почитать ещё эту.
Спасибо за замечание. Статья писалась в свободное от прочей работы время, затем некоторое время болталась на модерации, я не заметил, что Брок запушил апдейт Quickstart UI в сентябре.
Возможно, но я лично придерживаюсь в этом вопросе принципа "never roll your own".