LINUX.ORG.RU

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

 , , , ,


2

1

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

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

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

★★★★★

Если у атакующего есть рут на клиентской стороне - у него есть тысячи возможностей.

Атака реальна, если чел зарутовал смарт и установил с виду прилично ведущий себя софт. Поэтому, к примеру, (многие? некоторые? все?) банковские клиентские приложухи отказываются работать на рутованых смартах.

olelookoe ()

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

Здесь не все по ссылкам ходят. Напиши выдержку здесь.

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

Атака реальна, если чел зарутовал смарт

Если используются системные сертификаты можно без рута - ставим свой сертификат и через локальный VPN делаем mitm (adguard так делает).

Поэтому, к примеру, (многие? некоторые? все?) банковские клиентские приложухи отказываются работать на рутованых смартах.

Сейчас везде magisk, так что детектить рут или разлоченый бут бесполезно.

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

можно без рута - ставим свой сертификат и через локальный VPN делаем mitm

Но тебе нужен доступ к телефону чтобы поставить свой сертификат, разве нет? Если есть доступ для установки сертификата я считаю это тот же уровень что и рут.

Сейчас везде magisk, так что детектить рут или разлоченый бут бесполезно.

Не знаком с magisk, расскажи подробнее?

loz ★★★★★ ()

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

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от anonymous

В итоге почитав статеек, СО, форумов пришел к выводу что собственно говоря никак не получится. Более того похоже что и Гугл и Фейсбук отправляют текстовый пароль по HTTPS.

Есть левые сервисы которые помогают определить что запрос прислало твое настоящее, неизмененное приложение (https://approov.io/) что немного помогает с тем какие запросы могут приходить.

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

но сессионный токен короткоживущий

Насколько например? Один час?

рефреш передаётся клиенту только раз, при аутентификации, его перехватить сложнее. А ещё, рефреш можно оставить на бэке.

Типа делать рефреш без запроса логина у пользователя? А можешь подробнее про то как оставить его на бэке?

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

Насколько например? Один час?

Нет, совсем мало, несколько минут.

Типа делать рефреш без запроса логина у пользователя?

Нет конечно, но он долгоживущий. В некоторых случаях практически вечный, до перелогина.

А можешь подробнее про то как оставить его на бэке?

Я могу ошибаться, но при истечении сессионного бэк, у которого рефреш, сам генерит новый сессионный и отправляет его клиенту.

vvn_black ★★★★★ ()

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

Я таки не понял, ты хочешь защититься от мужика посередине или от собственного пользователя?

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

несколько минут. В некоторых случаях практически вечный, до перелогина.

Тогда не очень понятно насколько это поможет, по-сути он становится новым токеном, просто надо залогать несколько минут траффика вместо одного реквеста.

сам генерит новый сессионный и отправляет его клиенту.

А как сервер отправит используя REST?

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

От мужика) просто используя оригинальное приложение например он не сможет отправлять кастомные запросы с токеном, придется сделать логин. Логин немного сложнее перехватить потому что он происходит раз в некоторое время, а токен летает с каждым запросом.

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

Если есть доступ для установки сертификата я считаю это тот же уровень что и рут.

Нет, это штатная возможность. Конечно нужен доступ к устройству, но как я понял именно от пользователя ты и хочет защититься (что возможно, но только пока ты Неуловимый Джо).

Не знаком с magisk, расскажи подробнее?

https://4pda.ru/forum/index.php?showtopic=774072 Рут + скрытие рута + репа с крутыми аддонами. Де-факто это стандарт в 2019, позволяет обмануть даже gpay.

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

От мужика) просто используя оригинальное приложение например он не сможет отправлять кастомные запросы с токеном, придется сделать логин. Логин немного сложнее перехватить потому что он происходит раз в некоторое время, а токен летает с каждым запросом.

Ну смотри, я в этом нихрена не понимаю, поэтому меня не слушай.

Проблема номер раз: Мужик может перехватить токен из любого запроса, сформировать свой запрос, положить в него токен и отправить.

Решение номер раз: Используем какой-нибудь hmac.

