Мошенники вывели 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/. вам показалось что я написал много воды - ну что ж....
выглядит круто очень! вам нужны тестировщики?)
спасибо. пока нет...
Где билеты забрать?
круто, такой ликбез можно получить в комментариях) можно обучиться новой профессии я бы сказал)
Все так, но самое главное пункт 3, ещё точнее - ответственность, которую давно принято перекладывать, а по сути размывать и толком не спрашивать, ни на каком уровне )
Я обычный человек с небольшими навыками в js и php, который пишет код исключительно для своих нужд (продажа электронных книг/иных цифровых услуг в интернете) и даже я учёл все то, о чем вы написали, в своем простом коде для оплаты, хоть и понимаю, что те люди, с которыми мне доводится работать, никогда бы не стали делать махинации, потому что целевая аудитория вообще в этом не бум-бум. Я прописывал различные вариации проверки фактической оплаты и проверки хэша на подмену исключительно для себя, и если что-то где-то не сходится (название, цена, количество, айди продукта, хэш, ответ от платёжной системы) — сайт просто выдает определенную ошибку, потому что иначе не могу. Я в замешательстве от того, что такая крупная компания, как ВБ, вероятно об этом не подумали.
ну разработчики бывают очень разными. Вы вот ответственный, а ваш сосед нет.
Всё как и везде.
Дело даже в том, что разработчиком меня назвать сложно. От этого и печально, что разрабы могут такое пропустить.
Если разрабам плохо платить и относиться как к быдлу, они совсем будут не виноваты вот в таких вещах. А wb сокращала разрабов отделами, в итоге что-то нехорошее и выплыло.
ключевое — прилагательное "ответственный", а не существительное "разработчик"
Часто такие любители как Вы оказываются намного профессиональней и грамотней «штатных экспертов».
вообще то ради 350 лямов могли и внедрить не код, а целого кодера и не одного
чушь не мелите . В ПО часто куча интеграций и без понимания где была дыра сложно говорить о чьей то вине, точнее сразу вешать собак на разрабов платежного шлюза
Вы сами чушь не мелите. Прежде чем что-то писать, прочитайте ещё раз мой комментарий. Я вообще-то никого ни в чем не обвинял, в отличие от Вас.
да подумали они, то что в новости написано не факт что оно в реальности так) может тупо их хакнули, а сообщили об ошибки в коде(
чую не все вы учли )))
Целевая аудитория и там вроде как ни бум-бум. Это те ушлые ламеры которые везде свой нос засунут.
Можете об этом подробную статью написать? Интересно будет почитать
а ты пинтестер или просто тестер?
Я среди прочего внимательно смотрю на то, что у моих заказчиков едет в прод(не то чтобы мне сильно нужно,. просто если что серьёзное — чинить мне).
Комментарий недоступен
тоже самое написал) только более точно по ролям ответвственности, разрабы вообще не причем
Люблю такие Комменты. Каждый день такое где-то слышу, когда что-то опять не работает - «разрабы не причём» 😀
Хотя как подсказывает опыт работы за всю историю своей жизни - косячат именно они. Как и в строительстве, будет у тебя офигенный крутой проект с мега прописанным планом, приходит пара пьяных строителей и все, жди косяков )
Самая недумающая, не способная оценить картину в целом группа в проекте и не понимающая цены своей ошибки - именно разрабы.
Скажите тогда в чём конкретно косяк разраба в данном случае и ткните пальцем на конкретного человека.
так вот и тратиться куча времени на это тыканье пальцами. Зачастую разраб не понимает процесса в целом, особенно на аутсорс проектах, он не "живет" бизнес процессами заказчика, ну ему в целом пох на них :) Как строителю не жить в том доме, который он строит :)
Почитайте пожалуйста примеры трудовых договоров и должностных обязанностей разрабов. Там чаще всего речь вокруг ТЗ и не более. И юридические отделы, отделы кадров, директоров и ИТ-руководителей такие договоры полностью устраивают. Пунктов типа «ответственность за непродуманные и/или противоречивые бизнес-процессы» — в договорах у разработчиков я ни разу не встречал.
Есть разработчики которые хорошо шарят в процессах компании и её предметной области, но им за это не доплачивают и в целом чаще всего даже не ценят. К сожалению, большинство ИТ-руководителей дрочат только на технические навыки своих подчинённых.
что на стройке должен быть прораб, который следит, чтобы пьяные не были допущены к рабочему месту или не накосячили или чтобы накосяченное было переделано как надо, что у разработчиков должен быть процесс и люди, которые не дают косякам выйти во внешний мир
меня это и смущает, что им нужно слишком много "нянек".
В случае сложного ПО альтернатива отсутствию "нянек" - ошибки в реализации.
Тащемто, просто вопрос выбора для бизнеса, что выгоднее - уменьшить фот или кол-во ошибок.
Комментарий недоступен
Вот тут бы пригодились набившие оскомину на собесах джунов "валидация и верификация" )
Оке-ей, криворукость всего IT-отдела.
Мне кажется, ты перепутал wildberries со сбером. В диких ягодах нету бюрократии в виде 100500 согласований и подписей. Там больше как в стартапе — сегодня прислали задание почтой или таску на скрам-борд закинули, через пару дней готово.
В тз все не упихаешь, все равно что о не учтешь. Для этого есть инициативы на местах, когда приходит специалист и говорит шефу - иван-иваныч, у нас тут косяк пздц, это надо фиксить, и да, премию за работы вне тз не забудьте. (Либо приходит тикет в техсап от доброхота, много где премируют за найденные дыры)
Если начальник нормалтный - то прикидывает возможный ущерб, и если он выше цены фикса - косяк закрывается.
Если начальник - типичный баран из вшэ - он говорит чтото в духе "делай за что платят и не отсвечивай". После этого работы строго по тз, инициатива на ноль, и результат как тут.
Но у второго, конечно, стопиццот всяких дипломов что он дохера талантливый управленец. И премии регулярно получает за рацпредложения в духе уволить 5 админов из 8, чо тамтделать то, трое не справятся чтоли?
А это разве проблема разрабов, что «В тз все не упихаешь»? Кому нужен качественный продукт — тот упихнёт. Если руководство надеется на инициативы — то это такое себе руководство. Какие премии?) Ни разу не видел чтобы на инициативы хотя бы время выделяли.
Смотря что за сфера. Если это it и разработка - то все слишком быстро меняется чтоб все предусмотреть. Если ты не телепат, канешн.