Pull to refresh

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

Reading time 2 min
Views 8.6K

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

Что было плохо?
  • Было недостаточно проверок на соответствие чека и данных в 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 и палятся, т.к. чек который они подсовывают, совсем от другой покупки. Приятным сюрпризом для меня было и то, что ломалки для джейлбрейкнутых устройств тоже не могут провести покупку, вместо этого приложение падает в момент валидации. А это значит, пока защита работает, и работает хорошо, посмотрим сколько времени потребуется чтобы её сломать. :)
Tags:
Hubs:
+3
Comments 18
Comments Comments 18

Articles