Блог

У нас есть приложение для iOS, которое взаимодействует с различными веб-сервисами в серверной части. Однако серверная часть хочет подтвердить, что запрос, поступающий к ней, исходит от нашего действительного приложения для iOS, а не от повторной атаки или атаки «человек посередине». В конечном итоге все наши вызовы будут переведены на https. Однако есть ли какой-либо способ, которым серверная часть может подтвердить, что запрос поступает из нашего законного приложения? Мы думали использовать криптографический одноразовый номер для каждого запроса, но это все равно было бы подвержено атаке «человек посередине». Существует ли какой-либо обмен сертификатами, который можно использовать между приложением iOS и сервером?

TLS и SSL поддерживают аутентификацию клиента с использованием сертификатов. NSStream может поддерживать аутентификацию на стороне клиента, но я не смог найти способ сделать это, не переходя к использованию OpenSSL для фактической реализации.

Добавление:
ASIHTTPRequest поддерживает клиентские сертификаты начиная с версии 1.8, так что никакой суеты с его внедрением.

как насчет использования схемы закрытого / открытого ключа, чтобы приложение iOS могло подписывать каждый отправляемый запрос?

если схема закрытого / открытого ключа может показаться пугающей, та же идея «подписи» ваших запросов может быть легко реализована путем хеширования вашего одноразового номера с использованием sha1, sha2 или других алгоритмов криптографического хеширования. это было бы довольно просто реализовать (реализация легко доступна), быстро и обеспечило бы более высокий уровень безопасности.

Я бы предложил использовать OAuth. Это хорошо известно, понятно и в значительной степени безопасно, и в случае, если кто-то получит ваш токен, вы можете выпустить новый с обновлением приложения и отозвать старый.

Это общая проблема http, а не только проблема iOS. Фактически, это та самая проблема, которую https призван решить или, по крайней мере, смягчить. Вы можете подписать запрос, использовать HMAC для аутентификации сообщения, использовать дайджест-аутентификацию и так далее, но пока вы используете http, атаку «человек посередине» нелегко обнаружить. Вместо этого потратьте свое время на переход на https как можно быстрее.

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