Безопасность REST API для мобильного приложения

… Если трактовать это иначе …

Мне ткнули ссылку на статью здесь: Что должен знать специалист ИБ на старте (комментарий)

А трактовку здесь: Что должен знать специалист ИБ на старте (комментарий)

Суть такова: если Вася заключил с фирмой «рога и копыта» не трудовой договор, а любой другой (ГПХ) и в этом договоре есть в перечню выполняемых работ: защита данных, криптография, шифрование, прочие что требует наличие лицензии, то применяют статью УК РФ!

О фактах применения не слышал.

Надо просто использовать ssl с клиентским сертификатом. На сервере должен быть ЦС, выпускающий сертификаты для клиентов. Запрос на login URL сервер обрабатывает без проверки клиентского сертификата. В этом запросе он ждёт логин, пороль, и csr certificate signing request. Проверяет логин пароль, проверяет, что cn csr-а равен логину, использует ЦС для выпуска сертификата, передаёт сертификат клиенту в ответе. Клиент сохраняет сертификат. Запросы к остальным url-ам делаются с клиентским сертификатом. При этом на клиенте вводить пароль не требуется, а сервер принимает только выданные им сертификаты.

Так если ты перехватил любой запрос - у тебя есть сертификат. Если он сохраняется перманентно в телефоне - так же есть возможность сдампить его.

Ты в курсе как ssl работает? Сертификат содержит только публичный ключ. Парный ему приватный ключ генерируется один раз и никогда никому не передаётся. В процессе ssl handshake стороны проверяют, что каждая из них знает парный её сертификату приватный ключ. Поэтому перехват сертификат, что северных, что клиентских, ничего атакующему не даёт.

Тогда чем это отличается от того что происходит в HTTPS? Или подразумевается что доступ к сертификату внутри приложения сложнее получить чем к системному?

Против копирования приватный ключей – надо пользоваться системным апи при генерации ключевых пар. Что там на андроиде не знаю, наверное libnss3. У него абстракция security device, для доступа к которому нужно знать pin. Пользователь ввёл пин, твоё приложение разблокировали секурити девайс этим пином, и может делать запросы к девайс на шифрование и расшифровку. Приватный ключ при этом остаётся внутри девайса. Девайс может быть программным или аппаратные (смарт-карта, tpm, и т.п.)

Обычно в https нет клиентского сертификата. Только клиент проверяет подлинность сервера. Сервер подлинность клиента не проверяет.

В https с клиентским сертификатом обе стороны проверяют подлинность друг друга.

Если трактовать это иначе

Посмотрим на эту проблему со стороны власти. Обязанностью Президента есть гарантировать соблюдение Конституции РФ, включая статью 23. Рассмотрим для упрощения только эту тему, есть 3 мнения обеспечения целостности и приватности передаваемых в сети данных:

1. Использовать XOR

2. Использовать HTTPS

3. XOR не дает гарантии целостности и приватности передаваемых данных. В HTTPS заложили уязвимость и его нельзя использовать для гарантии целостности и приватности данных. Необходимо отказаться от предлагаемого HTTPS вообще или дополнить его внутри/с наружи тем что дает гарантии целостности и приватности данных.

Допустим 1. предложил использовать XOR для создания тунеля между офисами и филиалами фирмы, а 2 предложил использовать HTTPS между банком и его клиентами. Заключили договора, взяли деньги и сделали как описано в пунктах 1 и 2. С позиции власти это преступление из-за некомпетенции или умышленный вред ибо данными средствами целостность и приватность данных гарантировать нельзя. Для исключения «шифровальщиков» тунелей с XOR и «безопасников» для банк-клиента с https государство вводит лицензирование. Если лицензирования не будет то «шифровальщики» с XOR и «безопасники» с HTTPS будут причиной нарушения 23 статьи Конституции РФ.

«Единая Росия» неоднократно призывала к обсуждению проблем Законов РФ в сфере ИТ. Но по известной причине ей не помогли. По этому и законы такие неоднозначные.

Хоть предполагается, что статья применяется только когда есть комерческие договорные отношения. И не применяется в любых других случаях: домашние разработки и использование, научные, любая наемная работа в сфере трудовых отношений. Стоит добавить в Закон явной конкретики, а то будет как в старом советском анегдоте:

• ты за что 10 лет сидьшь?

• да за ничто…

• лжошь, за ничто дают всем по 5.

Допустим 1. предложил использовать XOR для создания тунеля между офисами и филиалами фирмы

Почему-то звучит как предложил использовать бревно для организации морской торговли)

Тем не менее оно здесь звучало: Безопасность REST API для мобильного приложения (комментарий)

Скремблеры они разработаны для удобной модуляции сигнала при передачи в физической среде и к гарантиям целостности и приватности отношения не имеют.

Если кому интересно в итоге решили использовать дополнительно шифрование для сенсетивных полей типа пароля с генерацией клиентского сертификата который может быть временным на сессию либо храниться в Keystore который по-идее должен обеспечивать безопасность.

Решение программистов :)

Админы подымают шифрованный тунель отдельной прогой и пускают все через него.

На телефоне как ты поднимишь шифрованный тунель для каждого юзера?

какой-нибудь веб-тунель

с динамической солью?

как клиент регистрирует пароль?

сервер знает пароль?

Сервер посылает публичный ключ при старте сессии, клиент генерирует себе собственную пару, шифрует данные своим ключем и шифрует свой ключ публичным ключем сервера и посылает оба назад.

Сервер соответственно разшифровывает клиентский ключ и им потом данные. Из хороших свойств - оба ключа могут быть временными на сессию, не обязательно ничего хранить на клиенте.

Но ведь для него нужны сертфикаты в итоге все равно? Если да - то в целом уровень безопасности тот же же.