Юра, привет! Интересная статья. Так получилось, что я сам недавно проводил подобное же исследование, даже подумывал о своей собственной статье, но как обычно, не хватает на все времени - напишу здесь, так как случай интересный и на мой взгляд, может привести к реальной угрозе:
Выполнял секюрити ревью мобильного приложение заказчика, и обратил внимание что в трафике прилетает OAuth2.0 Auth Code в диплинке, написал свой POC, подписавшись на схему в диплинке, получилось перехватить запрос приложения, и если выбрать мой POC то удавалось стянуть AuthCode. Но сам код все же бесполезен, без CodeVerifier так как используется PCKE, однако я решил подумать дальше, что тут можно сделать.
И придумал следующее. Если мы создаем малишес приложение, замаскированное под что то полезное, то в процессе аутентификации в наше хорошее приложение возникает неожиданное окно с выбором приложение, и если пользователь ошибся и выбрал неправильное приложение (например название похожее и значок), то открылось наше приложение, в котором мы имитируем форму авторизации, на которой только что находился пользователь (так что для него нет в этом неожиданности), и показываем фейковое сообщение, что "Ошибка авторизации, авторизуйтесь еще раз". Пользователь вводит свои креды, и все они утекли.
Как кейс, на мой взгляд выглядит валидным. Из за особенности реализации используется именно диплинк и само событие по вызову диплинки не рандомное, а вполне конкретное и пользователь не будет удивлен несвоевременностью запроса кредов.
Со всем согласен с написанным, хотел добавить один момент, не упомянутый в статье, для митигации этой и подобных проблем:
Как механизм защиты от подобных манипуляций с диплинками, для приложений, хорошим решением будет при запуске приложения, выполнять проверку на наличие на этом устройстве других приложений, подписанных на диплинку, которая уникальна для нашего приложения с помощью PackageManager.queryIntentActivities и при обнаружении либо вывести предупреждение для пользователя о наличии проблемы безопасности, либо полностью заблокировать запуск.
Надеюсь мой комментарий немного дополнит твою прекрасную заметку.
Вот может в этом разница, не хочу вас задеть, но я просто работаю в команде где аппсек выстраивался более 17 лет, через многие вещи уже прошли и многое показало свою несостоятельность, и от этого отказались, либо наоборот как рабочий вариант и его и придерживаемся.
В целом конечно же нет единственно верного пути и какого то 100% верного решения, много зависит от объема проекта/ов и кодовой базы, наличия сильной аппсек команды, вменяемости разработчиков и т.д...
Далее, дабы не утонуть в спорах, в которых не всегда рождается истина, пожелаю вам и вашей команде удачи в этом нелегком деле :)
Если были найдены новые файндинги, разработчик имеет возможность перейти в каждую джобу с результатами и сделать анализ.
Если конкретный файндинг подтверждается, он переходит в статус уязвимости, разработчик ее исправляет.
Если файндинг не подтверждается, т.е. разработчик посчитал его «фолсом», разработчик добавляет исключение для этого файндинга в отдельном репозитории в виде MR'а.
Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec или его очень мало и он просто перегружен.
Подход, когда найденные секюрити проблемы, отправляются на анализ разработчику имеет ряд недостатоков. Для начала, как правило пайплайн един и в данной схеме отправляются как сикреты, так и какие то более сложные моменты, которые требуют знаний именно в аппсеке. В вашем случае, если дефект условно подтвердился, но разработчик его не правильно интерпретировал и неправильно исправил, то это возможно прошло мимро аппсека? (по схеме не очень понятно), если даже нет, то это увеличивает цепочку взаимодействий. Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа, и если дефект подтверждается, то в результате чего согдается дефект в виде документа, с рядом нужных полей, серьезность, описание с т.з. безопасности, т.е. то к чему может привести уязвимость, а так же с рекомендацией по устранению, что позволит помочь выбрать разработчику верное решение по устранению дефекта.
UPDATE:
"{пункт со звездочкой} внедрить QG и по возможности внедрить возможность блокировки релизов в случае несоблюдения политик ИБ."
Вот этот пункт, тоже по факту не жизнеспособен в реальности. Очень сложно настроить все так, чтобы блокировки всегда были обоснованы. А если произошла блокировка, а аппсек на обеде? С т.з. бизнеса это решение может привести к большим издержкам, и в целом снизит репутацию аппсек в компании. Здесь нужны другие меры.
Нашел дыру на вашем сайте (розыгрыш призов на черную пятницу), опубликовал на openbugbounty, но они так долго верифицировали ее (зачем то в ручную), что уже все закончилось, страница стала недоступна и они реджектнули репорт об уязвимости :))
А вы не думали, что она не пользуется популярностью, просто потому, что strapi у нас просто еще не набрал популярность? Возможно ваш перевод, просто немного опередил время :) И наоборот поспособствует популяризации strapi в русскоязычном сообществе. Гугл по запросто strapi+habr выдает вашу первую статью одну из первых))
По поводу лайтовая — ну я не знаю. На хабре полным полно статей для новичков, различных helloworld и прочего… и все они несут свою полезность.
Возможно просто не стоит реагировать на некоторых комментаторов?) Кто то вообще например не признает тех документацию на русском, а читают все всегда только в исходниках, так что, теперь перестанем вообще выпускать тех документацию на русском? :)
Потому что у нас это гонки для самих пилотов, а не для публики. К сожалению сделать зрелищьными гонки дронов очень не просто. DRL очень немало денег в это вкладывают, у нас спонсоров не найти на это, большинство на энтузиазме делается, либо при скромных бюджетах, в которую просто не входит медиа-освещение на достойном уровне — в лучшем случае любительские стримы и отчетные видео, которые расползаются по тематическим пабликам.
Есть у меня похожая рука, собранная на основе такой штуковины.
Тоже написал для ардуины прошивку и програмку для винды, которая использовала для управления радио джойстик. На саму клешню поставил микрокамеру с видео передатчиком, а сам сидел в другом месте и по камере, джлйстиком выполнял какие то манипуляции рукой, например печатал на клавиатура или перетасиквал предметы…
На как то быстро наигрался и убрал все в шкаф… применение ей так и не нашел :(
Я как сотрудник ИБ КПС (Крупнейшего банка страны), так и не понял о чем вы тут ведете речь. В чем собственно автоматизация.
Возможно ваша статья имеет какой то смысл, но похоже для очень узкого круга людей, даже из числа сотрудников ИБ.
PS на сколько я знаю принятая аббревиатура для СрЗИ — просто СЗИ.
Ну во первых да — на пару км, во вторых шимом яркость подстраивать. Ардуина подключена к Naza V2, поэтому ардуина будет знать расстояние и высоту квадра. То есть яркость строба будет меняться в зависимости от удаления квадра. Если он близко будет то будет вообще выключаться или работать на минималке.
Очень своевременная статья (для меня). Прямо сегодня озадачился этим вопросом — нужно поставить 4 мощных светодиода на квадр TBS Discovery в режиме стробоскопа (поэтому выбрал 10W и буду их ставить без радиатора). На борту самодельная ардуина мелкая уже есть, так что буду к ней цеплять.
Код врят ли пригодится, а вот 20 полевичков уже заказал на Ali… :)
Зачем калечить ардуину? Только из за экономии кода? Вы этим самым лишаетесь всех ардуиновских «плюшек».
Хотите чистого С на AVR — можно плату под 328ю мегу сделать за час… и кодить ее.
В дополнение статьи описали бы как потом наигравшись восстановить все обратно. Ну я про залить бутлоадер и выставить фьюзы под ардуину.
Юра, привет! Интересная статья. Так получилось, что я сам недавно проводил подобное же исследование, даже подумывал о своей собственной статье, но как обычно, не хватает на все времени - напишу здесь, так как случай интересный и на мой взгляд, может привести к реальной угрозе:
Выполнял секюрити ревью мобильного приложение заказчика, и обратил внимание что в трафике прилетает OAuth2.0 Auth Code в диплинке, написал свой POC, подписавшись на схему в диплинке, получилось перехватить запрос приложения, и если выбрать мой POC то удавалось стянуть AuthCode. Но сам код все же бесполезен, без CodeVerifier так как используется PCKE, однако я решил подумать дальше, что тут можно сделать.
И придумал следующее. Если мы создаем малишес приложение, замаскированное под что то полезное, то в процессе аутентификации в наше хорошее приложение возникает неожиданное окно с выбором приложение, и если пользователь ошибся и выбрал неправильное приложение (например название похожее и значок), то открылось наше приложение, в котором мы имитируем форму авторизации, на которой только что находился пользователь (так что для него нет в этом неожиданности), и показываем фейковое сообщение, что "Ошибка авторизации, авторизуйтесь еще раз". Пользователь вводит свои креды, и все они утекли.
Как кейс, на мой взгляд выглядит валидным. Из за особенности реализации используется именно диплинк и само событие по вызову диплинки не рандомное, а вполне конкретное и пользователь не будет удивлен несвоевременностью запроса кредов.
Со всем согласен с написанным, хотел добавить один момент, не упомянутый в статье, для митигации этой и подобных проблем:
Как механизм защиты от подобных манипуляций с диплинками, для приложений, хорошим решением будет при запуске приложения, выполнять проверку на наличие на этом устройстве других приложений, подписанных на диплинку, которая уникальна для нашего приложения с помощью PackageManager.queryIntentActivities и при обнаружении либо вывести предупреждение для пользователя о наличии проблемы безопасности, либо полностью заблокировать запуск.
Надеюсь мой комментарий немного дополнит твою прекрасную заметку.
Вот может в этом разница, не хочу вас задеть, но я просто работаю в команде где аппсек выстраивался более 17 лет, через многие вещи уже прошли и многое показало свою несостоятельность, и от этого отказались, либо наоборот как рабочий вариант и его и придерживаемся.
В целом конечно же нет единственно верного пути и какого то 100% верного решения, много зависит от объема проекта/ов и кодовой базы, наличия сильной аппсек команды, вменяемости разработчиков и т.д...
Далее, дабы не утонуть в спорах, в которых не всегда рождается истина, пожелаю вам и вашей команде удачи в этом нелегком деле :)
Вот с этим не соглашусь:
Если были найдены новые файндинги, разработчик имеет возможность перейти в каждую джобу с результатами и сделать анализ.
Если конкретный файндинг подтверждается, он переходит в статус уязвимости, разработчик ее исправляет.
Если файндинг не подтверждается, т.е. разработчик посчитал его «фолсом», разработчик добавляет исключение для этого файндинга в отдельном репозитории в виде MR'а.
Из моего опыта, такой сценарий переворачивает концепцию AppSec и чаще всего используется, где слабый AppSec или его очень мало и он просто перегружен.
Подход, когда найденные секюрити проблемы, отправляются на анализ разработчику имеет ряд недостатоков. Для начала, как правило пайплайн един и в данной схеме отправляются как сикреты, так и какие то более сложные моменты, которые требуют знаний именно в аппсеке. В вашем случае, если дефект условно подтвердился, но разработчик его не правильно интерпретировал и неправильно исправил, то это возможно прошло мимро аппсека? (по схеме не очень понятно), если даже нет, то это увеличивает цепочку взаимодействий. Более эфективная и правильная схема, когда все потенциальные уязвимости попадает к Аппсеку для их триажа, и если дефект подтверждается, то в результате чего согдается дефект в виде документа, с рядом нужных полей, серьезность, описание с т.з. безопасности, т.е. то к чему может привести уязвимость, а так же с рекомендацией по устранению, что позволит помочь выбрать разработчику верное решение по устранению дефекта.
UPDATE:
"{пункт со звездочкой} внедрить QG и по возможности внедрить возможность блокировки релизов в случае несоблюдения политик ИБ."
Вот этот пункт, тоже по факту не жизнеспособен в реальности. Очень сложно настроить все так, чтобы блокировки всегда были обоснованы. А если произошла блокировка, а аппсек на обеде? С т.з. бизнеса это решение может привести к большим издержкам, и в целом снизит репутацию аппсек в компании. Здесь нужны другие меры.
Не обижайте начинающих программистов, а то они когда станут сеньорами тоже над джунами будут издеваться )))
PS код действительно может кому то быть полезен...
"Javarush, так ли полезно спустя 9.5 лет?" - Я считаю, что тема вообще не раскрыта.
По поводу лайтовая — ну я не знаю. На хабре полным полно статей для новичков, различных helloworld и прочего… и все они несут свою полезность.
Возможно просто не стоит реагировать на некоторых комментаторов?) Кто то вообще например не признает тех документацию на русском, а читают все всегда только в исходниках, так что, теперь перестанем вообще выпускать тех документацию на русском? :)
Тоже написал для ардуины прошивку и програмку для винды, которая использовала для управления радио джойстик. На саму клешню поставил микрокамеру с видео передатчиком, а сам сидел в другом месте и по камере, джлйстиком выполнял какие то манипуляции рукой, например печатал на клавиатура или перетасиквал предметы…
На как то быстро наигрался и убрал все в шкаф… применение ей так и не нашел :(
Возможно ваша статья имеет какой то смысл, но похоже для очень узкого круга людей, даже из числа сотрудников ИБ.
PS на сколько я знаю принятая аббревиатура для СрЗИ — просто СЗИ.
Код врят ли пригодится, а вот 20 полевичков уже заказал на Ali… :)
Вместо крены можно LM317 поставить.
Хотите чистого С на AVR — можно плату под 328ю мегу сделать за час… и кодить ее.
В дополнение статьи описали бы как потом наигравшись восстановить все обратно. Ну я про залить бутлоадер и выставить фьюзы под ардуину.
Вот тут:
У вас должна быть ссылка но она никуда не ведет.