Pull to refresh

Comments 63

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

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

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

"Зачем, а главное... "
Потому программисты второго курса образования по другому не умеют.

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

Т.е. никакого реального вектора атаки вы не нашли, но «как-то некрасиво»?

То есть вы уже забыли историю с суверенным CA-сертификатом, который время от времени хотят протолкнуть на устройства?

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

Я суверенный сертификат в качестве абсолютного примера вектора атаки привёл.


Точно так же сертификат для MitM может быть установлен, например, на корпоративных устройствах. Потом люди туда ставят свои клиент-банки, ведь им там удобненько, а просьбы безопасников так не делать игнорируются. А потом возникают вопросы: «А как так вышло, что мои данные утекли?»


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

Вот убьют — тогда и приходите, ага.

Вот убьют — тогда и приходите, ага.

Давайте уж тогда защищаться от взлома wifi с нормальным шифрованием, от взлома ssl с кривыми, от атаки на заморозку памяти устройства, что там еще есть из возможно-вероятных атак?
Сейчас HTTPS защищен. Я не очень вижу смысла оценивать, как повлияет раскрытие данных в защищенном канале, потому что ровно в таких же каналах гоняется критичных данных в сто раз больше, и все живут нормально, и думать «ой, а чо это там мои паспортные данные, кошмар какой» это лишняя паранойя. У вас при оплате данные карты там еще гоняются. И данные с госуслуг. Почему за них не боитесь? Кроме того, если кто-то имеет возможность перехватывать ваш https-трафик, он эти данные все равно получит, даже если они будут запрошены не при загрузке приложения, а при оплате через СБП, например, просто чуть подольше подождать надо.
Ругать разрабов же за то, что они не подумали о том, как защититься от ситуации «на корпоративном устройстве поставили свой сертификат, он утек, и из-за этого перехватили данные паспорта клиента» это очень странно.

Хм, так как там нет закрытых списков сертификатов на клиенте, то уязвимость через MitM точно есть.
Кроме того, зловредное приложение на рутованном андроиде точно так же сможет смотреть трафик.
Так как пароль хранится на устройстве, то для андроида с кривым security storage (а такие модели встречаются, хотя в РФ и весьма редко) можно подсмотреть его прямо в хранилище.

Это те вектора, что тривиально приходят в голову и только на основании статьи.
Но так как при разработке приложения, похоже, про безопасность вообще не думали, то, подозреваю, там еще много разных дырок.

Вектор атаки потенциально примерно такой - угнали приложение через удаленное восстановление доступа, взяли кредит в приложении. Банк перезвонил проверить и для идентификации спросил паспортные данные или мошенник от имени клиента сам позвонил в ТП банка что-нибудь подтвердить.

Не факт, что это применимо к данному банку в данное время, но где гарантии, что завтра это не будет возможно?

Это, конечно, в этой схеме косвенный дополнительный фактор, но тем не менее.

Вообще достаточно самой идиотичности ситуациии когда одна сторона которой известна некая информация передает ее другой стороне, которой она еще более известна. При этом это не связано с авторизацией.

Вообще достаточно самой идиотичности ситуациии когда одна сторона которой известна некая информация передает ее другой стороне, которой она еще более известна.

почему идиотично? Простите, но это так же идиотично, как если бы Госуслуги за Вас автоматически заполняли номера документов, но они именно так и делают, если Вы вошли в систему легитимно (!)

А сделано (в Госуслугах) понятно для чего - чтобы снизить вероятность человеческих ошибок при заполнении форм и сделать сервис более человеческим...

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

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

Тут есть тонкий момент, что ни Банк, ни Госуслуги НЕ ЯВЛЯЮТСЯ мастер системой для паспортных данных, ИНН, СНИЛС и всего прочего, что на самом деле выпускается 3-ми сторонами, а пользователь просто является владельцем этих данных. В теории, конечно, те же Госуслуги могли бы синкануться с базой МВД или налоговой, но это опасная история, потому что запросто может быть ошибка данных и это обязанность пользователя убедиться в том, что все формы заполнены верно.

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

