Защита против взломов in-app покупок. Часть 2


    Недавно я рассказывал о том, как защитить своё приложение с помощью валидации покупок на своём сервере. Через пару дней после публикации поста этот вид защиты научились обходить. Но есть и хорошие новости, мы теперь знаем в чем были слабые места, и можем эти моменты усилить.

    Что было плохо?
    • Было недостаточно проверок на соответствие чека и данных в SKTransaction.
    • Было недостаточно проверок ответа сервера.

    VerificationController от Apple


    Признаю, когда писал первый свой пост, я холодно отозвался о методе защиты предложенном Apple. Мол, их защита уязвима, потому что они всё еще делают проверку на своём сервере. Таким образом, если смогут этот сервер обмануть — защита будет сломана у всех приложений, которые ей пользовались. Звучит разумно, но, если присмотреться, шанс такого сценария не так уж и велик, потому что VerificationController — это не только отправка запроса на сервер и проверка результата.

    Вот какие проверки входят в VerificationController:
    • Сохраняет все совершенные в приложении покупки и проверяет их на уникальность, чтобы было сложнее обманывать приложение с одинаковыми поглощаемыми покупками.
    • Проверяет сертификат и правильность подписи данных о покупке, чтобы чек, который мы получили от сервера, был правильно подписан.
    • Проверяет совпадение полей в объекте SKPayment и в чеке покупки.
    • Проверяет чек покупки на сервере Apple, причем во время проверки, проверяет расширенную информацию из SSL сертификатов. Иначе соединение не будет установлено.
    • В запросе валидации используется уникальный для приложения секретный ключ. Возможно вскоре Apple запретит проверку без ключа или проверку чеков от покупок других приложений.
    • В ответе сервера проверяет совпадение полей с нашим чеком, чтобы нельзя было просто вернуть чужие данные и status:0.

    На github уже есть немного допиленная версия ValidationController-a: github.com/evands/iap_validation. От штатной она отличается тем, что в ней уже реализованы base64 кодирование-декодирование и сделаны удобные делегаты, в которых можно включать платную функцию.

    Что еще можно сделать


    Если написанного выше вам кажется недостаточно и вы хотите добавить что-то своё в защиту приложения, могу посоветовать хорошую книгу по этой теме: Hacking and Securing iOS Applications: Stealing Data, Hijacking Software, and How to Prevent It. Однако не стоит увлекаться, вы можете добавить слабое звено к уже имеющейся защите и сделаете только хуже.

    Проверка боем


    Пару дней назад магазин вышла версия 2.2.1 моего приложения и у меня есть немного статистики. Нынешние методы взлома не джейлбрейкнутых устройств доходят до провеки соответствия полей чека, полям SKPayment и палятся, т.к. чек который они подсовывают, совсем от другой покупки. Приятным сюрпризом для меня было и то, что ломалки для джейлбрейкнутых устройств тоже не могут провести покупку, вместо этого приложение падает в момент валидации. А это значит, пока защита работает, и работает хорошо, посмотрим сколько времени потребуется чтобы её сломать. :)
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 18
    • 0
      Вам не кажется, что те, кто использует подобные ломалки, принципиально ничего не покупают? Так что игра не стоит свеч. Или у вас есть положительная динамика роста покупок?
      • +2
        Нет, я не считаю что пользователи которые любят халяву, никогда не заплатят за нужную функцию. Им же досталось устройство на iOS, может быть у них просто карточка не привязана к аккаунту и лень покупать iTunes gift card, может просто жалко денег. Главное что в этом нету принципиальной позиции и в какой-то момент пользователи понимают, что если им нравится приложение и они хотят чтобы оно развивалось — не жалко заплатить разработчику денег. Я это наблюдаю за своими знакомыми, которые сначала ждут раздачи халявы и скачивают только бесплатные приложения, потом не выдерживают и покупают первое приложение. Дальше-проще и 1-3$ — это не такие уж и большие деньги.
        • 0
          Это мы с вами прекрасно понимаем, что без материальной поддержки разработчики не смогут выпускать качественный контент. Но я очень часто встречаюсь с непониманием людей, далеких от разработки, почему им надо платить за что-то еще, если они уже заплатили за телефон (я говорю про отечественный рынок). Такие люди обычно просто удалят приложение. Вот я и поинтересовался у вас, есть ли какие-то сдвиги в цифрах.
          • 0
            Положительная динамика роста покупок у меня есть, но она была и до реализации защиты. Возможно защита помогает удерживать положительную динамику, а может она и не участвует в этом процессе и просто приложение хорошее и его с удовольствием покупают. Слишком много факторов в этом участвуют.
      • 0
        Никто не в курсе как обстоит это дело в MKStoreKit?..
        Автор пишет что его имплементация уже включает в себя receipt verification, но прямо не отвечает на следующие вопросы
        — Подвержен ли MKStoreKit этой новой уязвимости? (он как бы говорит что «нет»)
        — Использует ли он новый VerificationController? (судя по всему нет)
        • 0
          Да, подвержен. Нет он не использует никакой валидации покупки.
          См. код обработки успешной транзакции: github.com/MugunthKumar/MKStoreKit/blob/master/MKStoreObserver.m#L81-92 он просто включает платную фичу без проверок.
          • 0
            А может всё и не так просто. Для iOS он отправляет проверку на свой сервер, но сервер отвечает просто YES, NO. Т.е. когда сервер взломщиков будет присылать правильный, но чужой чек от покупки — этот Kit не сможет заметить что его обманывают.
            • 0
              Возможно, наверное я поторопился вешать на него всех собак сразу.
              Надеюсь он закроет дыру, если она в его коде есть.
            • 0
              Значит зазнался чувак. Как-то слишком катерочино заявляет что его код уже включает в себя верификацию, прям с восклицательным знаком… Видимо не хочет ронять свою репутацию «industry standard», которую сам себе приписал.

              И похоже он ничего делать не собирается. В описании на гитхабе сказано «работаю на поддержкой Lion, после этого, скорее всего, никаких больших обновлений больше не будет (если только Apple не придумает новый механизм In-App Purchases)». Уже появился Mountain Lion, последние коммиты были 3 месяца назад, на открытый баг он отписался один раз, мол «все у меня проверяется!» и замолк. Жалко будет если он совсем забил на это дело.
              • +1
                GitHub тем и хорош, что вы можете сделать форк, доработать его StoreKit и отправить pull-request.
            • 0
              Я недавно описывал метод защиты с MKStoreKit в этом посте.
              Могу сказать по этому поводу следующее. С учетом того, что мои проги с этой защитой скачали больше 600 000 раз, попыток взлома — немеряно. мой сервер отрабатывает всю статистику. и метод защиты на данный момент работает отлично. То есть статистика из itunesconnect и статистика, которая собирается через приложения не отличаются больше чем на 2%-3%.
              И я у себя на сервере сохраняю все сертификаты для дальнейшего анализа. Попыток много — успешных взломов не видел.
              • 0
                У меня в приложении используется код проверки покупок от Apple доработанный напильником. Отчеты о крэшах с testflight показывают что в день где-то 3-5% новых пользователей пробуют активировать бесплатно покупки на джейлбрейкнутых телефонах с помощью твиков. Но т.к. твики рассчитывают на отсутствие детальной проверки со стороны приложения — они просто крэшатся. :)

                BTW успешная «бесплатная покупка» тем и отличается от неуспешной, что приложение её не может отличить от настоящей. :) Иначе откуда эти 2-3%?
                • 0
                  2-3% — это Non-consumable покупки на разных устройствах под одним appleid, и восстановление покупок после переустановки. Еще, возможно, несовпадение временых рамок статистики.

                  А то что приложение крешится — я считаю непремлемо, потому что как-то это неправильно. в слечае взлома, я прямым текстом пользователю пишу — Покупка не подтверждена. Это, как мне кажется, изящнее.
                  • 0
                    Если оно крэшится у пользователя, который подгрузил твик, который подменил функции приложения в рантайме, то тут тяжело что-то поделать. :) Я конечно заменю в следующей версии этот крэш на сообщение с призывами к совести, но надо понимать, что такие пользователи сами себе злобные буратины. :)
            • 0
              Поздравляю! Вы сделали защиту сами! Apple кинула в вас куском кода с проверкой, сама не сделав ничего. Кстати, по-моему в 2014 сертификат внутри истечет=)
              • 0
                Я разработчик, а не специалист по безопасности. Я не ломаю чужие приложения и как видно по моей первой статье, верные идеи в неопытных руках приносят не много пользы. Apple как обычно оставляет вкусности на последний момент, посмотрим что будет после выхода iOS6.

                Кстати, вам стоит признать, что с проверкой сертификата и проверкой соответствия полей в SKPayment ваш сервис пока ничего не может поделать. Ваш ход, как говорится.
                • 0
                  Да, я это признал. Ждем iOS6=)
                  • 0
                    На андроиде есть механизм патча dalvik-cache.

                    LuckyPatcher тому пример.
                    Может и такое есть для iOS?

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.