Тинькофф

Введение

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

В этой статье поговорим о некоторых лайфхаках и исправленных уязвимостях, а также попытаемся понять, как устроена маржинальная торговля у Тинькофф брокера.

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

Основные определения

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

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

Маржинальная торговля

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

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

Ставка риска, например, в 20% показывает процент собственных средств в размере позиции.
То есть, если есть сумма 10000, то максимальная сумма с учётом заёмных средств, на которую можно купить текущую бумагу будет 10000 / 20% = 50000.
Также можно сказать, что кредитное плечо по текущей бумаге 1 : 5.

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

Не баг, а фича: увеличиваем размер шорта в два раза

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

На моем депозите около 3200.
Рассмотрим лайфхак на примере акций компании ПИК.

Алгоритм

1. Покупаем максимальное количество акций в лонг

   До покупки

   
   
   Как можно заметить, на собственные средства я могу купить только 3 бумаги. Ставки риска по бумаге 22.56% в лонг и 25.44% в шорт, что соответствует тому, что с учётом заёмных средств можно купить 14 и продать 12 акций.
   

   После покупки

   
   
   
   
   
   
   Пока всё правильно: теперь можно продать 14 своих плюс те же 12 заемных акции. В сумме 26 штук.

2. Выставляем лимитную заявку на продажу на то количество бумаг, которое доступно продать без учёта плеча. В моём случае это 14 акций. Заявку нужно выставить по цене немного выше текущей. В моём случае цена акции 914, я выставил заявку по 915.

   Система неправильно рассчитала размер плеча для продажи

   Как можно заметить, теперь система предлагает выставить заявку ещё на 26 акций.

3. Выставляем на продажу то количество акций, которое доступно с плечом

   

   После того, как заявки будут исполнены, наши 14 акций продадутся и 26 бумаг пойдут в шорт.
   На первом скриншоте видно, что изначально система разрешала нам продать в шорт только 12 акций, но после нехитрых манипуляций мы увеличили размер шорта более чем в два раза, и теперь ставка риска по этой бумаге составляет чуть больше 10%
   
   Если же теперь отменить заявку на продажу 14 акций, то система не разрешит выставить такую заявку снова, нужно проделывать манипуляции заново.

   

Исправленная уязвимость: как увеличить плечо в десятки раз и зачислить заёмные средства на брокерский счёт

Данный кейс я поймал случайно и потом ещё день пытался воспроизвести. Стало интересно, что будет, если выставить две встречные заявки на покупку и продажу по единой цене. Если следовать логике, я должен купить акцию сам у себя, что странно.

Как работает сейчас?

Выставляем заявку на покупку одной акции по 916,4 и сразу же пытаемся продать себе по той же цене с плечом 13 акций.

Результат вполне ожидаемый: заявка на продажу 13 акций сервер отклонил:

Как работало раньше?

Рассмотрим тот же кейс: выставляем заявку на покупку одной акции, а также заявку на продажу 13 акций.

В таком случае на моём счету формально было бы минус 13 акций, при этом в портфеле эти акции не отображались бы, а баланс оставался бы неизменным.
Ночью при пересчёте сделок система бы поняла, что на самом деле на биржу заявка не была выведена и отменила бы эти -13 акций.

Но до конца торгового дня система считала, что я нахожусь в шорте на 13 бумаг, поэтому она давала мне более большое плечо по этой акции на покупку в лонг, чтобы я мог покрыть эти 13 акций и купить ещё 14 акций на свои деньги (см. первый скрин).

Итого я в сумме мог бы купить не 14, а 27 акций.
Ночью система снимает фейковые -13 акций, но в портфеле остаются все те же настоящие 27 бумаг.

Чтобы было понятно наглядно, покажу некоторые скриншоты, которые остались у меня с тестирований, на момент которого в моем портфеле было 4790$.

Можем видеть, что таким образом получилось купить 2211 акций Vipshop на сумму 62151$. То есть плечо здесь уже более, чем 1 : 12

Размер плеча, в теории, можно было увеличить насколько угодно: если мы выставим заявку на покупку одной акции и по этой же цене продадим ещё 13 акций из примера выше, то система уже будет думать, что у нас -26 акций, соответственно, она даст плечо на покупку этих 26 бумаг плюс 14 акций на собственные средства. Итого уже 40 акций.

С большим плечом дела пошли в гору, мой баланс на спекуляциях удалось увеличить до 6384$.

На скриншоте видно, как с помощью тех же манипуляций получилось увеличить плечо по Амазону почти до 200 000$. Таким образом оно уже стало более чем 1 : 30. Напомню, максимальное плечо у Тинькофф колеблется от 1 : 4 до 1 : 5.

Но вспоминаем, что ночью Тинькофф после пересчёта уберёт такое плечо и вполне вероятно, что на утро нас будет ждать маржин колл.

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

