Comments 15
«Не забывайте и о том, что, теоретически, applicationId и clientKey могут быть доступны любому злоумышленнику»
Вопрос такой. А разве можно как-то сделать так, чтобы эти данные были НЕ доступны злоумышленнику?
Вопрос такой. А разве можно как-то сделать так, чтобы эти данные были НЕ доступны злоумышленнику?
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.
Полностью скрыть, конечно, нельзя — но для усложнения доступа можно попытаться обфусцировать эти строки, или, при сильном желании, немного поиграться со стеганографией. Часть злоумышленников это сможет оттолкнуть и направить на поиски более легкой добычи.
Отличная статья, спасибо!
Я как раз один из таких разработчиков, который откладывает настройку безопасности на потом. Надо сделать для себя соответствующие выводы.
PS: для компиляции проекта надо OS X 10.10 :(
/ParseRevealer-master/ParseRevealer/Base.lproj/Main.storyboard: The document «Main.storyboard» could not be opened. OS X 10.10 or higher is required.
Я как раз один из таких разработчиков, который откладывает настройку безопасности на потом. Надо сделать для себя соответствующие выводы.
PS: для компиляции проекта надо OS X 10.10 :(
/ParseRevealer-master/ParseRevealer/Base.lproj/Main.storyboard: The document «Main.storyboard» could not be opened. OS X 10.10 or higher is required.
К этим данным же можно получить доступ только в случае физического доступа к девайсу, который не закрыт паролем. Так?
спасибо за пищу для размышлений, но не стоит путать теплое с мягким, если я правильно понимаю — у разработчиков того-же чата в примере — не было выбора кроме как разрешить редактирование всем пользователям в админке, иначе пользователь не сможет редактировать свои сообщения. то-же касаемо остальных настроек безопасности.
Просто помимо глобальных настроек безопасности есть ACL для отдельных объектов, и с ними и нужно работать, тогда никто, без masterKey ничего за пределами своего аккаунта не сделает. А вы, я так понял, проверяли только объекты принадлежащие вам.
Так что глобальные настройки, описанные в статье погоды не делают, а ACL для отдельных объектов не рассмотрены, с выводами «безопасность нужна» более-менее согласен, а вот методикой исследования не очень проникся
И еще спасибо за утилиту, но напишите пожалуйста в ней предупреждение, что она пишет в базу, это не совсем очевидно и это будет болееuser developer friendly, а то пришлось сперва подумать откуда всплыли пустые записи в продакшн базе.
Просто помимо глобальных настроек безопасности есть ACL для отдельных объектов, и с ними и нужно работать, тогда никто, без masterKey ничего за пределами своего аккаунта не сделает. А вы, я так понял, проверяли только объекты принадлежащие вам.
Так что глобальные настройки, описанные в статье погоды не делают, а ACL для отдельных объектов не рассмотрены, с выводами «безопасность нужна» более-менее согласен, а вот методикой исследования не очень проникся
И еще спасибо за утилиту, но напишите пожалуйста в ней предупреждение, что она пишет в базу, это не совсем очевидно и это будет более
Отвечу по пунктам:
1. Вообще в этом приложении редактирование сообщений чата не предусмотрено — как раз таки возможность этого и является одной из уязвимостей. Меняться должен только флаг unread при просмотре сообщения. Здесь, как раз таки, могли бы помочь user-based ACL, либо вынесение этого и/или других флагов в отдельную изменяемую таблицу.
2. Даже с отдельными ACL для каждого из объектов не решить рассмотренные здесь проблемы, не меняя глобальных прав доступа — как минимум, ничто не мешает создавать новые объекты, присваивать им определенный chatId, и наблюдать, как приложение будет крешиться. Но это безусловно необходимый шаг, о чем я и написал в секции рекомендаций :)
3. Статья задумывалась не как гайд по правильной конфигурации, а как proof-of-concept этого вектора атаки на исследуемое приложение.
А предупреждение обязательно добавлю :)
1. Вообще в этом приложении редактирование сообщений чата не предусмотрено — как раз таки возможность этого и является одной из уязвимостей. Меняться должен только флаг unread при просмотре сообщения. Здесь, как раз таки, могли бы помочь user-based ACL, либо вынесение этого и/или других флагов в отдельную изменяемую таблицу.
2. Даже с отдельными ACL для каждого из объектов не решить рассмотренные здесь проблемы, не меняя глобальных прав доступа — как минимум, ничто не мешает создавать новые объекты, присваивать им определенный chatId, и наблюдать, как приложение будет крешиться. Но это безусловно необходимый шаг, о чем я и написал в секции рекомендаций :)
3. Статья задумывалась не как гайд по правильной конфигурации, а как proof-of-concept этого вектора атаки на исследуемое приложение.
А предупреждение обязательно добавлю :)
Немного оффтоп. Пытался пользоваться Cloud Code, но простые скрипты вылетают по таймауту в 3 секунд (сами скрипты почти идентичны скриптам-примерам в справке самого Parse). Пришлось отказаться от него, хотя было бы удобно…
Вопрос: это на халявном аккаунте такая плохая производительность или вообще?
Вопрос: это на халявном аккаунте такая плохая производительность или вообще?
Sign up to leave a comment.
Безопасность Parse в iOS приложении