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 оных не перестал быть виден?
На самом деле, вопрос «А что же делать в подобных ситуациях?» — очень интересный. У меня был опыт взаимодействия с гос. структурами по части уязвимостей, отписывал в тп, писал на различные эл. почты, отвечали до смешного долго: на письмо мог ждать ответа несколько месяцев, но все же отвечали и правили. (Сказав «спасибо» на словах).
Не так давно выходила статья на сайте Ведомостей , в которой говорилось о намерении введения
в апреле государственной программы-аналога Bug bounty, по которой тестирование определенных сервисов будет приветствоваться (и оплачиваться).
Очень интересно узнать мнение других по этому поводу, как считаете, выйдет ли что-то хорошее из этой инициативы али нет?
А как же полные названия релизов указанных вами игр? Многие приведённые в качестве примера игры являются серийным, и конкретно ваши названия нельзя распространить на всю серию, игры в ней( в том числе и гораздо популярнее первых частей) будут иметь более продолжительные названия
Да, недокументированные фичи очень часто оказываются полезными. Причем зачастую создается ощущение, что разработчики начали их введение, но на полпути решили «позабыть» про них
Просто из интереса, про какой инструмент идет речь? Он точно существует? Ничего с подобным названием не гуглится, кроме каких-то проприетарных 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
Если быть точным, какие?
Не так давно выходила статья на сайте Ведомостей , в которой говорилось о намерении введения
в апреле государственной программы-аналога Bug bounty, по которой тестирование определенных сервисов будет приветствоваться (и оплачиваться).
Очень интересно узнать мнение других по этому поводу, как считаете, выйдет ли что-то хорошее из этой инициативы али нет?
Подскажите, пожалуйста, можно ли отнести АИС (автоматизированную информационную систему) федерального органа исполнительной власти к ГИС?