Pull to refresh

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.
Да, Storyboards в приложения для OS X добавили только в 10.10. Добавляйте issue, поправлю в ближайшее время.
К этим данным же можно получить доступ только в случае физического доступа к девайсу, который не закрыт паролем. Так?
К ним можно получить доступ с любого устройства, на которое установлено приложение. То есть, если оно есть в App Store, то никаких ограничений нет.
clientKey – твой либо с чужого девайса, разве нет?
clientKey устанавливается в настройках аккаунта Parse и един для всех установок.
Теперь я понял, круто однако.
спасибо за пищу для размышлений, но не стоит путать теплое с мягким, если я правильно понимаю — у разработчиков того-же чата в примере — не было выбора кроме как разрешить редактирование всем пользователям в админке, иначе пользователь не сможет редактировать свои сообщения. то-же касаемо остальных настроек безопасности.

Просто помимо глобальных настроек безопасности есть ACL для отдельных объектов, и с ними и нужно работать, тогда никто, без masterKey ничего за пределами своего аккаунта не сделает. А вы, я так понял, проверяли только объекты принадлежащие вам.

Так что глобальные настройки, описанные в статье погоды не делают, а ACL для отдельных объектов не рассмотрены, с выводами «безопасность нужна» более-менее согласен, а вот методикой исследования не очень проникся

И еще спасибо за утилиту, но напишите пожалуйста в ней предупреждение, что она пишет в базу, это не совсем очевидно и это будет более user developer friendly, а то пришлось сперва подумать откуда всплыли пустые записи в продакшн базе.
Отвечу по пунктам:
1. Вообще в этом приложении редактирование сообщений чата не предусмотрено — как раз таки возможность этого и является одной из уязвимостей. Меняться должен только флаг unread при просмотре сообщения. Здесь, как раз таки, могли бы помочь user-based ACL, либо вынесение этого и/или других флагов в отдельную изменяемую таблицу.
2. Даже с отдельными ACL для каждого из объектов не решить рассмотренные здесь проблемы, не меняя глобальных прав доступа — как минимум, ничто не мешает создавать новые объекты, присваивать им определенный chatId, и наблюдать, как приложение будет крешиться. Но это безусловно необходимый шаг, о чем я и написал в секции рекомендаций :)
3. Статья задумывалась не как гайд по правильной конфигурации, а как proof-of-concept этого вектора атаки на исследуемое приложение.

А предупреждение обязательно добавлю :)
Немного оффтоп. Пытался пользоваться Cloud Code, но простые скрипты вылетают по таймауту в 3 секунд (сами скрипты почти идентичны скриптам-примерам в справке самого Parse). Пришлось отказаться от него, хотя было бы удобно…
Вопрос: это на халявном аккаунте такая плохая производительность или вообще?
ну скрипты по идее должны быстро выполняться, но там куча других ограничений, например жестокий лимит на количество операций count

а для 3 секунды и больше лучше background job использовать — у них лимиты по времени гораздо больше но точно не скажу
Sign up to leave a comment.

Articles