Привет, Хабр!
По традиции, представлюсь, меня зовут Юрий Шабалин, и вместе с командой Стингрей мы разрабатываем платформу анализа защищенности мобильных приложений. Сегодня я хотел бы рассказать о хранении секретов в мобильных приложениях. А именно о том, что происходит с аутентификационными данными от сторонних сервисов, которые мы так любим использовать. И, конечно, о том, какими последствиями может обернуться для приложения и компании отсутствие должного внимания к их безопасности.
Поехали!
Привет, Хабр!
Меня зовут Юрий Шабалин, и, как я пишу в начале каждой своей статьи, мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.
В этой статье мне бы хотелось затронуть тему безопасной конфигурации сетевого взаимодействия, а также немного расширить предыдущую статью по SSL Pinning для механизма защиты канала связи в iOS. А именно, я расскажу про App Transport Security: для чего он нужен, использовать ли его или отключать в приложениях, в чем его польза.
На эту тему существуют статьи на англоязычных ресурсах (здесь можно многие из них найти в разделе “Ссылки“), достаточно подробно эта тема раскрыта в документации Apple, но на русском я статей практически не встречал. Но даже если они есть, я с удовольствием добавлю свой материал с практическими примерами в эту небольшую копилку.
Всем привет! Меня зовут Юрий Шабалин, я один из основателей компании Stingray Technologies. Мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.
Сегодня я хотел бы снова затронуть тему безопасности сетевого взаимодействия между приложением и его серверной частью. На эту тему написано немало, но комплексной статьи, отвечающей на самые разные вопросы, начиная от того, что же такое SSL, до того, как работает атака MiTM и как от нее можно защититься, я еще не встречал (а может, просто плохо искал). В любом случае, мне бы хотелось поделиться своими мыслями на этот счет и внести свою малую долю в русскоязычный контент на эту тему.
Статья может быть полезна для разработчиков, которые хотят понять, как устроен процесс прикрепления (пиннинга) сертификатов и специалистам по анализу защищенности мобильных приложений.
Привет, Хабр!
Меня зовут Юрий Шабалин, я один из основателей компании "Стингрей Технолоджиз" (входит в группу компаний Swordfish Security), мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.
По долгу службы мы подписаны на большое количество ресурсов и прорабатываем все статьи и материалы, которые относятся к теме мобильной безопасности. Результаты этого анализа я хочу представить в рамках этой статьи. Материал будет полезен всем, кто следит за появлением новой информации о способах поиска уязвимостей, разработкой новых инструментов и в целом заинтересован в безопасности мобильных приложений.
Всем привет, меня зовут Юрий Шабалин, я один из основателей компании "Стингрей Технолоджиз" (входит в группу компаний Swordfish Security), мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android. Этой статьей я бы хотел открыть серию материалов, посвященных мобильной безопасности. И сегодня поговорить о тех уязвимостях, что мы встречаем чаще всего при автоматическом анализе.
Продолжение статьи про комплексный подход реализации DevSecOps. В первой части были рассмотрены индустриальные вызовы, цели и задачи инструментов класса ASOC, Оркестрация и Корреляция.
Меня зовут Юрий Сергеев, я основатель и управляющий партнер в Swordfish Security.
С 2017 наша компания активно занимается проблематикой построения процессов разработки защищенного ПО (Secure Software Development Lifecycle). За прошедшие годы нам посчастливилось реализовывать поистине уникальные проекты в области DevSecOps, где мы приобретали для себя самое ценное - опыт. Накопленная экспертиза и сформированные компетенции дали нам возможность создать продукт - AppSec.Hub, который позволяет реализовать интеграцию практик информационной безопасности в непрерывный процесс разработки (DevOps) и построить настоящий DevSecOps.
Под катом я поделюсь своим взглядом на вызовы при построении DevSecOps, расскажу о той степени автоматизации, которой удалось достичь на основе анализа и трансформации процессов разработки защищенного ПО.
Статья получилась внушительная, так что мне пришлось разбить ее на две части. Обе будут опубликованы сегодня.
Вторая статья цикла, посвященного ОУД, рассказывает о проблеме с позиции разработчика прикладного ПО (или заказчика, который должен получить гарантии безопасности конечного продукта).
Давайте ненадолго абстрагируемся от ОУД. Представьте, что вы разработчик и создаете приложение для финансовых или кредитных организаций, подшефных Банку России. Или вы работаете в одной из таких организаций - банке, страховой, брокере, и являйтесь заказчиком продукта. Вы очень хотите гарантировать определенный уровень качества, и даже если не хотите - существующие SLA, нормативы регуляторов и требования контрактов заставляют прорабатывать не только функциональные требования, но и вопросы информационной безопасности. С чего же следует начать?
Привет, Хабр!
Я занимаюсь безопасностью мобильных приложений и с удовольствием слежу за развитием платформ Android и iOS, которые с каждым новым релизом становятся все привлекательнее для пользователей, «обрастают» новой интересной функциональностью и вместе с тем повышается их защищенность… или нет?
Сегодня я хотел бы сделать небольшой обзор развития различных функций безопасности системы Android, как внутренних, направленных на усиление безопасности самой платформы, так и внешних, напрямую относящихся к приватности и данным пользователей. Статья не претендует на оригинальность, все материалы есть в свободном доступе, но они рассредоточены по множеству публикаций. Мне показалась интересной попытка собрать эту информацию и проследить, как эволюционировала безопасность Android от версии к версии, чему уделялось внимание в каждом релизе и как это повлияло на дальнейшее развитие. В статье я постараюсь дать ссылки на различные ресурсы, где можно подробнее почитать о терминах, технологиях и прочем. Хотелось бы всё это рассказать в текущей статье, но тогда она рискует никогда не выйти.
Надеюсь, статья понравится и будет полезна всем, кто увлекается безопасностью мобильных приложений и операционных систем.
Привет, Хабр!
В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. «Secure SDLC» или «Secure software development life cycle»). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.
Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача – последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить «порог вхождения» в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России.
Подробнее под катом…
Привет, Хабр!
Как вы все уже знаете, в области безопасности приложений без статических анализаторов исходного кода (SAST) совсем никуда. SAST-сканеры занимаются тем, что проверяют код приложения на различные типы программных ошибок, которые могут скомпрометировать систему, предоставить злоумышленнику непредвиденные возможности для доступа к данным, либо для нарушения работы приложения. В основном анализ безопасности кода строится на изучении его семантической структуры, путей прохождения данных от момента пользовательского ввода до обработки. Однако есть и обычная для таких инструментов возможность поиска наиболее часто встречающихся небезопасных паттернов.
В этой статье я расскажу о CodeQL от GitHub Security Lab, интересном инструменте и языке для анализа исходного кода, который активно набирает популярность и выглядит весьма перспективным.
В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.
Привет, Хабр!
Как-то раз в нашей работе встретилась необходимость провести интеграцию сканера безопасности Netsparker и службы каталогов Active Directory. В этой статье я поделюсь инструкцией о том, как можно это сделать и на что стоит обратить внимание при настройке.
Забегая вперед, стоит отметить, что аналогичные шаги помогут настроить интеграцию с AD не только Netsparker, но и иных приложений, которые не имеют собственных средств взаимодействия с Active Directory.
20 ноября пройдет ежегодная конференция Archdays, где мы c Пашей Канн в рамках демонстрации покажем пример того, как может быть взломано приложение в Docker и как с нуля собрать пайлпайн с проверками безопасности на базе GitLab CI.
Взлом будет проходить в соответствии с инструкцией репозитория Pentest-In-Docker, который мы подготовили специально для Archdays. Есть также версия на русском языке, попробовать получить root на linux-хосте можно уже сейчас.
Привет, Хабр!
Наткнулись тут в Википедии на информацию: сколько дней продержалась каждая версия iOS до Jailbreak. В итоге соорудили инфографику just for fun.
Привет, Хабр!
В своей работе наша компания очень часто имеет дело с различными инструментами статического анализа кода (SAST). Из коробки они все работают средне. Конечно, всё зависит от проекта и используемых в нём технологий, а также, насколько хорошо эти технологии покрываются правилами анализа. На мой взгляд, одним из самых главных критериев при выборе инструмента SAST является возможность настраивать его под особенности своих приложений, а именно писать и изменять правила анализа или, как их чаще называют, Custom Queries.
Мы чаще всего используем Checkmarx - очень интересный и мощный анализатор кода. В этой статье я расскажу про свой опыт написания правил анализа для него.
Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.