Проблема номер два: Даже с использованием hmac мужик может может перехватить запрос и повторять его снова и снова по своему усмотрению.

Решение номер два: В запросе нужна какая-то динамическая компонента, допустим счётчик запросов. Сервер ожидает запрос номер один. Пользователь отправляет запрос номер 1. Запрос, включая номер, «подписан» с помощью hmac. Сервер его исполняет и ожидает запрос номер два. Мужик перехватывает запрос номер один и повторяет его. Сервер его не исполняет, потому что ждёт запрос номер два. Если мужик меняет номер запроса на два, то сервер его тоже не принимает, потому что сломался hmac.

Проблема номер три: Сервер и клиент должны как-то обмениваться ключём для hmac. Ключ может перехватить мужик.

Решение номер три: Обмениваться можно при первом логине каким нибудь диффи-хелманом. С помощью логина/пароля с этого девайса больше никогда не логинится, использовать то, что мы уже нагородили, пароль сразу забыть.

Проблема номер четыре: Мужик может перехватить пароль при первом логине. Алсо, у мужика рут, он может тупо прочитать ключ для hmac из памяти.

Решение: Жопа. Мы нагородили бесполезную фигню.

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

Но вообще идея обменятся каким-то ключом для конкретного девайса при первом логине и больше не иметь на этом девайсе главного пароля мне нравится.

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

Есть всякая хардварная фигня, на данные из которой ни рут, ни ядро не имеют доступа (теоретически). Trusted platform module, arm trustzone, вот это всё. Но я тут совсем не копенгаген, гугли сам.

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

Главный пароль - имеется в виду юзерский пароль? Его стоит требовать раз в какое-то время это точно.

А ключ (я так понимаю для шифрования) хранить постоянно или как?

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

Главный пароль - имеется в виду юзерский пароль? Его стоит требовать раз в какое-то время это точно.

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

Первый логин с девайса – юзер вводит пароль. Сервер генерирует токен и отдаёт клиенту. Клиент сохраняет токен и забывает пароль. При следующем запуске клиент логинится с помощью токена.

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

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

А ключ (я так понимаю для шифрования) хранить постоянно или как? Для подписи. Хранить постоянно. Автоматически обновлять.

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

Более того похоже что и Гугл и Фейсбук отправляют текстовый пароль по HTTPS.

Да что там гугл с мордокнигой, даже ЛОР пользуется https для отправки паролей!

Там где реально нужна безопасность, только один https использовать не стоит.

anonymous ()

А в чем проблема сделать простейшую аутентификацию с ключом? Даже по http прокатит.

Авторизация: запрашиваешь у сервера разрешение на авторизацию, получаешь некий ключ. Далее его используешь как соль, добавляя к MD5 пароля и вычисляя SHA512 результата + отправляешь SHA512 от случайной последовательности с той же солью. Отправляешь серваку. Если все ОК, тот вычисляет MD5 от твоей случайной последовательности и использует это в качестве дешифрующей.

Аутентификация: все, что клиент хочет отправить серверу, он XOR’ит своей дешифрующей последовательностью. Сервер принимает это дело и опять XOR’ит тем же самым. И никакой man-in-the-middle не сможет этот обмен раскусить.

Прикола ради можно авторизацию повторять каждые N единиц времени.

anonymous ()

P.S. Только полный дегенерат будет посылать пароль через интернеты в явном виде! Даже если используется https.

Что мешает хранить хэш пароля и сравнивать с тем хэшем, что присылает клиент? Естественно, соль использовать каждый раз разную.

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

отправляешь SHA512 от случайной последовательности с той же солью Если все ОК, тот вычисляет MD5 от твоей случайной последовательности и использует это в качестве дешифрующей.

Не понял, как это сходится? На сервак приходит хеш пароля и хеш случайный, у сервака есть только соль, что он может тут проверить?

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

Что мешает хранить хэш пароля и сравнивать с тем хэшем, что присылает клиент? Естественно, соль использовать каждый раз разную.

Если клиент хешует - как клиент и сервер могут договориться о соли?

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

