Comments 57
Спешите видеть! Код фронтенда доступен на фронтенде! /s
Ну так кодовая база то едина, что для веба, что для мобильных приложений. Так что на фронтенде доступен код мобильщиков! :)
Даже серверная часть должна делаться так, чтобы утечка её исходников не открывала каких-то явных чисто технических уязвимостей. Про клиентскую часть - хоть мобилку, хоть веб - и говорить нечего. Там скорее всего нет никаких секретов. А если и есть, то и без сорсмапов до них дотянуться несложно.
Ну, если бы все писали идеальный код - в мире были бы все счастливы и базы данных с ПД не утекали бы. Но увы, реальность иная.
Мало кто что будет делать с исходниками, вспомнить тот же Яндекс. Ну утекло, ну поржали, и всё. А может быть и не все - кто то мог взять наработки и заюзать у себя. Или найти там дырку... Вариантов исхода очень и очень много.
так код фронтед должен быть минифицирован. иначе свою зарплату сотрудники получают зря
Ну так код действительно минифицирован. Только вот с сохранением сорсмапов...)
А если не будет, то что?
Что в этом коде может быть такого опасного?
В этом коде будут ссылки на внутренние ресурсы, комментарии разработчиков и в целом будет доступна логика в исходном виде.
То есть, можно будет к примеру взять исходники и выделить из них библиотеку для работы с API. Не сидеть ночами в отладчике, не изучать что, куда и как нужно передавать, а взять уже готовую библиотеку для работы с API, и писать свои клиенты.
Ну а хорошо это или плохо -- смотря с какой стороны посмотреть. Я не думаю что какой-либо банк будет доволен тем, что к нему в API будут ходить нелегитимные клиенты.
Не сходят. API так не работает. Минификация это заборчик по колено в чистом поле — бессмысленно. Только на размер загружаемых джээсников влияет.
Не сидеть ночами в отладчике, не изучать что, куда и как нужно передавать, а взять уже готовую библиотеку для работы с API, и писать свои клиенты.
Вам никогда не говорили, что security through obscurity это плохая идея?
что к нему в API будут ходить нелегитимные клиенты.
Решается настройкой бэкенда (списком доменов, откуда разрешено вызывать бэкенд). CORS, вот это всё.
Вам никогда не говорили, что security through obscurity это плохая идея?
А я разве говорил о том, что минификация чудесным образом решает все проблемы? Согласитесь, ведь взять готовую либу это гораздо проще, чем самому с нуля делать.
А ещё, я прям в статье написал о том, что в теории можно самому собрать приложение под тот же андроид, и там внезапно и про CORS думать не надо.
Есть такая штука - "принцип Керкгоффса". Его можно (и нужно) применить к любому коду, не только к криптографии. А говоря доступным языком, для правильно спроектированной системы знание API и даже исходного полного текста не приводит к компрометации системы.
Утекающие сорсы -- это далеко не только лишь одна безопасность и вероятная компрометация всей системы.
Утекающие сорсы это ещё интеллектуальная собственность.
Конкретно в данном случае, который описан в статье, в целом ничего опасного нет -- это ведь по сути просто обычный клиент, который ходит в апи и рисует красивые формочки. Но если бы все так считали -- то наверное все банки, которые под санкциям, могли бы спокойно выпустить свои банк-клиенты в опенсорс, чтобы любой Вася/Петя/Катя могли собрать их и установить на свой айфон не посещая офиса сбера. Но так почему-то не делают.
Описаный в статье возможный вариант использования (собрать функционально идентичное приложение но со своими закладками) тоже можно реализовать и без наличия исходников. Только временные затраты будут несоизмеримо выше, чем при наличие этих сорсов. И если ковыряться (а главное, понимать!) в минифицированном и обёрнутом в вебпак js может X специалистов, то вот при наличие исходников количество специалистов увеличивается на порядки.
В целом, используя сорсы (а именно либу, отвечающую за коммуникацию с API) можно делать и безобидные, полезные вещи. Я бы, например, прикрутил бы в свой календарик выплат по облигациям прямую интеграцию с брокером, чтобы прям из апи выдёргивать и весь свой портфель, и все выплаты, вместо того, чтобы содержимое портфеля копировать из quik, а выплаты собирать из апи мосбиржи (что в некоторых местах то ещё удовольствие).
Ну а можно просто сидеть и ковыряться, находить некоторые забавности :)
Вот если бы вы время потратили и прикрутили свой календарик на основе этих API, и рассказали об этом, то они бы мигом поменяли все API и закрырили бы сорцы на зло ;D
Вообще, было бы не плохо конечно так сделать, но ведь брокеров много -- кому-то оно может оказаться и не нужным. А для каких-то случаев можно заюзать например открытое API тинькова. Но календарик уже написан, и решает задачи которые нужно было решать мне.
Немного про него я говорил тут.
Вы всерьез считаете, что достаточно просто собрать приложение и вас куда-то там пустят? Если вы не являетесь зарегистрированным клиентом?
Мобильное приложение банка не содержит никакой бизнес-логики. И не имеет прямого доступа к данным. Оно просто формирует запрос и потом отображает полученный ответ. при этом запрос без аутентификации не пройдет. А привязка там идет не просто к логину-паролю, но и к симке (для мобильного приложения). Смените симку (даже с сохранением номера) и все - вас уже никуда не пустят. Надо идти в банк, говорить что симку поменяли чтобы там произвели определенные действия.
Ну вот в данном примере это приложение брокера. Написано оно на react native и работает на нескольких платформах, включая веб. Из этого можно сделать вывод о том, что ни о какой привязке к сим и быть не может.
Функциональность в них идентичная (за исключением некоторых моментов).
Что (или кто) мне помешает конкретно в данном случае взять слой для работы с API, написать для него обвязку для прохождения всего потока авторизации и выполнения нужных мне запросов? CORS? А что мне помешает указать правильный Origin?
Т.е. там никакой аутентификации нет? Никаких логинов-паролей, ни, тем паче, двухфакторки? Кто хочешь заходи, что хочешь бери?
А зачем тогда что-то писать вообще? Поставили приложение (или зашли на сайт) и вперед - безо всякой регистрации...
А если аутентификация есть, то без логина-пароля далеко вы уйдете?
Еще раз. Приложение это всего лишь дергает REST API. Которое потом дергает какой-то внутренний сервис. А тот уже пойдет дальше - за данными (и тоже не напрямую в БД, а через вызов некоего "сервис-модуля" куда будут переданы параметры запроса). И там на каждом этапе будет нужна аутентификация. Что запрос пришел от зарегистрированного пользователя и запрашиваются именно данные этого пользователя.
Если не пройдете аутентификацию - вас просто не пустят. А чтобы все это обмануть, вам придется изменить код, который лежит совсем в другом месте и работает там, куда вам точно не дотянуться.
То, что вы видите - это просто отправлялщик запросов. А вот проверка насколько правильно сформирован запрос (в т.ч. и индентификация от кого он пришел) - оно лежит и работает совсем в другом месте. Это уже внутренний контур банка, туда вам не пролезть просто так.
Чтобы запрос прошел без аутентификации нужно изменить код, работающий на центральном сервере. А доступ к нему только у сопровождения (у банковских разработчиков доступа туда нет и они что-то на прод сами не могут развернуть, только через заявку сопровождению).
Впрочем, можете попробовать сами :-)
А с чего вы взяли то, что там нет авторизации?
Есть там и авторизация, и двухфакторка, и прочие радости.
И я же сказал про взять слой для работы с API. Да, это по сути REST-клиент, который дергает разные эндпоинты, передаёт туда разные модельки и получает из оттуда. И как удобно изучать всё это? Ковыряясь в devtools или просто взять сорсы, где уже описаны и различные методы в API, и типы данных которые ходят туда-сюда, причем даже с кусочками документации?
Я нигде не говорил что утечка сорсов может (напрямую) повлиять на доступ к каким-то данным, к которым доступа быть не должно. Я говорю лишь о том, что утечку сорсов допускать нельзя, т.к. это открывает кучу различных возможностей, в том числе и не совсем хороших.
Если же взять к примеру брокера от тинкова, то у него есть в открытом виде и документация, и опенсорсные клиенты для работы с их API. А у других брокеров есть? Нету! И для этого наверное есть некоторые причины (ну, например, не хотят показывать говнокод миру, это как одна из причин). И если же у таких вот нежелателей показывать свой код (открывать API для всех) утекают сорсы -- это разве не инцидент?
Я что в статье, что в комментариях пытаюсь донести то, что нельзя допускать никаких утечек, пусть даже они (могут быть) безобиды и не несут никакой угрозы.
Еще раз. Что вы можете сделать нехорошего на основе этих сорцов? Получить какие-то данные? Нет. Только то, что вам доступно в рамках вашей аутентификации.
Что-то поменять? Опять нет - что не положено с вашей аутентификацией вы не поменяете.
Вый поймите - что бы вы там снаружи не делали, внутри все это контролируется - можно вам это или нет. А все что внутри, к этим кодам никакого отношения не имеет - там свои коды они в другом месте.
Ну вот условно. Мобильное приложение -> REST API -> WebService -> Service Module -> Данные на сервере
Что вы увидели? Коды Мобильное приложение и REST API? И что? WebService работает на ESB шине, коды лежат во внутреннем контуре Service Module работает на центральном сервере, коды во внутреннем контуре.
Если вы что-то нахимичите с мобильным приложением или REST API - ну просто получите отлуп от WS. Поправить WS или СМ снаружи вы не сможете никак.
Т.е. ни получить доступ к чужим данным, ни накрутить что-то себе вы все равно не сможете.
P.S. Я ко всему этому никакого отношения не имею. Я работаю на уровне центральных серверов. Просто представляю как все это устроено в банках.
Угнать сеанс пользователя и выполнить нехорошие действия с его правами. Это можно сделать аж несколькими способами - через XSS, фишинговый клиент, или атакой на цепочку поставок.
Правда, не то чтобы закрытые исходники от такого защищали - но порог входа для злоумышленников они определённо повышают.
Ну вы же понимаете что это не уровень исходников уже...
И тут открыты исходники только те, которые дергают апишки. А то, что дальше уже с данными собственно работает недоступно.
Понятно, что все это не есть хорошо. Но это не является критической уязвимостью.
Ну так для злонамеренных действий от имени пользователя большего и ненужно же.
Ну например? Про "угнать сессию" понятно, но тут не про исходники.
Что злонамеренного вы можете сделать, поправив исходники? При том, что контроль того, что вам можно а что нет находится на более низком уровне.
Полностью рабочий неофициальный сайт банка с нескучными обоями, который ворует деньги.
Каким образом?
Что в должны поправить в исходниках сайта чтобы получить доступ к данным другого клиента, а не того, под которым вы авторизовались?
Или вы думаете что там внутри нет контроля того что, вы авторизовались под одним именем, а данные запрашиваете для другого?
Ну нет в банке прямой связи фронта с данными на бэке.
А у меня наоборот, складывается такое впечатление, что вы чуть ли не непосредственное отношение к этому имеете.
Может быть вы даже сможете мне ответить, почему в моём портфеле отображались чужие (ну, т.к. у меня таких не было) активы в аналитике? А вы точно уверены что там из API ничего другого нельзя выдернуть?
Почему вы так уверенны в том, что там всё настолько прекрасно? Люди нигде и никогда не ошибаются? Даже в банках?
А у меня наоборот, складывается такое впечатление, что вы чуть ли не непосредственное отношение к этому имеете.
Увы, но нет.
Альфа-банк, Развитие центральных банковских систем, автоматизация процессов комплаенс-контроля. Все это крутится на ЦС под IBM i (iSeries, AS/400). Т.е. максимум что мы делаем - сервис-модули. И наша тема - это всякие Compliace Check или Customer Terrorism. Ну и совпадения клиентов со списками росфина, комплаенс-проверки платежей для системы расчетов...
Вот когда Вас ошибочно в террористы запишут - тогда это наш косяк :-)
Может вы знаете почему в приложении Альфы регулярно ломается вход по биометрии с Keystore operation failed на Google Pixel 5?
Срабатывает какая-то защита без нормального сообщения для пользователя, коряво реализована аттестация устройства в приложении или баг в Android?
ответ был в классической форме «спасибо за обращение, если у вас возникнут сложности, обращайтесь в службу поддержки email-адрес».
/sarcasm
За MobX лайк
Газпромбанк?
Очень похоже на сбер, учитывая что у них "самокат", "сбермаркет" и куча других приложений в экосистеме на react-native
но может и газпромбанк
Сам я называть банк не буду. Но никто не мешает пройтись по веб-версиям брокерских приложений всех банков из списка системообразующих и найти самому, т.к. как указано в статье -- проблема не устранена до сих пор. Там не сильно то большой список, в теории можно управиться за минут 10 :)
Тогда тем более непонятно, чего скрывать? Если злоумышленникам надо - они и по этой информации найдут. А остальные не особо-то захотят лазить, но если в открытом виде скажите - больше вероятности что шум дойдёт куда надо.
Если переживания из-за возможного наказания - то во-первых, ещё пока никаких противозаконных действий вы не сделали, а во-вторых, если захотят, будут уже и по этой информации пытаться привлекать (не очень успешно, но нервы потрепят).
ВТБ товарищ, втб =)
В целом довольно очевидно, первый кандидат Сбер, второй Альфа, третий ВТБ.
Если переживания из-за возможного наказания - то во-первых, ещё пока никаких противозаконных действий вы не сделали
Вы же знаете в какое непростое время мы сейчас живём. Сегодня сообщить о преступлении это гражданская обязанность, а завтра ты уже можешь стать соучастником, ибо нехрен ходить там, где совершаются преступления. :)
Поэтому, я хоть чуточку, да прикрываю свою задницу. В случае взятия за жопу, можно будет сказать то, что я имел ввиду ГПБ, там вон тоже есть неминифицированные сорсы, и даже с комментариями, а то, что внезапно выяснилось в этой ветке то, что у ВТБ тоже сорсы доступны -- так это просто совпадение :)
Я был не уверен что это ВТБ, пока не нашёл аналогичные вашему скриншоту сорсики, они дают прямое направление)
Ну тут в целом можно сразу ужать список. Во первых -- системообразующие банки, их всего 13 штук на текущий момент. Во вторых веб-версия брокерского приложения -- у сбера и альфы я не помню чтобы такое было. Ну а в третьих, единая версия для мобилок и веба -- тут уж совсем список ужимается. Но, как говорится, кто знает -- тот понял, а кто не знает -- тому найти не составит труда)
Так, пожаловаться на то, что айтишники одного из системообразующих банков плевать хотели на такие мелочи, как доступные исходники своего приложения.
не факт, что до тех кто этим занимается информация дошла. То, что отвечает в письмах не всегда соответствует реальности. бюрократия в таких конторах - это что-то...
Я не исключаю и такого варианта. Но до кого-то ведь дошла информация. Ну, не могла же служба поддержки отправить её в /dev/null... Ну, точнее, могла переслать какому-нибудь абстрактному "руководителю отдела", а тот уже забил болт на всё это.
Не пробовали писать на security@vtb.ru? Причем сразу с описанием находки, а не в формате "дайте денег и тогда расскажу какая у вас ДЫРА".
Я пытался найти подобный ящик, но нигде подобной информации не было. А тот самый емейл -- это был 911@vtb.ru.
Туда я собственно и написал сразу с подробным описанием, и именно с ними был весь диалог, про который и сказано в статье.
Это стандартный ящик из RFC, возможно его читает первая линия SOC, а не всего банка. В ВТБ конечно жуткая бюрократия, но мне как клиенту удавалось добавиться эскалации.
Первый раз слышу о том, что имена ящиков описаны в RFC, спасибо, буду знать на будущее!
Я действительно пытался найти "безопасный" контакт, и обычно, такое расположено где-то на странице с контактами. Но конкретно у ВТБ -- нет такого контакта там.
В форме для связи с банком на сайте тоже не очень то имеется подходящий раздел.
Всё же, моя задача как добросовестного и этичного человека, сообщить о проблеме нужным людям, а не штудировать RFC на предмет того, какие же имена ящиков там описаны в стандарте. :)
А вы замечали, сколько исходников есть на github? И на 50-90 процентов приложения написаны используя эти библиотеки. В том числе stdlib. То есть если вы не видите исходный код самого приложения, то вполне вероятно, что у вас есть исходники большинства используемых библиотек.
Выходит, что нужно начинать читать весь гитхаб на предмет TODO и README
Половина статьи это общение с поддержкой, а вот полноценного объяснения почему доступность фронтенд кода является утечкой нет.
Например у Телеграм веб весь фронтенд код доступен на GitHub. У них даже код мобильных приложений доступен. По вашей логике нужно создавать статью с кричащим заголовком об утечке? Ведь кто угодно может пересобрать и разместить.
Даже миницифированный фронтенд без сорс-мапов можно отформатировать, опционально скормить LLM и понять что происходит в коде. Поэтому есть специальные утилиты для обфускации фронтенд кода: https://obfuscator.io/
Не поверите, LLM и тут справляется превосходно: https://claude.ai/share/64f2498b-9a3f-48ce-a672-6f9f7b5aab6d
В самом начале имеется дисклеймер, в котором сказано что я считаю это утечкой, ваше мнение может отличаться от моего.
Например у Телеграм веб весь фронтенд код доступен на GitHub
Разница между данным случаем и любого другого проекта на гитхабе (пусть даже телеграм) в том, что второе -- изначально было опенсорсом. Так и задумывалось авторами.
Даже миницифированный фронтенд без сорс-мапов можно отформатировать
Одно дело разобрать какой-то небольшой кусочек кода, метода, или даже файлика. Другое же дело получить исходники проекта весом в несколько десятков мегабайт (в данном случае ~70MB) вместе с комментариями, ссылками на различные внутренние ресурсы вроде таск трекеров, фигмы, ещё чего-либо.
Как уже выше говорилось, утечка сорсов сама по себе не компрометирует всю систему. Да, узнавший об этом школьник завтра не выпустит свою копию приложения идентичную натуральному. И даже с некоторой вероятностью можно сказать что и из апи там ничего секретного/важного не вытащить (но это уже отдельная история). Но это не значит что нужно так халатно относиться к защите информации.
В противном случае можно и дальше допускать утечки различных баз данных мотивируя тем, что всё и так уже утекло до нас, у нас тут (почти) ничего нового нет (это отсылка к комментарию про то, что ПО пишется с использованием библиотек которые и так доступны на гитхабе).
Разница между данным случаем и любого другого проекта на гитхабе (пусть даже телеграм) в том, что второе -- изначально было опенсорсом. Так и задумывалось авторами.
В статье написано что злоумышленник, имея исходники, может создать копию приложения и разместить в Play Market / AppStore. Аргумент несостоятелен - есть примеры фронтендов / клиентов которые публикуют исходный код клиентов в Open Source. Телеграм упоминался не в контексте готовности кода к публикации в Open Source, а в контексте сборки фишингового приложения из исходников.
Одно дело разобрать какой-то небольшой кусочек кода, метода, или даже файлика.
Злоумышленнику ничего не мешает отформатировать весь минифицированный код или использовать ИИ с гигантским контекстом вроде Gemini. Основной посыл статьи в том, что нужен security through obscurity. А в комментариях ответили про принцип Керкгоффса и что для хакера минификация это незначительная преграда. Более того, даже обфусцированный JS-код можно читать и понимать. На этом я своё обсуждение статьи закончу :)
Знакомый работал в одной ИТ компании менеджером проекта, не скажу что такой гений, но работу выполнял хорошо. Ему предложили работу в одном банке, так- же не скажу в каком, те кто узнают себя, поймут.
Так его просто убило что там 2е жиры было, одна официальная, в которой нужно было делать красивые отчёты, ради премий и одна полу официальная, в которой велась работа, и в которой обычно заваливали задачи, но премии же идут в первой жире, следовательно зачем программисту стараться если премия и так в кармане?
Он вернулся через 3 месяца обратно..
А банк межу прочим тоже не из маленьких....
У любого банка есть департамент ИБ и департамент Рисков.
На много лучше пинается через них, потому что они на много лучше возбуждаются.
Плюс есть регулятор: ЦБ и можно подсветить им. Они в том числе по теме ИБ банки дрючат.
Но с другой стороны, автору это всё знать вовсе не обязательно) Он сообщил и даже подождал, и даже светить банк не стал. Так что и без того большой молодец.
А в тему, намеренно или нет: им просто пофиг, пока не прилетит по шапке от ИБ или ЦБ)
Утечка исходников в банке: безразличие или так задумано?