Что интересно: Тинькофф прислал маржинколл, хотя позиция прибыльная.

Зачисляем заёмные средства на брокерский счёт

Для того, чтобы заёмные средства зачислились на брокерский счёт, достаточно было самому вызвать маржин колл: очевидно, что никакой маржи не хватит, если, имея 6500$ купить бумаг на 300 000$.

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

Поэтому, сделав -30 фейковых акций Амазона способом выше, я купил 40 акций на сумму более 120 000$. Сразу после покупки сработал маржин колл, и система моментально продала купленные 40 акций. Вместе с этим система сразу же отменила заявку на продажу 30 акций (помним, что до ночи система не знает, что заявка фейковая) и зачислила их мне на счёт. Вместе с 30 акциями на счёт зачислилось и 6 947 118 и стоимость ликвидного портфеля увеличилась до 7 337 776

Таким образом, получилось увеличить депозит в 10 раз. Конечно, если вывести эту сумму, то на утро, когда отменятся все сделки, которые не были выведены на биржу, образуется отрицательный баланс на брокерском счёте. Однако, для злоумышленников это не было бы проблемой.

Все сделки, кроме фейковых, были выведены на биржу, что подтверждается в брокерском отчёте.

Заключение

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

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

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

Как это работает сейчас

В Тинькофф около 2000 страниц с разным дизайном и за все эти страницы отвечает отдел привлечения. Он состоит из подразделений, которые отвечают за карточные продукты, депозиты, инвестиции, страхование, мобайл, путешествия и так далее.

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

Страницы собираются из блоков в нашем Конструкторе.

Вот пример такого блока с карточками:

В него уже вшита логика с отступами, возможность выключить заголовок или изменить стиль кнопки. Также в блок уже вшита логика растягивания. На примере блок для экрана 1024, а при разрешении 1360 блок растянется. Так у нас работают все блоки.

Конструктор, в котором собираются страницы, это часть нашей CMS. Главное преимущество админки возможность быстро и безрелизно вносить правки на страницу, настраивать аналитику и персонализацию.

Мы тестируем много страниц и иногда для теста создаём новые блоки. Раньше создание нового блока занимало у команды разработки до 2 недель. При этом если если тест не проходит, то от блока отказываемся.

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

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

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

Как было раньше

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

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

Тогда придумали систему, назовем ее версия 0. К сожалению, ее скриншоты не сохранились. Вся страница выглядела как один большой блок с формой. Даже такой подход всех устроил, его стали активно использовать и сделали админку с Конструктором версии 1.0.

У старой админки еще не было интерфейса, в котором можно было собирать лайв-превью страниц, не было превью блоков, но она уже обладала рядом функций, которые всех устраивали. Функционала становилось все больше, добавилась, например, возможность просматривать историю публикаций и изменений, появилась сложная настройка блоков. Админка превратилась в версию 2.0.

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

Сформулировали цели для новой админки:

• Уменьшить порог вхождения новых пользователей. Нам было важно, чтобы не только контент-менеджеры могли собирать страницы, но и дизайнеры, заказчики и менеджеры.

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

• Сократить время выпуска новых страниц.

Собрали команду из аналитика, дизайнера, контент-менеджера и разработчика. У нас не было привычного флоу, когда дизайнеры и аналитики придумывают интерфейс и отдают разработчикам. Вместо этого мы с самого начала собирались всей командой, проводили дважды в неделю встречи, на которых составляли разные фреймворки, писали сценарии по User Story Mapping. То есть все участники процесса имели слово и вместе собирали админку.

Результатом стала админка версии 3.0.

Новая админка сократила сроки выпуска: если раньше любой релиз можно было вносить раз в две недели, потому что у каждой команды был свой график релизов, то теперь, благодаря админке, это время сократилось до пяти минут. Пользователи заходят на нужную страницу, вносят правки (например, меняли процентную ставку) и нажимают кнопку Опубликовать и страница тут же была на продакшене. Таким образом мы закрыли одну проблему. Однако вместе с этим появилась другая проблема.

Проблема с блоками

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

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

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

Какие у этого минусы::

• Затраты на разработку. Разные команды делают одно и то же.

• Много одинаковых блоков.

• Один и тот же блок выглядит по-разному на разных страницах, из-за этого у нас нет консистентности.

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

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

Проблема с процессом сборки страниц

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

Давайте посмотрим на средний состав участников процесса создания страниц:

• Заказчик человек, которому нужна страница, чаще всего это product owner.

• Копирайтер пишет текстовый прототип страницы.

• Дизайнер собирает макет.

• Разработчики подключаются, когда нужна разработка нового блока.

• Контент-менеджеры все еще специалисты нашей админки, которые настраивают сложные блоки (футер, шапку, формы с различными шагами).