А есть описание того как они работают с мобильными клиентами? Главный вопрос хранят ли они ключи на клиенте?

Серверов несуществует!!!

Все клиентское ПО создает крыптоучетки (ключи) и хранит их запаролеными только у создателя.

Необходимо делать бекап крыптоучетки. Уже года 3 по инету ходит злобный вирь и херит крыптоучетки TOX.

Если система скомпрометирована, то вирус может кейлогером стырить пароль и твою крыптоучетку.

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

Все клиентское ПО создает крыптоучетки (ключи) и хранит их запаролеными только у создателя.

А как они хранят на мобилках? В Android Keystore / аналоге для iOS?

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

Оффтопик немного. Как там nim поживает. Вроде как заредизился, но после этого опять тишина. Попробовал искать либо. Но что-то не густо.

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

Не релизиться же каждый месяц) Я на самом деле давно не смотрел его, много очень фич завезли, на замену питону и плюсам должен хорошо подходить. PS пора аватарку менять)

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

А как они хранят на мобилках? В Android Keystore / аналоге для iOS?

Не скажу, надо смотреть..

А вообще в РФ сегодня как с разработкой меседжеров которые хоть какую-то крыптографию используют? Ну или в общем сетей с шифрованием типа замены/дополнения HTTPS?

С одной стороны:

Статья 23, Конституции РФ: Что должен знать специалист ИБ на старте (комментарий)

  1. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных [b]и иных сообщений[/b]. Ограничение этого права допускается только на основании судебного решения.

С другой стороны подзаконные акты требуют лицензирования деятельности по шифрованию: Что должен знать специалист ИБ на старте (комментарий)

Федеральный закон от 04.05.2011 N 99-ФЗ (ред. от 02.08.2019) «О лицензировании отдельных видов деятельности»

Статья 12. Перечень видов деятельности, на которые требуются лицензии

  1. В соответствии с настоящим Федеральным законом лицензированию подлежат следующие виды деятельности:
  1. разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, …

и

«Уголовный кодекс Российской Федерации» от 13.06.1996 N 63-ФЗ (ред. от 02.08.2019)

УК РФ Статья 171. Незаконное предпринимательство

  1. Осуществление предпринимательской деятельности без регистрации или без лицензии в случаях, когда такая лицензия обязательна, ….

…. , либо принудительными работами на срок до пяти лет, либо лишением свободы на срок до пяти лет …

Сделаешь хорошее дело, зашифруешь трафик своего приложения и в благодарность от Путина и «Единой России» 5 лет тюрьмы!

Вот посмотрите, даже архиватор забанили, наверно потому что кнопочку имел «заархивировать с паролем»: http://www.7-zip.org/

А линуксовую версию не банят: http://p7zip.sourceforge.net/

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

У каждой страны свои тараканы!

А, с этим я особо не волнуюсь потому что моя разработка за пределами РФ :)

Сегодня, во времена геноцида, очень много стран ссучились. Мне точно известно:

США - запрет на экспорт криптографии. Разработка и внутренне использование разрешено.

РФ - как выше написал, запрет на разработку и распространение.

Англия - точно не скажу, кажется есть «запрет на крыптографию которую нельзя расшифровать» - слова их премьерминистра.

Канада - Кажись все разрешено, поэтому OpenBSD разрабатывают у них.

Германия - было все разрешено, поэтому разработку GPG перенесли к ним. Но сегодня времена меняются…

Швейцария - Кажись все разрешено. Причем разрешение гарантируется их законами, примерно как у нас: Что должен знать специалист ИБ на старте (комментарий) только противоречащие Конституции подзаконные акты их власть не принимает…

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

Статья 12. Перечень видов деятельности, на которые требуются лицензии

В соответствии с настоящим Федеральным законом лицензированию подлежат следующие виды деятельности:

разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, …

IANAL, но скорее всего это только для случаев, когда ты официально хочешь сертифицировать свой говнокод как некое средство для шифрования. Типа КриптоПро и прочего подобного шлака.

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

gcc -lssl ...

и сразу с вещами идти сдаваться в полицию 8).

im-0 ()