Что не отменяет идиотичность всего этого и на госуслугах. Просто формы заявлений взяты из офлайна. Взять хотя бы прекрасную графу - наименование подразделения выдавшего паспорт. Зачем это вообще когда рядом айдишник этого подразделения?

Тут, конечно, виноват не именно сервис госуслуг, а общие традиции документооборота в ведомствах.

Тянется это даже не с доинтернетных, а с докомпьютерных времен. Чтобы при отправке запроса по почте можно было переписать наименование подразделения на конверт прямо из паспорта. Сей-час им самим неудобно, по этому ввели "код подразделения". Но всё равно эту идиотскую графу надо заполнять во всех заявлениях и попробуй ошибись хоть на букву.

Удивительно, что даже айтишники привыкли и не видят в упор на сколько это всё дремучее мракобесие.

Не по http же гоняют.
Ну может не оптимизировано немного по запросам. Но уязвимости то вы не нашли никакой. К чему выводы про «плевать на клиентов»?

Да просто показывает отношение к безопасности. Аутентификация без разглашения? Не, это слишком новые технологии. Прикреплять сертификаты для защиты от Майор-in-the-Middle и VPN-для-просмотра-LinkedIn? Не, не слышали. Разглашать личную информацию только по необходимости? Зачем, это только всё усложняет. С такими вводными, что может твориться в тех местах, которые вы не видите?

Без обид, но мне кажется, вы про возмущаться. У нас в мобильном приложениии -финсектор, реализовано, что при наличии root, пользователь посылается лесом. Увеличивает безопасность -да, но вам бы это не понравилось ))))

UFO landed and left these words here
при наличии root, пользователь посылается лесом
Ну вам ведь прекрасно должно быть известно, что это легко скрывается в том же приложении, которое этот root дает? :)
  1. Отправлять данные, которые заведомо не используются клиентом - это либо огромный косяк архитектора проекта, который такое захотел, либо косяк программиста, который поленился скрывать данные или выдает напрямую объект, например из БД, простая прокси бы полностью решила проблему;

  2. Персональные данные отправлять без необходимости - не самая лучшая затея, потому что можно довольно легко организовать канал утечки, с последующим иском банку на пару млн рублей каждому пострадавшему ( Это не призыв, а лишь констатация факта того, что данные могут быть украдены );

  3. HTTPS не дает 100% защиту, украсть данные можно внутри их сети, потому что там они так же передаются. По хорошему персональные данные без явного запроса клиента (хотя зачем они ему?) никуда не должны уходить с сервера, где они храняться;

  4. При создании защищенных сетей не бывает такого понятия как "ну и что", вы обязаны ЛЮБЫЕ факторы взлома или утечки данных пресекать на корню. Если этого не делается, значит служба безопасности Раффайзена не работает вообще, хотя возможно, что их дурят, но тогда это вопрос об их компетентности.

На месте руководства Раффайзена стоило бы принять меры.

Если покопаться, то в любом банке есть проблемы с безопасностью. По крайней мере некоторые, вместо правильной реакции(закрытие дыры), стремятся закрыть человека который её выявил или как минимум его игнорировать пока он не вынесет проблему наружу(а там уже можно и закрыть/оштрафовать за публикацию).

Всё это очень легко может засветиться. Например, если у них внедрено логирование запросов/ответов, то все пароли и паспортные данные могут стать видны разработчикам/QA на саппорте. Я сам так косячил, когда секретный ключ засветился в логах. Всё-таки у логов обычно более широкая аудитория, чем у БД с токенами/паролями.

Ну, вообще-то в логах чувствительные данные обычно маскируют. Куча стандартных библиотек для этого есть.

Это в идеальном случае. Лучше всё-таки не вводить потенциальные дыры, ожидая что кто-то где-то в другом месте их не только прикроет, но и будет держать прикрытыми в будущем навечно.

Oauth с grant_type password в мобильном приложении - это и есть дыра в безопасности.

Что почитать? Спасибо.

