Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 137
>Кстати вы еще проверьте, может их «фикс» — лишь забанили вашу айпиху, или еще что-нибудь такое.
Я практически знаю что фикс кривой. Но это уже не важно. Я решил не общаться с этими редисками вообще.
Я практически знаю что фикс кривой. Но это уже не важно. Я решил не общаться с этими редисками вообще.
и передали технологию в руки других редисок
Ну и поделом. Если не хотят нормально исправить проблему, которую им на блюдечке принесли, то это уже их личные сложности. Нормальные люди бы спасибо сказали и халявную карточку на сколько-нибудь денег подарили.
Как показывает практика, приносишь на блюдечке уязвимость, а тебя потом еще и во всех смертных грехах обвиняют, чего уж говорить о «халявной карточке». На моем счету обменники денег, несколько онлайн игр, новомодное питерское такси (с этими вообще весело было)
>На моем счету обменники денег, несколько онлайн игр, новомодное питерское такси (с этими вообще весело было)
Не хотите поделиться историями с общественностью?:)
Не хотите поделиться историями с общественностью?:)
Да ничего сверхъестественного.
Лет… много назад нашёл дыру в обменнике, фактически косяк хостера — своровать ничего нельзя было из-за ключей WM. Связываюсь с владельцем, объясняю ситуацию. Владелец всё понимает и идёт к хостеру. У хостера сидит админ Вася (имя реальное) и не долго думая поднимает хай с гневными письмами к моему провайдеру и в органы. Несколько дней угроз, общения с владельцами провайдера и органами. Вопрос замяли. Владелец высказал устную благодарность и переехал к другому хостеру, ибо предыдущий положил болт и ничего не стал менять.
mmorpg либо долго молчат и потом втихаря фиксят, либо банят за «ты ковыряешься у нас, нам это не нравится». Никакой благодарности, даже в виртуальной валюте.
История недавняя — У нас есть десяток городских телефонных номеров. Ночью случайно оказалась открыта консоль астериска. Краем глаза замечаю кучу звонков с мобильников к нам на номер, и как выясняется не первый день. Причем номер мне неизвестен, в астер не заведён. Завожу на себя, беру трубку — «Алё, ну где моё такси?» — Думаю ошиблись. Беру второй вызов — аналогично народ интересуется когда приедет их машина. Начинаю выяснять у звонящего — звонит он на YYY-XXXX, в зелёное питерское такси. Звоню на красивый YYY-XXXX — звонок приходит ко мне о_О. Номер, который я завёл, вообще не числится у нашего оператора. Пришлось долго и методом тыка искать людей, связанных с зелёным такси по их группе. Нашлась девушка, если не ошибаюсь, из начальства рекламного отдела. Сначала долго пришлось объяснять и доказывать что я не баран, после, видимо до них дошло.
Утром, выяснили что номер был у нас, но мы от него отказались. Оператор продал номер как б/у другому оператору, но что-то напутали с маршрутами, и в первую очередь звонок приходил к нам, а так как от нас был ответ 404, спокойно шёл дальше, к новому абоненту.
Никакой скидки или поощрения. В конкурсах, в группе вк, я тоже не выигрываю, зато частенько вижу ту барышню в списке _рандомно выбранных_
Видимо, нужно было пытаться найти выходы на «решающих начальников», либо всё же просто пустить их звонки на конкурентов и пусть сами дальше разбираются что за хрень творится.
Лет… много назад нашёл дыру в обменнике, фактически косяк хостера — своровать ничего нельзя было из-за ключей WM. Связываюсь с владельцем, объясняю ситуацию. Владелец всё понимает и идёт к хостеру. У хостера сидит админ Вася (имя реальное) и не долго думая поднимает хай с гневными письмами к моему провайдеру и в органы. Несколько дней угроз, общения с владельцами провайдера и органами. Вопрос замяли. Владелец высказал устную благодарность и переехал к другому хостеру, ибо предыдущий положил болт и ничего не стал менять.
mmorpg либо долго молчат и потом втихаря фиксят, либо банят за «ты ковыряешься у нас, нам это не нравится». Никакой благодарности, даже в виртуальной валюте.
История недавняя — У нас есть десяток городских телефонных номеров. Ночью случайно оказалась открыта консоль астериска. Краем глаза замечаю кучу звонков с мобильников к нам на номер, и как выясняется не первый день. Причем номер мне неизвестен, в астер не заведён. Завожу на себя, беру трубку — «Алё, ну где моё такси?» — Думаю ошиблись. Беру второй вызов — аналогично народ интересуется когда приедет их машина. Начинаю выяснять у звонящего — звонит он на YYY-XXXX, в зелёное питерское такси. Звоню на красивый YYY-XXXX — звонок приходит ко мне о_О. Номер, который я завёл, вообще не числится у нашего оператора. Пришлось долго и методом тыка искать людей, связанных с зелёным такси по их группе. Нашлась девушка, если не ошибаюсь, из начальства рекламного отдела. Сначала долго пришлось объяснять и доказывать что я не баран, после, видимо до них дошло.
Утром, выяснили что номер был у нас, но мы от него отказались. Оператор продал номер как б/у другому оператору, но что-то напутали с маршрутами, и в первую очередь звонок приходил к нам, а так как от нас был ответ 404, спокойно шёл дальше, к новому абоненту.
Никакой скидки или поощрения. В конкурсах, в группе вк, я тоже не выигрываю, зато частенько вижу ту барышню в списке _рандомно выбранных_
Видимо, нужно было пытаться найти выходы на «решающих начальников», либо всё же просто пустить их звонки на конкурентов и пусть сами дальше разбираются что за хрень творится.
Онлайн игры — это, да. Как сейчас помню эту детскую радость…
Была такая игра Старый Бойцовский клуб, зашел я в нее, а там банк с обменником внутренней валюту, ввел отрицательное число на обмен и стал моментально миллиардером.
Но речь не об этом. Благодарность фактически не проявилась.
Была такая игра Старый Бойцовский клуб, зашел я в нее, а там банк с обменником внутренней валюту, ввел отрицательное число на обмен и стал моментально миллиардером.
Но речь не об этом. Благодарность фактически не проявилась.
Раааанд, лови хакера! (:
Я сдал баг, там уже был не Рааанд, а trinity: )
О. Я таких знаю. Я им баг сдал, позволяющий клонировать предметы, а они меня заблокировали и гневное письмо в ящик накатали, что если баг пойдёт в народ — со мной будет разбираться суд, или кто похуже. Учитывая, что мы находились в разных странах, посмеялся. (;
Забавно. Браузерные игры — дело прибыльное (было во всяком случае), поэтому такая реакция. «Это ж подрыв экономики».
Но упоминание суда рядом с этим проектом и еще сотней его клонов в принципе неуместно, и админы об этом хорошо знают :)
Так что, да, они не правы…
Но упоминание суда рядом с этим проектом и еще сотней его клонов в принципе неуместно, и админы об этом хорошо знают :)
Так что, да, они не правы…
Ну «подрыв экономики» — это громко. У повального большинства экономики или нет или она жутко непродумана.
Я бы не сказал, что совсем нет… Экономика в проектах без доната и абонентки фактически определяется так: «максимальное
удвовлетворение своих инстинктов получает тот, кто платит больше других в данный момент»… К слову сказать, это ломает обычно сам игровой процесс, и нормальные игроки быстро покидают такие ресурсы…
удвовлетворение своих инстинктов получает тот, кто платит больше других в данный момент»… К слову сказать, это ломает обычно сам игровой процесс, и нормальные игроки быстро покидают такие ресурсы…
Проблемы никто не любит, даже если их приносят на блюдечке, поэтому такое отношение. Менеджеру, которому в итоге пришлось это разруливать, это было лишним головняком, и поощрять такое безобразие он не хочет. Владельцам/Акционерам — да, это, наверно, важно, но они это не всегда осознают. А конкретному менеджеру — глубоко по барабану.
передали технологию в руки других редисокЭто рэйс-то технология? А про поведение упомянутых Chikey «редисок» даже говорить не хочется… (реально столько неуравновешенных придурков на местах, тоже накушался).
Тогда тоже передам технологию… Не совсем рэйс, но похоже…
Хотел тут написать коммент, получился пост "Как я однажды взломал онлайн-казино".
Надо обращаться выше с жалобой на конкретного сотрудника — что он неадекватно разрулил кейс и угрожает вам. Если у вас хватит упорства вывести это дело выше — рано или поздно перед вами извинятся и компенсируют беспокойство и моральный ущерб, им bad publicity не нужна и обойдётся дороже.
Спасибо
Не расстраивайтесь. Все-равно кофе они никогда не умели варить…
+1. Самый вкусный напиток в старбаксе это пряный чай латте. (в азии не покупайте чай латте — это гадость зеленого цвета, совсем другая вещь).
вы во всей Азии проверили? или только за уралом?
Азия — это Тайланд, Китай, Гонконг, Индия, Камбоджа, Вьетнам и т.п. страны, но не РФ. Не придирайтесь к словам. У них Чай Латте это просто другой напиток сам по себе, а не то, к чему привыкли в Европе.
Кстати, то ли во Вьетнаме, то ли в Тайланде есть что-то подобное на латте — зеленого цвета. Не в курсе что это и как звать?
Вы про Маття́?
Я об этом и написал. Это называется Чай Латте (Chai Latte) www.starbucks.com.cn/en/menu/drink-tea-01.html Иногда он называется Green Tea Latte, зависит от страны азиатской.
rghost.ru/private/8swkWW4dv/f394875cf067d9b03d1747468d8a35e5.view — специально на память фото делал.
UPD: Думал вы про старбакс спрашиваете
rghost.ru/private/8swkWW4dv/f394875cf067d9b03d1747468d8a35e5.view — специально на память фото делал.
UPD: Думал вы про старбакс спрашиваете
>>> Азия — это Тайланд, Китай, Гонконг, Индия, Камбоджа, Вьетнам и т.п. страны
а Япония к Азии относится?
а Япония к Азии относится?
Конечно. Восточная Азия ведь
Так вот сообщаю вам что кофе они делают отличный а чай лате здесь не готовят
У каждого человека вкус разный.
Если я вас правильно понял, то судя по их японскому сайту очень даже готовят www.starbucks.co.jp/en/beverage/tea.html — Full Leaf Chai Tea Latte(Hot)
Если я вас правильно понял, то судя по их японскому сайту очень даже готовят www.starbucks.co.jp/en/beverage/tea.html — Full Leaf Chai Tea Latte(Hot)
Я из Японии такой растворимый заказывал, Nescafe выпускает. Ничего так, на любителя )
А я вот пил в Индонезии эту зелёную, как вы сказали, «гадость», и с тех пор ужасно раздражает, что здесь, в России, не могу её найти. Так что о вкусах не спорят.
Крутяк.
Но не сказал бы, что
является малоизвестным :)
Но не сказал бы, что
малоизвестный класс уязвимостей «race condition».
является малоизвестным :)
Да уж. Интересно, какое, по их мнению, должно быть поведение IT специалистов при обнаружении уязвимости, чтоб они не писали «fraud» и «malicious actions»? Получается их служба безопасности пытается наказать честных людей, а нечестные спокойно эксплуатируют или продают уязвимости.
Мой опыт подсказывает, что это просто большая компания, где непонятно кто и что творит. И чем перетряхивать все процессы от начала до конца, проще шугануть гика.
И зачастую накрывшаяся премия безопасников сейчас намного для них важнее чем украденные пару миллионов долларов у компании через пару лет, когда они уже будут работать в другом месте.
Обычно немного не так. У ответственного стоят KPI за конкретные вещи. По ним рассчитывается его эффективность. Делать что-то за пределами того, что идёт в отчёт, как бы можно, но смысла нет. Взвешивая правильную работу по исправлению (написать айтишникам, объяснить, что это, доказать руководству, согласовать с безопасниками, предупредить маркетинг, что-то сделать с действующей акцией, согласовать бюджет на изменения, переназначить приоритеты, в т.ч. своих задач у IT) — это сложно. Шугануть гика с помощью юриста — просто и понятно, можно работать дальше.
Или даже так:
— Что делать-то будем?
— Исправим через полгода.
— А сейчас?
— Ну там напишите ему что-нибудь, чтобы он на реддите про это не рассказал. Юристу сообщите.
А дальше юрист по накатанной, не особо разбираясь, что это было.
Или даже так:
— Что делать-то будем?
— Исправим через полгода.
— А сейчас?
— Ну там напишите ему что-нибудь, чтобы он на реддите про это не рассказал. Юристу сообщите.
А дальше юрист по накатанной, не особо разбираясь, что это было.
Ну так это и есть бич больших компаний Вроде и люди отобраны на работу самые лучшие, но число ступенек которые надо пройти чтобы принять любое решение слишком велико и это демотивирует начисто.
На примере Сони столкнулся пару месяцев назад. Их же оборудование с друг другом не работало, по отдельности с другими устройствами сторонних производителей работали. Сначала общение с поддержкой в РФ — аутсорсер. Когда на они поняли, что это нестандартное и рецепты типа отключите от сети, обновите прошивку и т.п. не помогают, написали запрос в Бельгию, обещали ответ за 10 дней, а вышло около месяца. Там мило отписались общими фразами используйте оригинальные аксессуары Сони, наши инженеры изучают вопрос, ожидайте обновления ПО. В переводе на нормальный язык — «никогда», только если такие обращения приобретут массовость, то это будет передано дальше.
В больших компаниях кроме увлеченных профессионалов, попадаются джедаи KPI и просто мудаки на которых можно натолкнуться.
А экстренные решения принимаются быстро, если это не совсем клака. Хороший пример — реакция банков на Heartbleed.
А экстренные решения принимаются быстро, если это не совсем клака. Хороший пример — реакция банков на Heartbleed.
Со Сбербанком так не получится?)
Попробуйте, как раз со Сбербанком может и получиться
На всякий случай лучше быть гражданином другой страны.
Тут главная проблема с обналом. Зачем вам миллионы на сбербанке, все равно же найдут. Дропы и проч это все муторно. А старбакс карты -> биткоины -> отмыв работают как часы
Что мешает осуществить конвертацию сбер -> qiwi / ЯД -> bit coin?
Там повсюду жоский антифрод. Невозможно нагенерить кучу ЯД аккаунтов, и обменять все надежно для масштабных сумм
Самый жёсткий антифрод — там нужно много счетов привязанных к разным людям, чтобы сколько-нибудь интересную сумму поиметь, а вот получить доступ к таким счетам — уже реально сложно. В отделение не придёшь с кучей паспортов открывать счета. :)
А в остальном — с их дырами и их политиками безопасности — по несколько тысяч со счёта утащить можно без палева. Чем и пользуются кардеры. Впрочем это уже касается почти всех банков (мало какие банки имеют параноидальный режим защиты клиентов).
А в остальном — с их дырами и их политиками безопасности — по несколько тысяч со счёта утащить можно без палева. Чем и пользуются кардеры. Впрочем это уже касается почти всех банков (мало какие банки имеют параноидальный режим защиты клиентов).
Неее: может помните случаи с жуткими скандалами о непроходящих транзакциях владельцах карт сбера? (хотели люди в др. гос-ве расплатиться, а банк им фигу, а власти той страны «давайте нал или посидите в отделении»).
Тогда они выложили запрос на международную доску, мол «помогите решить проблему». Ну и народ торкался там, предпологал как.
А знакомый прогер, работавший с ораклом и знавший эту багу (с большой вероятностью именно эту багу) предложил им решить, но ессно не за просто так. Ни ответа, ни привета, а приколы ещё с месяц продолжались.
Так что ждать спасибо от сбера можно только уже купив венок, думаю)
Тогда они выложили запрос на международную доску, мол «помогите решить проблему». Ну и народ торкался там, предпологал как.
А знакомый прогер, работавший с ораклом и знавший эту багу (с большой вероятностью именно эту багу) предложил им решить, но ессно не за просто так. Ни ответа, ни привета, а приколы ещё с месяц продолжались.
Так что ждать спасибо от сбера можно только уже купив венок, думаю)
Они варят плохой кофе и посредственный чай, а вы такой честный!
Интересно поведение безопасников. Вместо награды и отлаживания процессов поиска уязвимостей добровольцами, они в суд обещают сходить.
Мне кажется вам стоило остановиться на идее, изложенной в последнем абзаце.
Интересно поведение безопасников. Вместо награды и отлаживания процессов поиска уязвимостей добровольцами, они в суд обещают сходить.
Мне кажется вам стоило остановиться на идее, изложенной в последнем абзаце.
А если безопасники сами этой дырой пользуются? Тогда да, их поведение абсолютно логично.
Я предполагаю, что поведение «добровольца» может отличаться в зависимости от куша, который он может сорвать.
Если на кону полтора бакса, которые можно только конвертировать в кофе — то поведение одно.
Если на кону миллиард долларов — то добровольца его же собственная жаба может задушить.
Вариант торговли «клонированными» карточками давайте не будем всерьёз рассматривать — гемороя и риска много, а толку мало.
Больше 10 лет назад я сам нашел возможность переводить вебмани с чужого адреса на свой не имея чужого файла приватных ключей кипера, а зная только пароль человека на форуме «околовебманевского» сайта. Поэкспериментировал с одним знакомым (с его согласия). Потом неделю думал, как мне добыть чужие пароли и стать миллионером. Ничего не придумав, «сдал» эту багу в саппорт вебманей и успокоился.
Если на кону полтора бакса, которые можно только конвертировать в кофе — то поведение одно.
Если на кону миллиард долларов — то добровольца его же собственная жаба может задушить.
Вариант торговли «клонированными» карточками давайте не будем всерьёз рассматривать — гемороя и риска много, а толку мало.
Больше 10 лет назад я сам нашел возможность переводить вебмани с чужого адреса на свой не имея чужого файла приватных ключей кипера, а зная только пароль человека на форуме «околовебманевского» сайта. Поэкспериментировал с одним знакомым (с его согласия). Потом неделю думал, как мне добыть чужие пароли и стать миллионером. Ничего не придумав, «сдал» эту багу в саппорт вебманей и успокоился.
>Вариант торговли «клонированными» карточками давайте не будем всерьёз рассматривать — гемороя и риска много, а толку мало.
В чем гемор? Торговля заключается в том что юзер видит объявление, идет покупает себе карту, платит нам биткоины и получает в два раза больше денег на свою карту. Мы — полностью анонимны. Отмываем биткоины, концы в воду.
В чем гемор? Торговля заключается в том что юзер видит объявление, идет покупает себе карту, платит нам биткоины и получает в два раза больше денег на свою карту. Мы — полностью анонимны. Отмываем биткоины, концы в воду.
Ну, для этого же карты нужно нагенерировать, используя дыру?
Писать скрипт, потом еще запускать его через какой-нибудь tor, а потом увидеть то, что старбакс обнаружил в балансах разночтение, а в логах подозрительную активность.
Могло бы получиться так, что на «инфраструктуру» вы бы потратили больше, чем получили бы «выхлоп».
Ну да что я вам это объясняю? Уверен, что вы лучше меня посчитали ситуацию и решили, что честь — дороже.
Писать скрипт, потом еще запускать его через какой-нибудь tor, а потом увидеть то, что старбакс обнаружил в балансах разночтение, а в логах подозрительную активность.
Могло бы получиться так, что на «инфраструктуру» вы бы потратили больше, чем получили бы «выхлоп».
Ну да что я вам это объясняю? Уверен, что вы лучше меня посчитали ситуацию и решили, что честь — дороже.
Ну все зависит от вероятности того что они заметят. Конечно если у них есть статистика то нашли бы после первых тысяч баксов. А если нет, то врядли бы нашли вообще
А не должно ли быть в таких системах инструментов для анализа всей денежной массы в системе? То есть если общее количество денег на картах увеличивается быстрее, чем разница совокупного прихода и расхода, значит они возникают из ниоткуда.
Конечно, должно, но только в таких системах и безусловное использование транзакций для любых денежных переводов тоже быть должно.
int x = 5;
if ( x != 5 ) // если не присвоилось
{
…
}
Конечно, должен быть анализ. Вопрос в том — как и кем он был писан, как его тестировали и насколько часто его смотрят. Если какой-то скрипт будет вам в течение года выдавать фразу «В Багдаде всё спокойно», то вы просто перестанете его запускать.
if ( x != 5 ) // если не присвоилось
{
…
}
Конечно, должен быть анализ. Вопрос в том — как и кем он был писан, как его тестировали и насколько часто его смотрят. Если какой-то скрипт будет вам в течение года выдавать фразу «В Багдаде всё спокойно», то вы просто перестанете его запускать.
Впрочем, это капитанство, только так это и должно работать.
Тем временем официант одной ресторанной сети 8 лет назад торговал скопированными дисконтными картами почти год. Уволился не бедным человеком.
И последнее мое предложение носило скорее юмористический характер.
И последнее мое предложение носило скорее юмористический характер.
> далеко не каждый программист при проектировке программ учитывает такие факторы, как параллельность выполнения кода и его последствия
Только не в том случае, если речь идет о деньгах или других важных данных. Перевод денег должен осуществляться в рамках одной транзакции.
Только не в том случае, если речь идет о деньгах или других важных данных. Перевод денег должен осуществляться в рамках одной транзакции.
Тут дело не только в транзакциях. Не раз сталкивался с программистами считающими что они знают что делают, при этом локающие лишь один аккаунт из двух, или локающие без создания транзакции. Там куча тонкостей. Поэтому не стоит быть таким уверенным что «я то эту ошибку не допущу».
Согласен, существует много нюансов. Поэтому и надо следовать железному правилу — все операции с деньгами только внутри транзакций.
Предполагаю, что изначальный вариант карт был без возможности переводов между ними.
И на этом строилась вся архитектура.
Когда понадобились переводы — пришлось вставлять костыли в систему, которая не была на это расчитана.
Хорошо, если дорабатывали те же, что писали первоначальный вариант. А если эту доработку поручили другим? Представляю себе сколько мата там было.
И на этом строилась вся архитектура.
Когда понадобились переводы — пришлось вставлять костыли в систему, которая не была на это расчитана.
Хорошо, если дорабатывали те же, что писали первоначальный вариант. А если эту доработку поручили другим? Представляю себе сколько мата там было.
Все хитрее. В базе не должно быть такой записи как «текущий баланс клиента». Баланс должен каждый раз рассчитываться на основе документов-движения средств.
Т.е. если у аккаунта есть две записи «внесение $10», потом «оплата за кофе $5.5», значит баланс сейчас $4.5. И никакие рейс-кондишены не страшны.
Конечно, каждый раз считать баланс с начала времен тяжело, поэтому можно и нужно заводить какие-то опорные точки, например на границе месяца, недели, суток, и считать относительно них.
Т.е. если у аккаунта есть две записи «внесение $10», потом «оплата за кофе $5.5», значит баланс сейчас $4.5. И никакие рейс-кондишены не страшны.
Конечно, каждый раз считать баланс с начала времен тяжело, поэтому можно и нужно заводить какие-то опорные точки, например на границе месяца, недели, суток, и считать относительно них.
И никакие рейс-кондишены не страшны.
Ошибаетесь, покупаем две анонимные карты по 5$, организуем 100 параллельных транзакций по переводу 5$ с одной карты на другую, в результате у нас две карты на одной +505$ на другой -500$ (вторая карта просто не успеет «понять» что баланс ушел в минус), выкидываем вторую и выводим деньги с первой в биткоины. К тому моменту когда начнутся разборки у злоумышленников уже будет пару миллионов в биткоинах. Профит.
Хм, ну тоже верно. Технический овердрафт получается.
Как вариант, можно периодически запускать задачу, которая будет откатывать транзакции, приводящие к овердафту. Хотя, тоже не лучшее решение.
Как вариант, можно периодически запускать задачу, которая будет откатывать транзакции, приводящие к овердафту. Хотя, тоже не лучшее решение.
Если все действия записывать в виде последовательных событий, то проблему можно легко решить.
Прежде чем перевести деньги, поток должен создать событие «хочу перенести 5 баксов» и записать в хранилище. у каждого события будет свой уникальный ИД.
Далее пробегаемся по всем событиям с самого начала до этого события, и смотрим, хватает ли сумма. Если да, то создаем событие что перевод одобрен.
Допустим параллельно запустили 2 поток, он то же создал событие заявку. И когда пробегается по всем событиям, он видит что другой поток оставил заявку на снятие раньше. Поэтому из баланса условно вычитаем эту сумму. И когда доходим до нашего события-заявки, то видим, что баланс пустой и создаем событие, что нашу заявку выполнять не нужно.
3 поток видит что 2 поток создал заявку(-5 баксов) и потом отменил(+5 баксов), в итоге 2 поток никак на баланс не повлиял.
Прежде чем перевести деньги, поток должен создать событие «хочу перенести 5 баксов» и записать в хранилище. у каждого события будет свой уникальный ИД.
Далее пробегаемся по всем событиям с самого начала до этого события, и смотрим, хватает ли сумма. Если да, то создаем событие что перевод одобрен.
Допустим параллельно запустили 2 поток, он то же создал событие заявку. И когда пробегается по всем событиям, он видит что другой поток оставил заявку на снятие раньше. Поэтому из баланса условно вычитаем эту сумму. И когда доходим до нашего события-заявки, то видим, что баланс пустой и создаем событие, что нашу заявку выполнять не нужно.
3 поток видит что 2 поток создал заявку(-5 баксов) и потом отменил(+5 баксов), в итоге 2 поток никак на баланс не повлиял.
Я рассмотрел вариант с SELECT… FOR UPDATE, которая собственно и придумана для конкуретной выборки.
пользователь А, хочет перевести деньги пользователю Б.
он делает select… for update для своей строки и потом select… for update для строки пользователя Б.
делает апдейты, и комитит изменения, освобождая тем самым строки.
Но тут возможна взаимоблокировка:
когда пользователь А хочет перевести деньги пользователю Б, а пользователь Б — наоборот, хочет перевести деньги пользователю А.
1) пользователь А блокирует запись А
2) пользователь Б блокирует запись Б
3) пользователь А пытается заблокировать запись Б, которая уже заблокирована пользвателем Б, следовательно пользователь А подвисает в состоянии ожидания.
4) пользователь Б пытается заблокировать запись А, которая уже заблокирована пользователем А,
ждет, когда она разблокируется… а она не разблокируется, потому что пользователь А ждет, когда разблокируется строка Б (смотри шаг 3).
Как этого избежать?
Я предлагаю всегда первым лочить строку с наименьшим айдишником.
Если у строки А айдишник меньше чем у Б, то её всегда лочить первой, независимо от того, какой пользователь, куда хочет перевести деньги.
пользователь А, хочет перевести деньги пользователю Б.
он делает select… for update для своей строки и потом select… for update для строки пользователя Б.
делает апдейты, и комитит изменения, освобождая тем самым строки.
Но тут возможна взаимоблокировка:
когда пользователь А хочет перевести деньги пользователю Б, а пользователь Б — наоборот, хочет перевести деньги пользователю А.
1) пользователь А блокирует запись А
2) пользователь Б блокирует запись Б
3) пользователь А пытается заблокировать запись Б, которая уже заблокирована пользвателем Б, следовательно пользователь А подвисает в состоянии ожидания.
4) пользователь Б пытается заблокировать запись А, которая уже заблокирована пользователем А,
ждет, когда она разблокируется… а она не разблокируется, потому что пользователь А ждет, когда разблокируется строка Б (смотри шаг 3).
Как этого избежать?
Я предлагаю всегда первым лочить строку с наименьшим айдишником.
Если у строки А айдишник меньше чем у Б, то её всегда лочить первой, независимо от того, какой пользователь, куда хочет перевести деньги.
Я предлагаю всегда первым лочить строку с наименьшим айдишником.
Вообще, надо лочить обе строки сразу. Но такая вещь в параллельном программировании называется deadlock, по методам борьбы с ней написана тонна книжек и придумана куча теорий. Если кратко полностью избавиться от deadlock'ов практически невозможно, но можно уменьшить шанс их появления до очень маленького.
А вы мой комент читали?
Читал. В чем проблема сделать во время транзакции SELECЕ… WHERE id in (запись_А, запись_B) FOR UPDATE? Вообще, методы правильных организаций критичных транзакций и блокировок — тема избитая годами исследований, не стоит там изобретать велосипедов.
А я и не изобретаю, я использую старый «select for update» для этого.
Ну если можно лочить сразу две строки с помощью SELECT FOR UPDATE..., то хорошо.
Ну если можно лочить сразу две строки с помощью SELECT FOR UPDATE..., то хорошо.
Есть же в mysql и транзакции и Atomic операции, которые надо только правильно настроить и использовать, они сами все блокируют и изолируют, ручная реализация транзакций и блокировок для критичных финансовых операций и приводят к подобным уязвимостям.
>>ручная реализация транзакций и блокировок
вы так говорите, как будто я сам этот select for update придумал.
вообще-то у них в документации MySQL dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
как раз и разбирается некий гипотетический пример c select for update
По вашей ссылке я не нашёл противоречия способу с select for update.
Только перед select for update надо отключить autocommit
вы так говорите, как будто я сам этот select for update придумал.
вообще-то у них в документации MySQL dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
как раз и разбирается некий гипотетический пример c select for update
По вашей ссылке я не нашёл противоречия способу с select for update.
Только перед select for update надо отключить autocommit
И кстати, по вашей ссылке упоминается LOCK TABLES, а select for update лочит только строки, что лучше.
Вы описали обычные транзакции с блокировкой ресурсов.
Ну не совсем. Во первых «блокировка» будет только в случае, если денег на счету не хватает. А если там много денег, то эти операции будут выполнены без всяких блокировок параллельно. Причем всю логику можно легко настроить под себя.
Во вторых, я бы не стал использовать реляционную модель с операциями UPDATE/DELETE при работе с денежными средствами. Если посмотреть как работают бухгалтеры, то заметите что они ведут отдельные записи прихода и расхода. И уже потом считают сколько денег было на определенный момент. Операции UPDATE сотрут такого рода информацию.
Во вторых, я бы не стал использовать реляционную модель с операциями UPDATE/DELETE при работе с денежными средствами. Если посмотреть как работают бухгалтеры, то заметите что они ведут отдельные записи прихода и расхода. И уже потом считают сколько денег было на определенный момент. Операции UPDATE сотрут такого рода информацию.
Эээ, просто надо настроить правильные уровни изоляции транзакций СУБД и вообще правильно использовать транзакции, все вопросы по безопасному переводу денег давно уже изучены и внедрены во все популярные СУБД, просто нужно внимательно изучать документацию к ним.
P.S. Кстати, транзакции есть не только в СУБД, но и языках программирования.
P.S. Кстати, транзакции есть не только в СУБД, но и языках программирования.
Так может напишите пост, как не допускать race condition?
Я по другую сторону баррикад ;)
как вариант habrahabr.ru/post/258449/#comment_8429455
Надо отдавать отчет, что отвечал вам, скорее всего, не ответственный представитель компании, а низкий чин, который за наличие такой уязвимости в системе компании мог поплатиться премией, а то и должностью. Желание «припугнуть» вас могло быть продиктовано страхом перед тем, что информация просочится наверх.
Любопытно, какая бы была реакция, если бы вы заранее намекнули на то, что сделаете информацию об этой уязвимости публичной после ее устранения и широко распространите весть. То есть никаких шансов выйти сухими из воды для них не будет. Тогда-то бы, может, засуетились.
Ну и, собственно, как насчет того, чтобы приложить усилия, чтобы об этом посте, а лучше, наверное, о его англоязычной версии на каком-нибудь популярном сайте, узнали в компании где-нибудь повыше? Кейс-то ого-го. Те, кто считает, что инициатива наказуема, должны быть наказаны :-D
Любопытно, какая бы была реакция, если бы вы заранее намекнули на то, что сделаете информацию об этой уязвимости публичной после ее устранения и широко распространите весть. То есть никаких шансов выйти сухими из воды для них не будет. Тогда-то бы, может, засуетились.
Ну и, собственно, как насчет того, чтобы приложить усилия, чтобы об этом посте, а лучше, наверное, о его англоязычной версии на каком-нибудь популярном сайте, узнали в компании где-нибудь повыше? Кейс-то ого-го. Те, кто считает, что инициатива наказуема, должны быть наказаны :-D
>Тогда-то бы, может, засуетились.
Не рассматриваете, что они засуетятся не в том направлении?
И начнут жестко пресовать через ментов и попытаются закрыть.
Вместо устранения уязвимости.
Не рассматриваете, что они засуетятся не в том направлении?
И начнут жестко пресовать через ментов и попытаются закрыть.
Вместо устранения уязвимости.
На Западе-то — вряд ли. Представьте, допустим, что какой-то всемирно известный спец по безопасности, выступающий на конференциях, любимчик публики, на досуге это обнаруживает. И переводит себе 5$ — цену одной чашки кофе. Компания бы выставила себя на посмешище. Это при условии должной публичности, конечно.
Я примерно о том же писал выше. Только лучше всё-таки обратиться по инстанции к руководителю этого кренделя, и дальше, пока не отнесутся серьёзно. Кстати, в результате «гонки» деньги можно ведь и потерять — а вот тогда уже их самих можно будет засудить.
Символичная уязвимость.
Brian Goetz в книге «Java Concurrency in Practice» в главе 2.2.1. Race Conditions как раз объясняет проблему «race conditions» на примере двух заведений Starbucks
books.google.com.ua/books?id=EK43StEVfJIC&pg=PT43&lpg=PT43&source=bl&ots=uoWzy2rTjz&sig=ip9dsA3gjzd7KoyBebrVfSkEMyc&hl=ru&sa=X&ei=4tFdVbuqGMSssgHx1YG4Dg&ved=0CB0Q6AEwAA#v=onepage&q&f=false
Brian Goetz в книге «Java Concurrency in Practice» в главе 2.2.1. Race Conditions как раз объясняет проблему «race conditions» на примере двух заведений Starbucks
books.google.com.ua/books?id=EK43StEVfJIC&pg=PT43&lpg=PT43&source=bl&ots=uoWzy2rTjz&sig=ip9dsA3gjzd7KoyBebrVfSkEMyc&hl=ru&sa=X&ei=4tFdVbuqGMSssgHx1YG4Dg&ved=0CB0Q6AEwAA#v=onepage&q&f=false
> высосать пару миллионов долларов из этой дружелюбной фирмы со сладким кофе
Купить джип, написать по заднему стеклу «Высосал из дружелюбной фирмы со сладким кофе», и ездить себе с улыбкой!
Ах да, неплохо бы то же сделать и с картой какой-нибудь дружелюбной топливной компании, чтобы джип заправлять ;)
P.S. Откровенно, ожидал финала «дырку заткнули, а моя карта была помечена как делающая 100% скидку лично мне».
Купить джип, написать по заднему стеклу «Высосал из дружелюбной фирмы со сладким кофе», и ездить себе с улыбкой!
Ах да, неплохо бы то же сделать и с картой какой-нибудь дружелюбной топливной компании, чтобы джип заправлять ;)
P.S. Откровенно, ожидал финала «дырку заткнули, а моя карта была помечена как делающая 100% скидку лично мне».
Автор так и сделал. Не будет же он кричать об этом на весь интернет.
Нет, ни в коем случае. Карты я уничтожил, так что они мне еще должны $8.30
Неужели, если постоянно переводить средства с карт, описанным в статье способом, и накрутив ну пусть не $1000 000, а хотя бы $1000, то это останется незаметным?
Пускай не каждый день, не раз в неделю, ну хотя бы раз в месяц какие-то отчеты проводятся, увидят, сколько карт куплено, сколько по этим картам снято. Я думаю маркетинг в таких компаниях хорошо построен и различные отчеты присутствуют и их, самое главное, просматривают. По крайней мере за рубежом точно.
Пускай не каждый день, не раз в неделю, ну хотя бы раз в месяц какие-то отчеты проводятся, увидят, сколько карт куплено, сколько по этим картам снято. Я думаю маркетинг в таких компаниях хорошо построен и различные отчеты присутствуют и их, самое главное, просматривают. По крайней мере за рубежом точно.
сколько карт куплено, сколько по этим картам снято.
А что они увидят? Куплено карт на 1 млн. $, снято на 900 тыс. $. Дело в том что можно купить карту год назад и только сейчас снять деньги, можно купить карту и вообще её потерять, то есть ничего с неё не снять, 100% совпадения в одном месяце куплено/снято никогда не будет. А если и увидят, то будут долго и муторно искать причину ошибок в первую очередь в построении отчетов. А если там ещё проводятся всякие акции «купи пять карт по цене шести», то концов вообще не найдешь. К тому моменту когда найдут дыру в безопасности злоумышленики давно будут отдыхать на собственном острове.
Надеюсь, вам такими системами никогда заниматься не придется.
Занимался :), поверьте вытащить из статистики приходов и расходов действительный текущий баланс по всей крупной корпорации с филиалами по всему мире ОЧЕНЬ сложно, сама по себе операция синхронизации десятков СУБД довольно сложная.
У старбакса карты действуют в пределах одной страны
Это не так важно, главное что транзакций где-нибудь в США до… фига. Распределенные базы, ошибки при оплатах и переводах в полночь, откаты банковских транзакций, все возможные баги в отчетах и системах. Увы, точное совпадение всех цифр прихода/расхода по всем отчетам за день в больших международных компаниях это скорее фантастика чем обычная практика.
Какие распределенные базы и десятки субд? У старбакса в США 12000 кофеен, большинство посетителей, ну, на глаз, платит всё равно наличкой или банковской картой, очень сомневаюсь, что из одной кофейни оплата старбакс-картой может происходить чаще, чем раз в пару минут. Это в пике 100 rps (думаю, это сильно завышенная оценка), нафига там что-то городить?
FYI где то читал 40 или 60 процентов ВСЕХ денег в системе вращаются через гифт карты.
40% недалеко от правды:
Every week we process over 8 million mobile payment transactions. And for all transactions in our stores we are now up to over 18% are via mobile payment. It was amazing that’s over half of our card payments are now through the app.
seekingalpha.com/article/3015706-starbucks-sbux-ceo-howard-schultz-hosts-2015-annual-meeting-of-shareholders-conference-transcript
То есть всего платежей по картам в неделю около 15 миллионов, то есть около 2 миллионов в день, то есть и 100 rps в пике там вряд ли конечно есть
Every week we process over 8 million mobile payment transactions. And for all transactions in our stores we are now up to over 18% are via mobile payment. It was amazing that’s over half of our card payments are now through the app.
seekingalpha.com/article/3015706-starbucks-sbux-ceo-howard-schultz-hosts-2015-annual-meeting-of-shareholders-conference-transcript
То есть всего платежей по картам в неделю около 15 миллионов, то есть около 2 миллионов в день, то есть и 100 rps в пике там вряд ли конечно есть
Входящие/исходящие остатки, поступления/снятия, а также всякие акции/скидки в отчетах должны быть, где-нибудь, да разницу или несоответствие цифр можно будет увидеть, да и потом историю отчетов никто не отменял и всякие графические выписки тоже.
Если фирма маленькая да можно, если идут миллионы транзакций сложно. Все конечно можно сделать, но слабо вериться что фирма забившая на банальные транзакции, будет заниматься разработкой подобного глобального аудита.
Вы серьезно решили мониторить глазами все миллионы транзакций?
Скрипту аудита глубоко фиолетово сто там транзакций или миллион.
Он выявляет аномалии в движениях.
Тут как бы такой момент. Это не фирма забила на транзакции.
Это ошибка маленького винтика в системе.
А винтиков в таких больших системах много.
Скрипту аудита глубоко фиолетово сто там транзакций или миллион.
Он выявляет аномалии в движениях.
Тут как бы такой момент. Это не фирма забила на транзакции.
Это ошибка маленького винтика в системе.
А винтиков в таких больших системах много.
Нет, не глазами, просто в больших системах все становится сложнее. Со стороны это кажется простым написать один sql запрос/скрипт и все, на самом деле там нужно решать кучу проблем, как-то:
1) согласования таймзон разных серверов,
2) отмененные банковские транзакции,
3) отмененные внутренние транзакции,
4) учет курсов валют в случие разных стран,
6) обмен данными между разными репликами СУБД,
7) учет ошибок, востановлений данных при сбоях СУБД и т.д.
8) учет ошибочных переводов, ошибочных списаний денег в кафе и т.п.
9) и т.п. и т.д.
Казалось бы банки в банковское ПО вкладывают миллионы и тем не менее оно далеко не всегда способно все решать в автоматическом режиме, зачастую оно не может ответить на вопрос на сколько денег у банка на данный момент.
Плюс, ну положем обнаружится появление 1 тыс.$ из ниоткуда и тут возникает вопрос стоимость команды в США из аналитиков, программистов, тестеров по поиску и исправлению таких ошибок в огромных системах может измерятся десятками и сотнями тысяч.$, не считая нагрузки на оборудования и т.п. И тут перед бизнесом возникает вопрос «а оно того стоит?»
1) согласования таймзон разных серверов,
2) отмененные банковские транзакции,
3) отмененные внутренние транзакции,
4) учет курсов валют в случие разных стран,
6) обмен данными между разными репликами СУБД,
7) учет ошибок, востановлений данных при сбоях СУБД и т.д.
8) учет ошибочных переводов, ошибочных списаний денег в кафе и т.п.
9) и т.п. и т.д.
Казалось бы банки в банковское ПО вкладывают миллионы и тем не менее оно далеко не всегда способно все решать в автоматическом режиме, зачастую оно не может ответить на вопрос на сколько денег у банка на данный момент.
Плюс, ну положем обнаружится появление 1 тыс.$ из ниоткуда и тут возникает вопрос стоимость команды в США из аналитиков, программистов, тестеров по поиску и исправлению таких ошибок в огромных системах может измерятся десятками и сотнями тысяч.$, не считая нагрузки на оборудования и т.п. И тут перед бизнесом возникает вопрос «а оно того стоит?»
А самый прикол ведь в том, что Старбакс действительно получает больше денег на свой счет и тупо генерит сам себе сколько захочет виртуальных долларов.
Я вас понимаю и поддерживаю. Получить адекватный ответ не всегда просто. Например с ноября 2014 пытаюсь достучаться до одной компании, которая не защитила паспортные данные своих клиентов. Фирма не маленькая, судя по данным, но ответа по теме так и не получил. Выкладывать на хабр такую вещь до исправления довольно опасно, т.к. могут пострадать невинные люди, а оповестить надо.
Чем крупнее матодонт, тем сложней его вращать) Вопрос всегда один: в мотивации. Если найти в паспортных данных работников данной орг-ции глядишь и расшевелятся, если правильные слова подобрать.
Напишите руководителю приблизительно так: ваша организация не защитила паспортные данные своих клиентов, таким образом нарушила 152-ФЗ.
Если и такое обращение не сработает, пиши в прокуратуру о факте нарушения.
Если и такое обращение не сработает, пиши в прокуратуру о факте нарушения.
Мда. Все как обычно, нашару делается.
Esli oni tak neblagodarno sebya vedut — stoit napisat' business-ethics complaint: businessconduct.eawebline.com
Ого, ты уже в Калифорнию перебрался. Можно где-то почитать про опыт переезда?
жесть конечно читать «состояние гонки»
В студенческие времена пополнял интернет местного провайдера использую похожую уязвимость. Купил карточку на 25, пополнил на 200. Но провайдер был не очень, через пару месяцев перешел на другой так и не использовав «вирутальные» деньги.
К слову
geektimes.ru/post/250390
geektimes.ru/post/250390
О, про вас BBC «раструбили»:
www.bbc.com/news/technology-32844123
www.bbc.com/news/technology-32844123
Меня удивила поощрительная риторика в статье на BBC. Даже не смотря на тренд в их прессе по демонизации русских хакеров и русских вцелом.
Замечательная статья, замечательная уязвимость, замечательный итог.
Очень надеюсь, что старбакс не прибегнет к давлению на автора.
Замечательная статья, замечательная уязвимость, замечательный итог.
Очень надеюсь, что старбакс не прибегнет к давлению на автора.
Ну вообще-то, справедливости ради, ни слова в статье что хакер русский не прозвучало, да мы-то знаем что имя Егор русское, но 99.9% мира — нет. ИМХО.
А что мешало им написать: хакер, предположительно, работающий на российское правительство, взломал старбакс, после чего обнародовал способ взлома с целью обрушить акции компании?
Ну и зачем кому-то нужна такая явная ложь, если у любого СМИ есть сто один способ обмануть, сказав чистую правду и ничего кроме правды?
Попробуйте доказать, что вешеобозначенная версия публикации является ложной. Да и кто на этот счёт будет там беспокоиться?
Не знаю как Вы, но не питаю иллюзий о неполживости западных (ди и остальных) масс-медиа.
ru.wikipedia.org/wiki/Большая_ложь
Впрочем, это не относится к теме публикации, поэтому не думаю, что следует продолжать.
Не знаю как Вы, но не питаю иллюзий о неполживости западных (ди и остальных) масс-медиа.
Чем больше ложь, тем скорее в нее поверят — Адольф Гитлер
ru.wikipedia.org/wiki/Большая_ложь
Впрочем, это не относится к теме публикации, поэтому не думаю, что следует продолжать.
Тренд, скорее, против россиян и особенно правительства РФ.
К русским отношение не изменилось в последние годы.
К русским отношение не изменилось в последние годы.
Хм, ну получается, всё что вы получили за свою работу — кофе по сниженной цене. А по большому счёту его следовало вернуть прямо на кассе без объяснения причины.
Кстати, не так давно я случайно обнаружил уязвимость в одной платёжной системе. После вашей статьи тоже жду от них привета.
Кстати, не так давно я случайно обнаружил уязвимость в одной платёжной системе. После вашей статьи тоже жду от них привета.
ОМГ, откуда столько плюсов за достаточно обычную для этого сайта статью?)
Вообще-то, обычной она была если бы это был перевод статьи какого нибудь «Джонса как он взломал старбакс». В этой статье автор утверждает (и нет оснований ему не верить), что именно он лично взломал известную всему миру компанию и описывает процесс. Подобных статьей на хабре хорошо если несколько за год будет.
Интересно, а что заставило произвести и 6 попытку после 5 неудачных?
Я к тому, что уязвимость же могла проявиться не на 6, а на 106 раз.
Aka, нельзя быть на все 100 уверенным в наличие race-condition`а.
Я к тому, что уязвимость же могла проявиться не на 6, а на 106 раз.
Aka, нельзя быть на все 100 уверенным в наличие race-condition`а.
Homakov, а почему они не объединили два запроса в один и почему происходил этот race-condition?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я взломал Starbucks для безлимитного кофе