Этот вопрос является зеркалом отчета об ошибке, который я сделал в справочном форуме по анализу
Теперь я знаю, что тот, который находится на сайте разбора, - это не вопрос, а отчет, и я не хочу оставлять здесь только зеркало отчета, но просто проверьте, что мои проблемы обоснованы, с людьми, которые вероятно, больше опыта со мной.
Проблема в том, что похоже, что синтаксический анализ не создает правильную подпись HMAC.
- Первый тест: я взял прокси (Charles proxy), установил точку останова в запросе на обновление и изменил поле, оставив подпись незатронутой. Выполните запрос. Сервер принимает запрос, и поля обновляются соответствующим ему (даже поле, измененное в точке останова, конечно).
- Второй тест: вместо изменения запроса я просто изменил подпись, чтобы убедиться, что сервер фактически тестирует значение подписи, запрос получил отклонение, как ожидалось.
- Третий тест: вместо изменения только значения существующего поля добавьте новое новое поле в запрос и выполните. Сервер принимает запрос, обновляет поле, если добавленное поле не существует, оно добавляет его в обновленную строку, иначе просто обновит его.
Теперь, мои заботы обоснованы? Я неправильно понял OAuth RFC в каких-либо частях, касающихся генерации подписи? Как возможно, что сотрудники/пользователи Parse никогда не замечают такой ОГРОМНОЙ ошибки?
Пожалуйста, я знаю, что этот вопрос может вызвать широкую дискуссию, но поскольку важность этого вопроса (и не только для меня, но для всех пользователей синтаксического анализа) оставляют время, когда кто-то из информированных должен оставить действительный ответ.
ИЗМЕНИТЬ
Я копаю внутри Parse iOS SDK, чтобы узнать, почему это происходит на самом деле. После некоторых исследований и небольшого числа обратных разработок их статической библиотеки я обнаружил, что они используют модифицированный (возможно, они просто изменили имена методов, префикс их с помощью библиотеки "PF" ) под названием OAuthCore. Обнаружив это, я получил подтверждение, посмотрев на старую версию SDK с открытым исходным кодом (найденный googling для измененных имен библиотек). Теперь библиотека выполняет свою работу и работает, как ожидалось, достаточно прилипает к RFC. Проблема в том, что, очевидно, OAuth не охватывает весь HTTP-запрос, а только часть его. То, что я ожидал, и как должно быть ИМХО, заключается в том, что когда вы делаете запрос на обновление поля (или осуществляете покупку? Регистрируетесь? Отправляете конфиденциальные данные?), "Грязные" поля должны отправляться как параметры запроса, так что они будут включены в процесс подписи/проверки, выполняемый через протокол OAuth. Вместо этого запросы обновления (в частности, сделанные при вызове запроса POST, направленного на https://api.parse.com/2/update), устанавливают тело запроса POST в строку json, представляющую фактическое обновление. Честно говоря, это было ясно даже до всего этого, поскольку, посмотрев на запрос, я должен был понять, что текст json отправляется как необработанное тело запроса вместо объекта x-www-form-urlencoded (таким образом, параметры запроса urlencoded и -конкатированы в теле запроса).
Пока это "правильное" поведение, я чувствую, что это не так, как должно быть в производственной среде, используемой тысячами людей. Теперь я попытаюсь исправить это, не нарушая функциональность, я должен сделать это, я поделюсь патчем.
Все еще надеется получить ответ от Парса напрямую.
РЕДАКТИРОВАТЬ 2. Парс закрыл мой вопрос как не вопрос, а отчет об ошибке. Никаких комментариев по основным недостаткам безопасности, которые подразумевает их реализация.
Ниже копии сообщенной ошибки
Я играл с SDK Parse iOS, и я нашел основную ошибку что серьезно угрожает безопасности приложений, разработанных с использованием синтаксического анализа как бэкэнд.
Теперь, извините, если я не использую средство создания отчетов об ошибках, но я делаю не владею учетной записью facebook, и я не хочу этого делать.
Помещение: API-интерфейсы Parse, похоже, соответствуют протоколу OAuth 1.0a (RFC 5849). Соответствующая часть RFC, которая включает эту ошибку, стр. 18, подпись.
В соответствии с вышеупомянутым RFC каждый запрос должен имеют заголовок аутентификации, составленный как:
OAuth realm="Example", oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7", oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176", oauth_version="1.0"Это гарантирует не только то, что запрос разрешен, но даже запрашивать целостность, поскольку подпись HMAC будет обеспечивать это. Как Фактически подпись должна быть рассчитана с использованием нормализованная строка, состоящая из параметров запроса и подписанная с клиент, объединенный с общим секретом токена (см. раздел 3.4.2, стр. 25 RFC). Таким образом, злоумышленник не должен ВСЕГДА изменять запрос до того, как он достигнет сервера. сервер на самом деле должен проверить соответствие подписи целому запрос, отклоняя его, если он этого не делает.
Довольно печально, что Parse, похоже, не полностью соответствует приведенному выше. Используя простой прокси, я могу полностью изменить запросы, от изменения идентификатор пользователя, выполняющий запрос, измените значение параметра в запрос, ДОБАВИТЬ ОБЛАСТЬ И ЦЕННОСТЬ, КОТОРЫЕ НЕ ВКЛЮЧЕНЫ В ЗАЯВКУ ВСЕ.
Теперь очень легко представить себе недостатки, которые все это может привести к. В частности, я думаю разработчикам мобильных устройств, которые включить покупки в приложении в своем приложении, полагаясь на то, что синтаксический анализ является безопасным достаточно для них, чтобы их пользователи не смогли "обмануть", таким образом теряя доход и сводя на нет усилия, которые они предприняли для своего приложения.
Теперь, когда я смог проверить его на других SDK, я уверен такая же ошибка воспроизводится там, или, что еще хуже, проблема что сервер вообще не проверяет подпись.
Ожидание ответа сотрудника Parse об этой ошибке.
С уважением, Антонио