• Аналитики вносят свои настройки в страницу.

Например, заказчик мог пойти в админку, собрать и опубликовать страницу. Либо он мог отдать задачу на создание текстового прототипа копирайтеру. Копирайтер все это передает контент-менеджеру, а контент-менеджер в админке собирает страницу. Либо заказчик ставит задачу дизайнеру, дизайнер в Figma собирает макет, контент-менеджер по макету из Figma собирает в админке страницу. Таких процессов у нас было очень много, но усредненно процесс выглядел так:

Заказчик ставит задачу копирайтеру, копирайтер отдает текстовый прототип дизайнеру, дизайнер собирает в Figma макет, контент-менеджер по figma-макету собирает в админке страницу, все ребята его согласовывают. Если нужен блок, ставят задачу разработчикам и затем передают аналитику для окончательной настройки, после чего страница запускается.

Минусы такого подхода:

• Планирование времени участниками. Случались ситуации, когда новый участник процесса узнавал о задаче за неделю до выпуска.

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

• Новый блок для страницы ждем долго. Как я упомянул выше, мы очень поздно предупреждали разработчиков о том, что нам нужен новый блок. Разработчики не успевали его подготовить либо, очень злясь на нас, были вынуждены готовить его быстро, но говорили, что это в последний раз.

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

• Нет понимания зон ответственности и результатов работы.

• Увеличивается срок выпуска страниц.

Решение

Столкнувшись с вышеописанными проблемами, мы решили:

• Описать правильный и понятный процесс выпуска страниц, потому что у ребят уже были свои чек-листы, гайды и так далее.

• Описать зоны ответственности. Собрать все вместе и превратить в нормальный процесс.

• Дизайнеры собирают страницы в Конструкторе. Перевести всех дизайнеров со сборки страниц в Figma в наш Конструктор, чтобы они понимали, как работают блоки, и из них составляли страницы.

• Все команды подключаются на старте.

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

Копирайтер может использовать артефакты: он может пойти в сторибук, посмотреть, как работают блоки, если ему так проще составлять прототип; может пойти в Figma либо в Конструктор. Результатом его работы будет текстовый прототип (на самом деле не только текстовый прототип может быть собран в PDF или в Figma, и это будет результатом работы).

Затем этот прототип передается дизайнеру. Дизайнер может по-прежнему использовать сторибук, Figma, гайд по сборке страниц, который у нас есть, но все равно результатом его работы будет ссылка на десктопную и мобильную версии страницы.

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

Как создают новые блоки?

Дизайнер рисует мобильную версию страницы и в процессе понимает, что ему нужен блок (карточка с иконкой), которого у нас еще нет. Согласно процессу, он идет в команду дизайна и говорит: Нам нужен новый блок. Ребята понимают, что это многофункциональный блок, который может понадобиться всем, его можно встраивать и на другие страницы. Тогда задача передается в команду админки, у которой есть два варианта:

1. Команда админки видит, что есть похожий блок, но без иконки это просто текстовая карточка со своим набором полей. Они решают дополнить эту карточку иконкой и добавить новые настройки. После миграции все могут использовать этот блок и нет необходимости создавать и поддерживать новый.

2. Нужного блока нет, и похожего тоже нет. Тогда дизайнер идет в Figma и там собирает макет для разработчиков, отрисовывает все состояния и, когда макет собран, он передается в команду админки, которая создает схемы и UI блока. То есть команда админки решает, какие опции должны быть в настройках карточки. Команда блоков верстает и тестирует этот блок.

При разработке блоков используют инструмент Multistory, который разработала команда блоков.

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

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

Для отслеживания поведения блоков команда блоков разработала инструмент RealStory. Например, есть карточка с картинкой (заголовком, кнопкой), и мы можем в реальном времени посмотреть, на каких страницах сейчас эта карточка присутствует и как она выглядит. Это позволяет дизайнерам и разработчикам отслеживать поведение блока: как он работает и нет ли в нем ошибок.

Вернемся к процессу

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

Если, например, контент-менеджер не настроил аналитику сам, то задача аналитика настроить эти блоки: какие блоки надо трекать, настройки шеринга либо настройки оптимизации и персонализации. После задача попадает обратно в эпик.

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

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

Что будет дальше?

Во-первых, из-за того, что у нас много команд и они большие, нельзя просто взять и сказать: Теперь вы будете делать так, как мы решили. Конечно, так нас просто пошлют. Для начала мы решили протестировать на небольших процессах, на сборке шаблонных страниц, и процесс начал себя показывать достаточно хорошо. Конечно, есть нерешенные проблемы (например, на какой стадии подключать команды), но процесс двигается хорошо. Более того, команда блоков уже работает по новому процессу, и это экономит много ресурсов и времени.

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