Комментарии 7
Выглядит довольно надёжно, но что если пользователь сам скомпрометирует хранилище сертификатов в своей системе, установив в доверенные сертификат злоумышленника.
Имхо, это достаточно смелое предположение.
Отдельный момент — это то, как многие приложения реализуют Pinning: пользователь получает максимально неинформативное сообщение о том, что приложение не работает (крайне мало компаний пишут хоть что-то о том, что сертификат может быть подменён), он пытается ещё раз, идёт искать "ApplicationName не работает", попадает на официальный сайт, где написано "Вышла новая версия приложения, старая вообще никак работать не будет, установите по ссылке новую, в ней дадим 100 рублей компенсации", а там уже ссылка на фишинговое приложение.
Имхо, это достаточно смелое предположение.
Извините, а можете пояснить подробнее? Вы в целом алгоритмы SSL и TLS считаете ненадежными, или же ситуацию когда пользователь старается испортить себе жизнь? Если второе, так я вроде это и написал — пользователь сам с удовольствием ищет себе проблемы, поэтому мы и вынуждены реализовывать pinning на уровне приложения.
А во второй части — полностью с Вами согласен. Разработчикам стоит не только задумываться о безопасности на уровне приложения, но и том, как именно уведомить пользователя о потенциальной атаке. А еще желательно предоставить ему в таком случае инструкцию как поступить в максимально простом виде. Я бы даже сказал, что это продолжение механизма защиты от атаки. Если не объяснить пользователю что он в опасности — он продолжит и обязательно найдет себе неприятности, например таким образом, который вы описали.
От митма спасут сами ОС которые не дадут установить контакт если сертификат не подходит/произошел даунгрейд, пытаются подменить.
Если ваше приложение захотят атаковать надо просто заменить файл сертификата и пересобарать приложение, на андроиде это делалось за пару минут.
А что вы собираетесь делать если истечет срок жизни сертификата, о таких вещах частенько забывают?
Если ваше приложение захотят атаковать надо просто заменить файл сертификата и пересобарать приложение, на андроиде это делалось за пару минут.
А что вы собираетесь делать если истечет срок жизни сертификата, о таких вещах частенько забывают?
От митма спасут сами ОС которые не дадут установить контакт если сертификат не подходит/произошел даунгрейд, пытаются подменить.
Тут вы скорее неправы, ОС спасут только в 1 случае — если пользователь не начнет чудить. Допустим он самостоятельно может поставить сертификат злоумышленника себе в систему. К слову, мы недавно проходили пин-тесты в одном из бизнес проектов. Так вот в требованиях по безопасности было четко прописано, что приложение должно корректно защититься в случае если «злоумышленник с помощью методов социальной инженерии убедит пользователя установить скомпрометированный сертификат». И это абсолютно правильно — никогда не надо полагаться на пользователя. Закон Мёрфи — всё, что может пойти не так, пойдёт не так.
Если ваше приложение захотят атаковать надо просто заменить файл сертификата и пересобарать приложение, на андроиде это делалось за пару минут.
Вы недостаточно внимательно прочитали статью, я писал об этом. В той реализации которую предлагаю я, для этого придется приложить довольно много усилий, потому что сертификат вшит в код, а не положен в ресурсы. А код в релизной сборке Flutter компилируется AOT способом.
А что вы собираетесь делать если истечет срок жизни сертификата, о таких вещах частенько забывают?
С этим соглашусь, тут стоит учитывать время жизни сертификата и подобрать оптимальное решение для вас. Обеспечить ко времени его протухания обновление вашего приложения у пользователей. Или если вы не можете гарантировать подобного, стоит смотреть в направлении установки цепочек доверенных сертификатов. Принцип в целом тот же — вы настраиваете внутри приложения свою среду «доверия/недоверия» не полагаясь на системные настройки.
Android при установке сертификата в системное хранилище заставляет поставить пин код, и постоянно напоминает, что трафик может мониториться. В полной мере от социальной инженерии невозможно защититься.
По поводу сертификата буду благодарен за сравнение кода с примером сертификата и кода сертификата как list, в том смысле насколько они разные/узнаваемые и тяжело ли будет их найти.
По поводу сертификата буду благодарен за сравнение кода с примером сертификата и кода сертификата как list, в том смысле насколько они разные/узнаваемые и тяжело ли будет их найти.
В полной мере от социальной инженерии невозможно защититься.
Именно про это и речь, нельзя полагаться на сознательность пользователя. Поэтому самостоятельное определение того, что является доверенной зоной приложением, а не системой, является частой реализацией пиннинга. Нужно использовать все возможности которые доступны для защиты. Это как с входной дверью — вы можете держать ее открытой, закрыть, или поставить как в банковском хранилище, и в любом случае будет возможность, что к вам проберутся. Но оставлять дверь открытой не самый лучший выход, правда?
По поводу сертификата буду благодарен за сравнение кода с примером сертификата и кода сертификата как list, в том смысле насколько они разные/узнаваемые и тяжело ли будет их найти.
Вы можете просто почитать про AOT компиляцию. Если вкратце, то декомпиляция данного кода невозможна, возможно дизассемблирование и при этом придется приложить достаточно много усилий. Да, это не стопроцентная гарантия от взлома, но это уже далеко не простая задача.
Кстати Flutter использует AOT только для релизной сборки, при debug сборке используется JIT компиляция, и вот оттуда можно довольно легко выдернуть сам код. Это на случай, если вы решите попробовать декомпилировать приложение.
Главный вопрос — как победить ошибку при использовании self-signed и вебсокетов?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SSL pinning во Flutter