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