Как стать автором
Обновить

Комментарии 23

4. Уязвимости общения через WebSocket
Пример эксплуатации уязвимости — как и в предыдущем случае, 1Password. Его браузерное расширение собирало введенные пользователем в различных формах пароли и номера кредитных карт, и через порт 6263 отправляло их приложению. Дальнейшие действия просты — пишем программу, которая слушает этот же порт, логируем все полученные данные, и собираем неплохую базу. Опять же, все это спокойно проходит проверку в App Store.
А как Apple может исправить подобную уязвимость, если браузерное расширение отправляет данные на произвольный порт? Разве что ввести ещё больше ограничений для производителей расширений и сделать браузерные расширения частью программ из MAS, как это сделано на iOS?
Достаточно по необходимости резервировать порт для одного приложения.
Но меня больше интересует 1Password — софтина для работы с паролями, и нет шифрования на таком уровне? Это уже косяк разработчика, а не ОС.
Как резервировать-то? Из-за одного приложения никто из миллионов пользователей маков больше не сможет использовать этот порт?

И как делать шифрование? Расширение браузера — это javascript-код. Даже если сделать ассиметричное шифрование и расширение обойдётся публичным ключём, то вытащить приватный ключ из программы — не проблема.

Я о том, что если приложение призвано работать с приватной информацией, необходимо создать возможность для разработчика защищать канал передачи. На уровне AppStore возможно доработать механизм модерации. Допустим, объявить заранее определенный диапазон портов, который позволено резервировать только специально одобренным приложениям, действительно нуждающимся в защите. Да, это завинчивание гаек — но в таком частном случае оно на руку всем. И Apple как раз может это сделать, если захочет.
НЛО прилетело и опубликовало эту надпись здесь
Даже если сделать ассиметричное шифрование и расширение обойдётся публичным ключём, то вытащить приватный ключ из программы — не проблема.
Через общий ключ шифрования, который генерируется на стороне программы и копипастится пользователем в расширение. Какое-то из расширений для KeePass так делает.
Да, останется только защитить доступный всем программам буфер обмена.

Мне кажется, бескостыльный способ — это сделать браузерное расширение частью основной программы, тогда у них будет общая область памяти, примерно как это сделано под iOS. Но тогда это будет не Javascript-расширение, а нативный плагин, и возможно потребует переработки механизма расширений.

Интересно, как обстоят дела в других браузерах и операционных системах.
Да, останется только защитить доступный всем программам буфер обмена.
Зачем? Копипаста происходит, когда соединение с программой уже установлено, т. е. его никто не перехватит. Скопипащенный ключ используем для обмена свежесгенерированными парами ассиметричных ключей. В принципе можно даже без копипасты обойтись, просто показать диалог «кто-то запрашивает доступ к базе ключей, разрешить?».
НЛО прилетело и опубликовало эту надпись здесь
«Приложение должно само...» Мы живем не в идеальном мире, увы. Внушить каждому разработчику правила сложнее (да в целом невозможно), чем определить область допустимых действий. Тому же Касперскому и Adobe (к примеру, из другой области) плевать, что официальные деинсталляторы оставляют тонны хвостов в системе. Они не скрываясь гадят на системах рядовых пользователей, закрывают на это глаза — им никто не указ. И если любое популярное приложение начнет издеваться над клиентом (Скайп) — это повлияет на Ваш личный выбор, но не на большинство.
Другой вопрос — когда на уровне ОС есть механизмы принудительного регулирования. Они должны быть.
когда на уровне ОС есть механизмы принудительного регулирования. Они должны быть.

Они есть — механизмы аутентификации на уровне API. Никто не будет вводить ограничения на сетевой стек, это нереалистично. Максимум это ввод гайдлайнов для разработчиков. Канал данных между приложением и внешним миром это забота разработчика и только разработчика. Это как раз наша с вами реальность.
То есть, если разработчик откровенно игнорирует какие-либо правила, но при этом приложение популярно либо отказаться от него нельзя — делать с кривотой ничего не надо? Ладно, пусть хоть на уровне API был бы порядок, так его же нет.
Есть какие-то правила? Я нигде их не видел. На уровне API порядок есть. Есть сетевой стек, есть технологии шифрования, аутентификации и контроля целостности. Выбирай что хочешь. Единственное, что в этой ситуации можно делать, это вводить ограничения на определенный вид приложений, которые работают с персональными данными. С учетом того, что проблемы защиты канала данных известны с самого дня их появления и Apple явно о них тоже знают, у меня большие сомнения что спустя такое время какие-либо существенные ограничения вдруг появятся.
А вы пользуетесь каким-нибудь менеджером паролей вообще? Каким? Или только штатным?
Пользуюсь 1Password
KeePassX
mSecure
Несколько лет назад сравнивал 1Password и mSecure для айфона, mSecure на тот момент оказался намного удобнее и функциональнее.
Потом и десктопную версию к нему докупил на какой-то распродаже.

Сейчас лень менять, да и десктопный 1Password денег стоит.
Access Control Groups не существуют на iOS, значит это не делает платформу уязвимой. Источник.
Заголовок такой, потому что рассматриваются не только уязвимости, связанные с Keychain
-в отличие от того же Android, пользователю не предоставляется выбор, какое из приложений должно открыться.
Вот за это я и не люблю ios — нет выбора. Все делается за тебя, ты не можешь это настроить или поменять — только через удаление/переустановку приложения.
А подскажите пожалуйста, как в Андроиде поменять одно приложение открываемое по ссылке на другое, в настройках нету почему-то.
В настройках приложения есть кнопка «Сбросить умолчания», тогда при открытии ссылки система вновь предложит сделать пользователю выбор, если он есть, с возможностью запомнить действие «по умолчанию». Механизм одинаков не только для ссылок, но и для открытия домашнего экрана, например, если приложений несколько.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий