Comments 87
https://monosnap.com/file/lsVKG15Q6LMQIb0xZYbf7etrDFcW1J
Ну там типа: мы взломали вашу сеть и засунули к вас в c:\windows\system32 нашу программу, но это не троян, нет-нет — это наш защитник, он вам помогает с вирусами бороться.
То есть теоретически, конечно, можно себе представить мир, в котором подобные «Робин Губы» существуют, но практически… Нет — ну кем нужно быть, чтобы в такое поверить? Шестилетним мальчиком?
А написание же хака — от стоимости алгоритма не зависит. Пока кто-то не проведёт исследование и не обнаружит его — можно поступать достаточно грубо.
Как можно это сделать проще?
Это все равно оставляет пространство для маневров. Например, злокачественный скрипт может скидывать "плохих" клиентов другим.
Этого не достаточно. Нужно сегментировать аудиторию для АБ тестов на сервере, включать функциональность тоже на сервере, а куку для сегментации делать недоступной из js.
Ещё неплохо все внешние скрипты 1) запускать во фрейме 2) грузить со своего домена, чтобы исключить подмену скрипта не добросовестным партнером
Как вариант — разносить по разным доменам (суб-доменам)… + SOP + не юзать кросс-доменные куки ...
Отличное расследование и шикарная подача материала.
Вспомнилась война читов в тестах для видеокарт.
Утопить бы репутацию этих нехороших людей поглубже, чтобы урок был для других.
Анализом статистики поймали необъяснимые девиации.
Код доступен — довольно простой реверсинжениринг. Я про картинку правда не понял.
Теперь просто в порошок растёрли свою репутацию.
Плюс, судя по комментариям, там было противодействие отладке (скрипт отключался при открытой консоли браузера).
Подняли кучу других претензий (о которых в статье ни слова), а основную претензию вместо того чтобы нормально разобрать и, возможно, действительно оправдаться — списали на безграмотность специалистов Retail Rocket (и, видимо, всех остальных).
Ну и считает окружающих идиотами заодно.
Похоже, что сейчас у них любой запрос на поддомен "api." возвращает 403.
Похоже на попытку запутать людей, не обладающих навыками веб-разработки, набросав много непонятных менеджерам и маркетологам слов (“у них в коде тоже много функций eval” – серьезно? – звучит так же, как если бы они на фразу “мы нашли спрятанный у вас дома топор с кровью жертвы” ответили “ну и что, у них тоже в сарае есть топор”).
Они пытаются придраться к деталям интеграции на магазине, при этом весь код интеграции все еще на сайте в том виде, в котором он был на момент теста и любой может проверить как он работает. Все, к чему они апеллируют, что есть конфликт имен модулей между магазином и кодом Retail Rocket и якобы это позволяет нам менять куку. Во-первых, нет: JavaScript исполняется последовательно, а код Retail Rocket подключен значительно ниже кода деления трафика магазина (сегментатор магазина – ~65 строка, код Retail Rocket – ~2500 строка) и момент его срабатывания уже поздно что-то там подменять, так как сегмент пользователя уже определен в куке (наш код ни к каким кукам теста не обращается). Это легко проверить в дебаггере (наш код там работает и не зашифрован). Во-вторых, мы все знаем — чтобы сменить куку никакие “конфликты” не требуются, берешь и меняешь, вот прямо как они сделали:
document.cookie="rr-VisitorSegment_Rec=3:2; domain=.dochkisinochki.ru; path=/; expires=Mon, 25 Sep 2017 10:15:20
+0000";document.cookie="DS_SM_rrSegmentRecommendedABC=B; domain=.dochkisinochki.ru; path=/
Коллеги довольно легко разбрасываются домыслами налево и направо. Мы же оперируем фактами: их зашифрованный в картинке код поймали и это чудо, что нам это удалось сделать, их библиотека намеренно скрывает функциональность (замена букв при вызове eval и передача кода в картинке — бррр, код не работает при открытой консоли и т.д.), статистика Google Analytics точно показывает в чей сегмент мигрировали заказы и так далее.
И стоило оно того?
Какая ещё репутация прахом. Менеджмент большинства клиентов не поймет всех этих объяснений. Rees легко смогут заболтать этот случай.
Вот только ничего особенного у них в этот движок не вложено.
И защитились они тоже неплохо.
Имеет ли смысл? Помните «дизелгейт» VW в США?
и могли таскать друг у друга сессии
но это же дыра, блин,
если сейчас этой дырой воспользовался REES, то в другие разы ей мог пользоваться RR
как я понял, сегментатор авторства RR — тогда вообще все не так однозначно (ц)
Ежу понятно, что только один код для одного сегмента должен отрабатывать — тогда таскать сессии будет невозможно
Мы увидим юридические последствия этой аферы? Или все спустится на тормозах?
О чем вы? При чем тут взлом сайта?
Решение — просто делать клевые проекты.
АБ-тесты нужны там, где людям пытаются продать хлам. Я огорчен теми, кто этим до сих пор занимается.Ок, принято. Выкидываем всё, что разработано Гуглом и Майкрософтом, Каноникалом и Эпплом, перестаём пользоваться Яндексом и Файрфоксом… слушайте — а как вы тут комментарий написали, если ни Хром, ни Оперу не пользуете и ни с МакОС, ни с Windows, ни с Linux не общаетесь?
Решение — просто делать клевые проекты.Осталось понять как вы узнаете, что ваш проект — клёвый, если ни с чем его не будете сравнивать…
как бороться?
все скрипты должны быть под контролем магазина?
валидация скриптов всеми участниками?
контроль качества сегментации арбитром?
Функциональность скриптов должна быть прозрачной, любое сокрытие того, что делает код, должно быть исключено.
контроль качества сегментации арбитром?
Пока нам кажется достаточным, чтобы трафик делился ровно, а пользователи не меняли сегмент. Это можно отследить через google analytics.
валидация скриптов всеми участниками?
Боюсь, что такое недоверие сильно замедлит разработку всех проектов. Думаю, будет достаточно, чтобы сервис всегда рисковал своей головой, если он будет замечен хотя бы в сокрытии функционала кода, не говоря уже о действиях которые несут вред магазину: отправка пользователей в другие системы без ведома магазина или атаки на тесты магазина. Да и вообще всего, что намерено наносит вред.
ну а если конструктивно: проблема в том, что заинтересованным лицам доступен контроль над данными, влияющими на ход тестирования, а именно идентификатор сегмента, это и есть узкое место и в корне не правильно.
моя мысль следующая: если мы допускаем, что сегментатор — это неподвластная истина, то назначать сегменты может только он, решается это следующим образом: у пользователя при первом заходе (если в куках еще нет) генерируется guid, обычный такой случайный гуид, далее, например, суммируется со счетчиком из GA и отправляется на сервер. если по этой паре не назначен сегмент — сервер его назначает и хранит у себя, никому не говоря, а по этому сегменту уже сам направляет на обработку в необходимый экзепляр…
в случае умышленной подмены guid-а мы просто получаем нового пользователя со снова рандомным сегментом, подтасовать в этом случае (опять-таки я учитываю «честный» сегментатор) невозможно.
Атака на АБ-тест: рецепт 'R'+t(101)+'es46'