Ctrl + D в бесплатной версии Adobe Acrobat Reader есть уже как 300 лет, не благодарите. Еще когда в энергетике работал, выяснял так названия объектов, которые "обезличенно" присылали. Тогда же и очистку метаданных себе реализовал, чтобы этого избежать самому.
И мы говорим, что X < Z < Y, так? И при этом мы, как я описывал, хотим отслеживать инвалидацию токена, чтобы уметь разрывать соединения?
Тут можно, кмк, рассмотреть несколько подходов в зависимости от задачи, например
Делать время жизни WS-соединения всегда меньшим, чем время жизни access token (насколько помню, я делал так)
Если у вас "сессией приложения" выступает refresh token, а не access token, можно подумать над тем, чтобы как-то связывать соединения с ним
Принять, что токен может истечь, а соединение продолжить какое-то время быть активным
Тут смотря какая специфика и нагрузка, наверное. Я полагал, что во многих случаях лишний раз "перезагрузить" WS-соединение для проверки актуальности кредов - не такая большая проблема.
Да, это справедливое высказывание. Часто мы вынуждены находить компромисс с точки зрения НФТ между безопасностью и иными требованиями, например, к производительности. Поэтому и пишу, что подходы существуют разные, все со своими особенностями. Но если требования к ИБ в конкретном случае играют бОльшую роль, то подобные практики уместны, ну или по крайней мере полезно их держать в уме при проектировании.
Влияние на latency и на нагрузку на authorization server имеется, безусловно, и я это старался подчеркнуть. Однако, каким оно будет - зависит от различных факторов. В том числе и от того, с чем мы сравниваем. Здесь не зря рассмотрел такой механизм именно на примере схемы, когда мы уже ходим с API Gateway в authorization server, расширяя назначения такого "похода за обменом токенов". Да, можно сказать, что кто-то кэширует у себя на стороне authorization server созданные JWT, а здесь нужно будет создавать новые, но это уже частный случай, как думаю.
Более того, для отдельных групп API или клиентов можно принять быстродействие важнее безопасности, и использовать для них отличный подход.
потоку операций генерации электронной подписи, которая, обычно значительно медленней проверки
На всякий случай еще добавлю, что здесь, насколько мне известно, это зависит от используемого алгоритма. Так для алгоритмов, основанных на эллиптических кривых, генерация подписи может быть быстрее проверки.
То есть мы усложняем и замедляем систему вместо простого правила "отправлять/принимать внутренние запросы только через гейтвей*?
Здесь не могу согласиться, что это "простое" правило. Использование API Gateway для east-west трафика, то есть межсервисных запросов, возможно, но всегда оправдано и применимо. К тому же существуют разные подходы к разработке и нарезанию API: например, иногда одни и те же API могут использоваться как для внешних запросов, так и для внутренних (сейчас не говорю, плохо это или хорошо, но сам факт). Поэтому да, если есть возможность добавить дополнительные ограничения, это может работать, но здесь старался рассмотреть вопрос на более низком уровне с точки зрения наделения учетных данных, которые нужны для выполнения операции, минимальным набором необходимых полномочий.
А в финальном решении он куда-то исчез?
Нет, все верно, суть не меняется. Здесь имел в виду, что принципиально добавление еще одного уровня абстракции не решает всех проблем.
Лет пять назад активно пользовался тогда еще Сбермаркетом и делал userJS для решения аналогичной задачи. Кстати, можете посмотреть пример варианта размещения блока с ценой за единицу измерения.
Скриншоты (могут вызвать приступ ностальгии от цен)
1. Миниатюры товаров в плитке
2. Всплывающее окно детальной карточки товара
3. Выпадающие подсказки при поиске
4. Страница "Избранное"
Подобные селекторы действительно будут часто отваливаться, поэтому в то время обычно искал некоторый "стабильный" элемент и от него уже городил цепочки вида
el.querySelectorAll('div>div>div>span')[0]
Или использовал частичные селекторы а-ля [attribute^=value] , как предлагает коллега ниже. А вообще, да, работа с уже готовым кодом современных фронтендов - это то еще развлечение)
Правильно понял, что взяли в стек Oathkeeper в качестве API gateway? Если еще будет статья про это, интересно узнать, как и почему выбрали его, под какие именно задачи подошел. Раньше мнения были неоднозначные, некоторые писали, что продукт сыроват.
Вообще в комьюнити очень не хватает реальных кейсов использования Kratos/Hydra, было бы интересно почитать про опыт реализации и поддержки боевого решения:
Решали ли вопрос мультитенантности/мульти-realm, что Kratos из коробки не поддерживает
Какие впечатления от работы с кодовой базой, насколько удобно расширение функциональности
Вопросы масштабирования и работы под реальной нагрузкой, возможно, особенности работы с БД
Опыт организации деплоймента под Kratos
Анализ с точки зрения ИБ, есть ли нюансы
С какими еще проблемами можно столкнуться при разработке и эксплуатации
Статья действительно на уровне "Крутые приколы ВКонтакте 2010", конечно. Теперь про все баги 15-летней давности пора по новой статьи писать? Хоть ретроспективу бы включить тогда, чтобы можно было поностальгировать Списки подобных id вузов с того времени и существуют, хотя подозреваю, что значительно поредевшие.
Пример
У меня вот за 2011 год нашлась заметка с такими списками id'шников. Кажется, ~ до 2009 можно было писать свои без enum, потом уже использовали те, что создали ранее. Популярным городом для таких вузов, кстати, был Hong Kong. Еще же есть такие же школы, войсковые части и пр. Или жир в заметках вспомнить, авось еще работает.
YAML Designer. Онлайн-редактор для общих конфигураций YAML с компонентами пользовательского интерфейса.
Просто из интереса, про какой инструмент идет речь? Он точно существует? Ничего с подобным названием не гуглится, кроме каких-то проприетарных DevOps-инструментов Azure:
Для аутентификации запроса — достаточно, это как раз один из доступных способов.
Однако остается вопрос контроля валидности соединения. Поскольку в данном случае природа передаваемых сообщений асинхронна и само HTTP-соединение остается открытым в течение некоторого времени, у нас все так же имеется риск передать некую важную информацию в сообщениях, даже если токен по любой причине будет инвалидирован. Инвалидация токена по истечении максимального времени жизни — это часто не единственная причина, есть, например, тот же логаут (выход по инициативе пользователя), отзыв токена в связи с различными событиями.
Естественно, степень критичности данного риска для каждого своя, допускаю, что в ряде приложений последствия могут быть не такими серьезными.
Да, как раз говорю про бэкенд прокси или сервис воркер. Ну и смотря, про что мы говорим, имея в виду "запросить токен заново", если про использование refresh-токена, то я выше в другой цепочке написал пример мер для повышения безопасности его использования.
Я был уверен, что такое поведение является требованием стандарта, но как оказалось нет - OAuth2 даже не требует заменять refresh токен при перевыпуске access.
Да, я согласен, что было бы здорово это добавить в стандарт, чтобы повысить безопасность ванильных имплементаций. На текущий момент это отражено в драфте OAuth 2.0 Security Best Current Practice, который пока еще не стал RFC.
если при этом клиентский код (а значит, и XSS) все так же способен запросить этот токен заново
Здесь встает вопрос того, как у нас реализован запрос токенов и кто за ними обращается. Если это вынесено за рамки клиентской части, например, то такой трюк не пройдет.
можно привязать токен к айпи-адресу клиента или еще какому-то фингерпринту
Подход с привязкой сессий к IP-адресу был распространен в 2010-х годах, однако сейчас кажется применимым в более ограниченной области использования. Наша мобильность повысилась, мы можем при работе с веб-приложением переключиться с мобильного интернета на Wi-Fi, например, включить или отключить VPN. В таком случае при привязке к IP мы ощутимо жертвуем удобством пользователей.
Использование refresh-токена - пример известного компромисса между безопасностью и удобством пользователей, поэтому и стоит вопрос подбора его времени жизни.
Мне лично для их использования нравится совмещение ротации с защитой от переиспользования. Ротация refresh-токенов подразумевает, что при обращении с ним за получением access token мы получаем в ответе не только сам access token, а также и новый refresh token. При этом у нас получается некое "семейство" refresh-токенов, которые все идут от одного своего родителя.
И тогда, если у нас, скажем, злоумышленник похитил refresh token 2, а пользователь с ротацией уже получил следующий refresh token 3 мы можем сделать следующее: злоумышленник обращается с refresh token 2 за получением access token, мы видим, что происходит попытка переиспользования refresh token 2, который уже был использован, и инвалидируем все семейство этих токенов, поскольку мы не знаем, кто с каким к нам обращается, ведь это такие же Bearer-токены (если не используется другой подход).
О, у меня был Wave 525, использовал аж до 2014 года =) Помню, что там можно было делать виджеты на HTML на коленке, я себе делал мордочку для загрузки файлов на сервер, чтобы скриншотами с телефона делиться, было очень удобно. Из приложений запомнил приложение для чтения башорга, служило одним из немногих развлечений тогда.
Что бы получить доступ к содержимому https запросов, помимо настроек прокси, в свойствах подключения смартфона, нужно дополнительно установить доверенный сертификат, который генерирует программа.
Могу заблуждаться, но разве после какой-то версии Андроида https-трафик с приложений без пересборки .apk оных не перестал быть виден?
Ctrl + D в бесплатной версии Adobe Acrobat Reader есть уже как 300 лет, не благодарите. Еще когда в энергетике работал, выяснял так названия объектов, которые "обезличенно" присылали. Тогда же и очистку метаданных себе реализовал, чтобы этого избежать самому.
Если правильно понимаю, условия такие:
Время жизни access token = X
Время жизни refresh token = Y
Время жизни WS-соединения = Z
И мы говорим, что X < Z < Y, так? И при этом мы, как я описывал, хотим отслеживать инвалидацию токена, чтобы уметь разрывать соединения?
Тут можно, кмк, рассмотреть несколько подходов в зависимости от задачи, например
Делать время жизни WS-соединения всегда меньшим, чем время жизни access token (насколько помню, я делал так)
Если у вас "сессией приложения" выступает refresh token, а не access token, можно подумать над тем, чтобы как-то связывать соединения с ним
Принять, что токен может истечь, а соединение продолжить какое-то время быть активным
Тут смотря какая специфика и нагрузка, наверное. Я полагал, что во многих случаях лишний раз "перезагрузить" WS-соединение для проверки актуальности кредов - не такая большая проблема.
Да, это справедливое высказывание. Часто мы вынуждены находить компромисс с точки зрения НФТ между безопасностью и иными требованиями, например, к производительности. Поэтому и пишу, что подходы существуют разные, все со своими особенностями. Но если требования к ИБ в конкретном случае играют бОльшую роль, то подобные практики уместны, ну или по крайней мере полезно их держать в уме при проектировании.
Влияние на latency и на нагрузку на authorization server имеется, безусловно, и я это старался подчеркнуть. Однако, каким оно будет - зависит от различных факторов. В том числе и от того, с чем мы сравниваем. Здесь не зря рассмотрел такой механизм именно на примере схемы, когда мы уже ходим с API Gateway в authorization server, расширяя назначения такого "похода за обменом токенов".
Да, можно сказать, что кто-то кэширует у себя на стороне authorization server созданные JWT, а здесь нужно будет создавать новые, но это уже частный случай, как думаю.
Более того, для отдельных групп API или клиентов можно принять быстродействие важнее безопасности, и использовать для них отличный подход.
На всякий случай еще добавлю, что здесь, насколько мне известно, это зависит от используемого алгоритма. Так для алгоритмов, основанных на эллиптических кривых, генерация подписи может быть быстрее проверки.
Здесь не могу согласиться, что это "простое" правило. Использование API Gateway для east-west трафика, то есть межсервисных запросов, возможно, но всегда оправдано и применимо. К тому же существуют разные подходы к разработке и нарезанию API: например, иногда одни и те же API могут использоваться как для внешних запросов, так и для внутренних (сейчас не говорю, плохо это или хорошо, но сам факт). Поэтому да, если есть возможность добавить дополнительные ограничения, это может работать, но здесь старался рассмотреть вопрос на более низком уровне с точки зрения наделения учетных данных, которые нужны для выполнения операции, минимальным набором необходимых полномочий.
Нет, все верно, суть не меняется. Здесь имел в виду, что принципиально добавление еще одного уровня абстракции не решает всех проблем.
Лет пять назад активно пользовался тогда еще Сбермаркетом и делал userJS для решения аналогичной задачи. Кстати, можете посмотреть пример варианта размещения блока с ценой за единицу измерения.
Скриншоты (могут вызвать приступ ностальгии от цен)
1. Миниатюры товаров в плитке
2. Всплывающее окно детальной карточки товара
3. Выпадающие подсказки при поиске
4. Страница "Избранное"
Подобные селекторы действительно будут часто отваливаться, поэтому в то время обычно искал некоторый "стабильный" элемент и от него уже городил цепочки вида
Или использовал частичные селекторы а-ля
[attribute^=value], как предлагает коллега ниже. А вообще, да, работа с уже готовым кодом современных фронтендов - это то еще развлечение)Спасибо за статью.
Правильно понял, что взяли в стек Oathkeeper в качестве API gateway? Если еще будет статья про это, интересно узнать, как и почему выбрали его, под какие именно задачи подошел. Раньше мнения были неоднозначные, некоторые писали, что продукт сыроват.
Вообще в комьюнити очень не хватает реальных кейсов использования Kratos/Hydra, было бы интересно почитать про опыт реализации и поддержки боевого решения:
Решали ли вопрос мультитенантности/мульти-realm, что Kratos из коробки не поддерживает
Какие впечатления от работы с кодовой базой, насколько удобно расширение функциональности
Вопросы масштабирования и работы под реальной нагрузкой, возможно, особенности работы с БД
Опыт организации деплоймента под Kratos
Анализ с точки зрения ИБ, есть ли нюансы
С какими еще проблемами можно столкнуться при разработке и эксплуатации
"Колесо сансары делает оборот"
Статья действительно на уровне "Крутые приколы ВКонтакте 2010", конечно. Теперь про все баги 15-летней давности пора по новой статьи писать? Хоть ретроспективу бы включить тогда, чтобы можно было поностальгировать
Списки подобных id вузов с того времени и существуют, хотя подозреваю, что значительно поредевшие.
Пример
У меня вот за 2011 год нашлась заметка с такими списками id'шников. Кажется, ~ до 2009 можно было писать свои без enum, потом уже использовали те, что создали ранее. Популярным городом для таких вузов, кстати, был Hong Kong.
Еще же есть такие же школы, войсковые части и пр. Или жир в заметках вспомнить, авось еще работает.
p.s. qweqwe, привет
При итоговой оценке в этом году эти категории будут влиять на что-то?
Просто из интереса, про какой инструмент идет речь? Он точно существует? Ничего с подобным названием не гуглится, кроме каких-то проприетарных DevOps-инструментов Azure:
Hidden text
Для аутентификации запроса — достаточно, это как раз один из доступных способов.
Однако остается вопрос контроля валидности соединения. Поскольку в данном случае природа передаваемых сообщений асинхронна и само HTTP-соединение остается открытым в течение некоторого времени, у нас все так же имеется риск передать некую важную информацию в сообщениях, даже если токен по любой причине будет инвалидирован. Инвалидация токена по истечении максимального времени жизни — это часто не единственная причина, есть, например, тот же логаут (выход по инициативе пользователя), отзыв токена в связи с различными событиями.
Естественно, степень критичности данного риска для каждого своя, допускаю, что в ряде приложений последствия могут быть не такими серьезными.
По данной теме могу порекомендовать следующую статью: https://cheatsheetseries.owasp.org/cheatsheets/Microservices_security.html (не смотрите, что OWASP, там не только про безопасность)
Да, как раз говорю про бэкенд прокси или сервис воркер. Ну и смотря, про что мы говорим, имея в виду "запросить токен заново", если про использование refresh-токена, то я выше в другой цепочке написал пример мер для повышения безопасности его использования.
Да, я согласен, что было бы здорово это добавить в стандарт, чтобы повысить безопасность ванильных имплементаций. На текущий момент это отражено в драфте OAuth 2.0 Security Best Current Practice, который пока еще не стал RFC.
Здесь встает вопрос того, как у нас реализован запрос токенов и кто за ними обращается. Если это вынесено за рамки клиентской части, например, то такой трюк не пройдет.
Подход с привязкой сессий к IP-адресу был распространен в 2010-х годах, однако сейчас кажется применимым в более ограниченной области использования. Наша мобильность повысилась, мы можем при работе с веб-приложением переключиться с мобильного интернета на Wi-Fi, например, включить или отключить VPN. В таком случае при привязке к IP мы ощутимо жертвуем удобством пользователей.
Использование refresh-токена - пример известного компромисса между безопасностью и удобством пользователей, поэтому и стоит вопрос подбора его времени жизни.
Мне лично для их использования нравится совмещение ротации с защитой от переиспользования. Ротация refresh-токенов подразумевает, что при обращении с ним за получением access token мы получаем в ответе не только сам access token, а также и новый refresh token. При этом у нас получается некое "семейство" refresh-токенов, которые все идут от одного своего родителя.
И тогда, если у нас, скажем, злоумышленник похитил refresh token 2, а пользователь с ротацией уже получил следующий refresh token 3 мы можем сделать следующее: злоумышленник обращается с refresh token 2 за получением access token, мы видим, что происходит попытка переиспользования refresh token 2, который уже был использован, и инвалидируем все семейство этих токенов, поскольку мы не знаем, кто с каким к нам обращается, ведь это такие же Bearer-токены (если не используется другой подход).
вернули 2007
О, у меня был Wave 525, использовал аж до 2014 года =)
Помню, что там можно было делать виджеты на HTML на коленке, я себе делал мордочку для загрузки файлов на сервер, чтобы скриншотами с телефона делиться, было очень удобно. Из приложений запомнил приложение для чтения башорга, служило одним из немногих развлечений тогда.
Скриншоты
Могу заблуждаться, но разве после какой-то версии Андроида https-трафик с приложений без пересборки .apk оных не перестал быть виден?
www.anti-malware.ru/news/2011-07-25/4373