LINUX.ORG.RU

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

 , , , ,


2

1

Добрый день, допустим есть HTTPS REST API, внутри которого авторизация происходит один раз за сессию и после используется JWT токен.

Возник интересный вопрос - есть ли возможность защититься от мужика посередине который получил возможность читать траффик, например так ?

Ведь даже без логина пока токен валиден он может делать любые запросы. Как проверить подлинность клиента не могу придумать. Что-то можно сделать в этой ситуации? И насколько реальна такая атака? Все-таки требуется доступ к внутренностям телефона.

★★★★★

Ответ на: комментарий от im-0

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

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

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

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

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

anonymous ()
Ответ на: комментарий от loz

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

iliyap ★★★★★ ()
Ответ на: комментарий от iliyap

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

loz ★★★★★ ()
Ответ на: комментарий от loz

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

iliyap ★★★★★ ()
Ответ на: комментарий от iliyap

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

loz ★★★★★ ()
Ответ на: комментарий от loz

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

iliyap ★★★★★ ()
Ответ на: комментарий от loz

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

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

iliyap ★★★★★ ()
Ответ на: комментарий от im-0

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

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

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

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

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

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

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

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

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

  • да за ничто…

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

loz ★★★★★ ()
Ответ на: комментарий от loz

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

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

anonymous ()

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

loz ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

loz ★★★★★ ()
Последнее исправление: loz (всего исправлений: 1)