Ну вот, например, перечислены возможные векторы атаки https://www.identityserver.com/articles/fact-sheet-the-dangers-of-using-the-password-grant-type-with-mobile-applications

Основной вопрос в том, зачем они отдают те данные, которые не нужны и не запрашивались?

Как мне пояснили в твиторе, используется для автоматического заполнения форм в различных разделах приложения. Однако я не увидел в запросах отправки паспортных данных, может там заявки на кредиты всякие, не знаю. Да и с таким же успехом могли бы server-side дозаполнять формы. Разработчиков надо просто побить палкой больно, чтобы они так не делали, видимо

Во-первых, да. На сервере. Во-вторых, эти данные можно запрашивать только когда это реально нужно, а не всегда при входе клиента в приложении.

Я не знаю как там организовано, но логично разделить запросы по тематике - "дай данные по основному ДУЛ клиента", "дай остатки по счетам", "дай лимиты", "дай тарифы"... И каждый запрос выполнять ровно тогда, когда эти данные необходимы для отображения в приложении.

У нас на корпоративном сайте была одна страница, где на основе заполнения <input> полей js-скрипт заполнял hidden поле формируя в нем запрос

execute procname @input1=1,@input2=2,&etc

Ну вы поняли.. теперь человек ответственный за это работает на один из ведущих банков страны. Причем без шуток -_-

Как человек работающий в финтехе, хочу сказать что QA такому не учат.) автору респект, дам ссылку на статью на ближайшем митинге, проверим свой проект на подобное. Вроде кроме юида ничего не шлём, но всётаки.

ой тут скучно как на кладбище: "крипта" одним словом, только деньги туда и сюда. но если вот прям хочется, то готов рефералочку в свою компанию заслать, нужно только CV :) отправьте мне на почту пожалуйста, если заинтересованы.

Если реально хочешь и не в крипте, то пиши в личку или в телеграмм @dphil

Банк подойдет?

В Москве есть вакансии мобильной разработки, Фронт, Джава. Есть системные аналитики, QA, сисадмины...

На Core уровень (IBM i) разработчиков нет.

Вроде кроме юида ничего не шлём

обычно достаточно session_id если таковой вообще есть.

У меня Райффайзен стоит на первом месте в личном антирейтинге банков.

Как банк, которому вообще пофиг на то, чтобы зачисления бились со списаниями. Например, чтобы 100тыс. - 95 тыс. = 5 тыс (у Райффайзена своя математика в котором ответом на это выражение будет 0 рублей).

До сих пор висит счёт, где расхождение на 130 тыс. руб. Тех. поддержке - пофиг.

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

Всё ленюсь сходить, закрыть эту помойку.

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

Много лет назад в личном кабинете физика в Райфе слетали сессионные куки каждые 5 минут. Поддержка советовала пользоваться интернет-эксплорером 6. А кабинет юрлица был на ActiveX, в котором, если он вообще не падал за три минуты, чтобы найти нужную транзакцию, надо было мышкой и глазками проскроллить таблицу, похожую на какой-то дефолтный датагрид. Ни поиска, ничего.


Смотрю, с тех пор не особо подход поменялся.


При этом от чешского Райфа были исключительно положительные впечатления. Но мы ж понимаем, что, кроме бренда, ничего общего между ними нет

Это вопрос баланса рисков, который надо явно доводить до разработчиков (собственно, одного я уже неофициально проконсультировал, и он не из Райффайзена).

Собственно, главный вопрос - что именно прибивать гвоздями. Если прибивать один корневой сертификат, то банк не сможет сменить вендора в случае компрометации, санкций, изменения допустимой политики использования и прочих ситуаций, когда этим CA больше пользоваться нельзя. Если полагаться на системное хранилище, возникает риск MITM-атак через установку "доверенных" сертификатов. В итоге я посоветовал держать два сертификата, один активный и один запасной, от разных CA (или просто иметь возможность быстро перевыпустить что надо в другом, заранее обговоренном, CA), и прибивать в клиенте гвоздями корневые сертификаты этих двух CA.

