Мошенники вывели 350 млн рублей с Wildberries через «подставных продавцов» — источник Статьи редакции
Представители ритейлера подали заявление в полицию.
Мошенники обманули Wildberries через «подставных продавцов», пишет ТАСС со ссылкой на источник в УМВД. В компании подтвердили vc.ru подачу заявления о «хищении денежных средств путём обмана».
«Подставные продавцы» размещали на маркетплейсе несуществующий товар, «подставные покупатели» оплачивали его, но в процессе оплаты намеренно совершали ошибку. Оплата отклонялась, но в Wildberries отображалась продажа, и деньги уходили «продавцу».
В Wildberries рассказали vc.ru, что мошенники впервые провели операцию в начале апреля на сумму в несколько тысяч рублей. А массовая атака прошла в последнюю неделю мая. Компания выявила обман, обратилась в полицию и в профильные органы, чтобы рынок узнал о новой мошеннической схеме.
Мы уверены в успешном исходе дела: злоумышленники, оставившие свои «цифровые следы», уже установлены, а правоохранительные органы ведут активные следственные действия. Покупатели и продавцы товаров не пострадали — для нас их «цифровая безопасность» на онлайн-площадке является ключевым приоритетом.
Официально в компании не комментируют сумму ущерба. Знакомый с расследованием источник рассказал vc.ru, что потери составили около 350 млн рублей, задержаны первые подозреваемые. Часть средств, полученных мошенниками, уже заблокирована.
«Новая мошенническая схема» состоит в обнаружении в компании криворуких разрабов?
А в чём тут криворукость разрабов? Наверняка разрабы сделал всё по ТЗ, тестировщики проверили всё на соответствие ТЗ. Наверняка ТЗ подписало несколько руководителей разного уровня. И то что составитель ТЗ не учёл подобные ситуации — это исключительно его ответственность и тех, кто его подписал.
Я разбирал наверно с полсотни шлюзов в разные продукты и платёжные системы и самые популярные ошибки такие:
1) никак не выфильтровывается тестовая платёжная система (то есть платёж и весь колбек в целом нормальный, но что ПС не тестовая не проверяется, иногда в доках от эквайера эта особенность даже не описана, а иногда если где-то не убрать галочку, она автоматически становится тестовой для карты 4111 1111 1111 1111 / 123)
2) не проверяется сумма платежа (где-то подменяется сумма на 1 рубль, а платёж проходит по номеру "транзакции" и корректной цифровой подписи.
3) аналогично с полем "валюта"
4) очевидно слабый ключ хеширования, который можно сбрутить, отсутствие валидации запрсом эквайеру.
п 1 и 2 встречается даже в официальных модулях к CMS от шлюза (которые конечно же предоставляются в виде "as is" который превращается в "is ass" ).
и да, есть ещё распространённый вариант что всё тз на интеграцию это задача вида: "вот ссылка на новый шлюз, вот доки у него на сайте, вот доступ к ЛК и чтобы завтра было готово".
Согласен. Тоже есть большой опыт в этом, и карта 4111 куда ж без нее )))
https://kernel.group/index_ru.html
Такое возможно, только когда нет:
1. Нормального процесса производства кода. Создается код, коммитится в репо, далее анализ, доработки, применение в ТЕСТОВУЮ зону, тесты, применение в РЕАЛЬНУЮ зону. Если нет тестовой зоны, максимально совпадающей по коду с реальной зоной, это ахтунг! Нет программы испытаний - плохо.
2. Пока "завод по разработке ПО" производит код, решает одну задачу, остальные задачи терпеливо ждут на входе. Делать десять дел одновременно - плохо. Постоянно выдергать кодеров, которые погружены в одну задачу, чтобы срочно-обморочно делали другую - это очень плохо. Тогда процесс разработки состоит из болезненных и никому не нужных всплытий и погружений.
3. Должен быть архитектор, как при строительстве дома, с ответственностью за все "изваянное". Кто это у Wildberries? Есть ли он вообще?
4. Должна быть понятная схема процессинга, в UML, многократно обсужденная, согласованная и протестированная. Типа получил деньги отдал товар, вернул товар, вернул деньги. С true многопоточностью и проверками и шаг вправо, шаг в лево - расстрел. Это все просто, за это нобелевку не дают. Детских ошибок в реализации именно этой части видел много. Они всегда стоят дорого. Пример из далекого прошлого, один товарищ забыл проинициализировать переменную в цикле, продал PIN код для пополнения GSM за 100 руб. (правильно), и все остальные PIN коды, включая номиналы 1000, 2000 руб. тоже за 100 руб. Кому попало процессинг в ядре системе нельзя доверять писать.
"Эффективным менеджерам" на всех этих пунктах 1-4 хочется сэкономить. Итог немного предсказуем....
В вашем комментарии много воды, а сути ноль.
1. Ну предположим есть и тестовый контур и нагрузочный и не один.
2. предположим никто никого не выдёргивал. Даже тестировщиков.
3. Ну предположим есть архитектор. Меняется одна платёжная система на другую такую же, зачем он в этом процессе? Плохо что нет внешней валидации, но это не решающий фактор в моих примерах.
4. Предположим все диаграммы тоже есть.
А теперь моделируем самую популярную ситуацию из моего комментария: и у меня вопрос — откуда в правильном процессе возьмётся в списке тест-кейсов тест-кейс "проверить что платёжная система боевого платежа не тестовая". В боевой системе могут быть вполне тестовые платежи(с этим обычно проблем нет), а вот о том что есть "тестовая ПС" можно узнать обычно только если уже сталкивался с такой проблемой или где-то у других платёжек видел такую реализацию.
Это настолько важная деталь, которую "и узнать её никак" что я не представляю как даже в хороших процессах ловить такое кроме как на опыте человека, который с этим уже сталкивался.
А нанимать аналитика/тестировщика с опытом именно тестирования платёжных интеграций, это, извините, оверкилл.
Я даже конкретный пример приведу(не прямо 1-в-1, но похожий) , откуда кто угодно может узнать что оказывается в https://docs.assist.ru/pages/viewpage.action?pageId=5767488 есть ещё описанный примерно нигде параметр testMode (они это вроде как-то фиксили когда волна пошла, но эта бага работала в 2016 году у 9 из 10 пользователей этой платёжки). И ассист такой далеко не один.
И там таких деталей дофига. И это в СНГ все эти шлюзы более-менее новые, забугорные выдают местами намного более интересные "особенности реализации".
Я очень конкретно описал что нужно.
вот наша тестовая зона:
http://test.bil.cool/
В ней кстати карта 4111 1111.... можете купить билеты
вот реальная
http://real.bil.cool/
https://eventscanner.ru/ Тут 13000 событий
Тут охват рынка, наши продажи https://bil24.pro/market_reach.html
Ну и я 30 лет этим занимаюсь, проекты по ссылке https://kernel.group/. вам показалось что я написал много воды - ну что ж....
выглядит круто очень! вам нужны тестировщики?)
спасибо. пока нет...
Где билеты забрать?