Не за что :) Вообще большая часть дизайнеров используют Photoshop+Illustrator, на Sketch еще не перешли. Насчет версий сходу не скажу, но завтра постараюсь уточнить. С названием плагина для разметки то же самое — узнаю.
На самом деле мы не слишком сильно участвуем в процессе именно дизайна, так что тонкостей вроде использования ссылок не знаю — но уверен, что что-то в этом роде используется.
Отвечу по пунктам:
1. Вообще в этом приложении редактирование сообщений чата не предусмотрено — как раз таки возможность этого и является одной из уязвимостей. Меняться должен только флаг unread при просмотре сообщения. Здесь, как раз таки, могли бы помочь user-based ACL, либо вынесение этого и/или других флагов в отдельную изменяемую таблицу.
2. Даже с отдельными ACL для каждого из объектов не решить рассмотренные здесь проблемы, не меняя глобальных прав доступа — как минимум, ничто не мешает создавать новые объекты, присваивать им определенный chatId, и наблюдать, как приложение будет крешиться. Но это безусловно необходимый шаг, о чем я и написал в секции рекомендаций :)
3. Статья задумывалась не как гайд по правильной конфигурации, а как proof-of-concept этого вектора атаки на исследуемое приложение.
The first thing you need to understand is that your client key is not a security mechanism. It’s not even intended to serve as such. Your client key is shipped as a part of your app.
Полностью скрыть, конечно, нельзя — но для усложнения доступа можно попытаться обфусцировать эти строки, или, при сильном желании, немного поиграться со стеганографией. Часть злоумышленников это сможет оттолкнуть и направить на поиски более легкой добычи.
Несколько ссылок привели вот к этой библиотеке: github.com/project-imas/encrypted-core-data. Честно скажу — еще не потестил, но, судя по описанию, позволяет прикрутить прозрачное шифрование на базе SQLCipher к Core Data.
Спасибо за ссылки, попробую поиграться. В SQLCipher огромный плюс — встроенная поддержка в FMDatabase, который все-таки очень удобен при разработке.
Насчет проблем с публикацией — не возникло, учитывая, что ERN приложил.
Чтобы самому сделать сборку — да, нужен девелоперский аккаунт. Если с этим проблема — можете скачать версию 1.4.8 из App Store. Ссылку отправил в личку.
Я считаю, что нельзя полностью полагаться на чувство сознательности пользователя, который мог и не устанавливать блокировку, особенно приложениям, оперирующим конфиденциальными данными. Да и вообще, полностью полагаться на встроенные механизмы безопасности — отнюдь не лучшее решение. А использование проверенных сторонних библиотек считать костылем — как минимум странно.
Не совсем то, что нужно. Насколько я помню, данные с его помощью шифруются только когда прошло несколько минут с момента блокировки паролем. Все остальное время, включая также и тот вариант, что пароль не установлен вообще, информация хранится в открытом виде и может быть получена тем же самым образом.
На самом деле мы не слишком сильно участвуем в процессе именно дизайна, так что тонкостей вроде использования ссылок не знаю — но уверен, что что-то в этом роде используется.
1. Вообще в этом приложении редактирование сообщений чата не предусмотрено — как раз таки возможность этого и является одной из уязвимостей. Меняться должен только флаг unread при просмотре сообщения. Здесь, как раз таки, могли бы помочь user-based ACL, либо вынесение этого и/или других флагов в отдельную изменяемую таблицу.
2. Даже с отдельными ACL для каждого из объектов не решить рассмотренные здесь проблемы, не меняя глобальных прав доступа — как минимум, ничто не мешает создавать новые объекты, присваивать им определенный chatId, и наблюдать, как приложение будет крешиться. Но это безусловно необходимый шаг, о чем я и написал в секции рекомендаций :)
3. Статья задумывалась не как гайд по правильной конфигурации, а как proof-of-concept этого вектора атаки на исследуемое приложение.
А предупреждение обязательно добавлю :)
Полностью скрыть, конечно, нельзя — но для усложнения доступа можно попытаться обфусцировать эти строки, или, при сильном желании, немного поиграться со стеганографией. Часть злоумышленников это сможет оттолкнуть и направить на поиски более легкой добычи.
Божественный анализ.
Для тех, кто спешит — с 1:59.
UPD: промахнулся веткой, предназначалось комментарию выше.
\usepackage[russian]{babel}Насчет проблем с публикацией — не возникло, учитывая, что ERN приложил.