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

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

VerificationController от Apple

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

Вот какие проверки входят в VerificationController:

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

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

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

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

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

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

Автор: mOlind