В случае изменения CA просто выпустить новую версию приложения, старая работать перестанет. На современных мобильных пплатформах приложения обновляются довольно часто.

Брат работает в немецком банке по фрилансу, этот банк так же в открытом виде гонял данные. ЦБ Германии как то прознал про этот беспредел, дал 6 месяцев на исправление и 3 месяца на тесты. Сказал, если не исправят, то "звезда" вашей лицензии. В авральном порядке всех кинули на проект.

"ЦБ Германии как то прознал про этот беспредел". Прошу прощения, но представил отрывок с бункерным истериком из известного фильма.

UFO landed and left these words here

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

UFO landed and left these words here
Причём если деньги пришли, а баланс был околонулевой или недостаточный для покупки/перевода, то оплатить/перевести что то через приложение нельзя, пишет недостаточно денег. Надо как нибудь наоборот попробовать, когда денег на карте уже нет(автоплатёж/автоперевод и т.п.), а приложение считает иначе. Но опасно это, ещё «хакером» «взломавшим» банковскую систему объявят и уголовку повесят.

Похоже, что дерево DOM строится только при начальном входе с логином паролем, двухфакторкой. Перед его показом ещё вывешивается "доброго времени суток" и вот после этот DOM не добавляет ноды, тоесть можете открыть новый счёт, но слева в колонке со счетами вы его не увидите, пока не разлогинитесь/залогинитесь снова. Это не баг, это by design НеОбновление баланса это видимо тоже родом из этого же фреймворка.

UFO landed and left these words here

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

баланс не обновляется в открытом приложении, если он изменился не из этого приложения. При свайпе вниз на главном экране тоже, при входе/выходе в/из счета тоже ничего не меняется

Подтверждаю, есть такое
*в немом ужасе думает об уровне специалистов, которые делают это*

В тинькове ещё хуже - при открытии приложения показывается баланс с прошлой сессии и автоматом редко сам обновляется. Видишь что на счету 2350, набираешь полную корзину продуктов, а после отлупа оплаты баланс обновляется и оппа, а ведь там 430 р.

Баланс да, бывает не сразу. Ещё лимиты на карте не сразу обновляет после изменения и гадай: изменилось или нет.

Да все просто. Программисты не задумываться о безопасности, безопасники аудит проводят тулами от каких-то вендором, не вникают. По логике любое изменение в API должно согласовываться с безами, но у молодёжи всякие спринты, в которые нужно успеть заскочить, а безопасники слишком долго согласовывают, что мешает каждую неделю новому релизу выходить, как итог, ИБ исключают из процесса. И ещё у бизнеса есть привычка произносить фразу: "все риски мы берём на себя". Никогда не понимал, что это значит, но действует. Не видел, что бы из-за сработавшего риска, который бизнес взял на себя, из бизнеса кого-то уволили.

Так и не понял, в чем техническая проблема, если все под https?

Обычная история об compromised клиент, когда добавлен доверенный сертификат

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

А последнее время райф вообще оставляет ощущение поделки либо помирающей конторы.

Например, чат в online.raiffeisen.ru через который делаются всякие нужные вещи уже с год не работает в firefox, потому что текст сжимается до колонки в 10 пикселей.

Сейчас воспользовался другим чатом chat.raiffeisen.ru, чтобы туда войти достаточно ввести имя и телефон, при этому СМС подтверждения не требуется. Захожу, прошу открыть счёт, ответ "хорошо, откроем счёт, скинем реквизиты на почту, ваша почта xxx@yyy актуальна?". То есть первому неавторизованному встречному сходу как минимум сливают мою личную почту. Скорее всего наинженерить и что-то посерьёзнее.

Потом, они подозрительным образом позакрывали все отделения и банкоматы в округе (районы Лосиноостровский, Южное Медведково Москвы), а те что остались работают через раз. По карте хорошо видно что на большей части Москвы банкоматов в пешей доступности не осталось.

Only those users with full accounts are able to leave comments. Log in, please.