Pull to refresh

Comments 10

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

Как можно написать приложение, работающее с деньгами, не осилив транзакции? Такое разве бывает?
Я не понял, в чём вопрос. Просто берёшь и пишешь. Достаточно компьютера и рук с пальцами. ;)

Реально вопрос другой: «Как можно брать на работу по написанию приложения, работающего с деньгами, программиста, не усвоившего транзакции?», или, что то же самое, «Как можно принимать для работы с деньгами программы от программиста, не усвоившего транзакции?».

Попробуем найти ответ:
  1. Решения принимают менеджеры. Конечно, брать на работу программиста должен руководитель группы программистов, т.е. по идее — тоже программист, но взрослый, опытный и ответственный. Но беда в том, что руководителя группы программистов назначает менеджер, который ни разу не программист.
  2. Критерии назначения на должность (особенно на руководящую должность) в крупных организациях весьма своеобразные (на взгляд людей моего уровня, разумеется). В частности, есть критерий «родственник большого начальника» — который заведомо сильнее критерия «взрослый, опытный и ответственный.»
  3. У меня есть серьёзные основания полагать, что скоро появится критерий принадлежности к правильной конфессии. Да собственно, кое-где он уже вовсю применяется.
  4. Система образования деградирует. Причём давно — по утверждениям некоторых людей, аж примерно с 196*-х годов.
  5. Эффект Даннинга-Крюгера учитываем.
Так что ничего удивительного в том, что не-транзакционный код можно встретить где угодно, в т.ч. и там, где он необходим.

Когда я преподавал студентам, я рассказывал им о транзакциях. Причём рассказ строился не столько о том, как они устроены и работают — сколько о том, зачем они вообще нужны. Рассказывал о неработающих методах — причём подсовывал их так, чтобы студенты сами заметили ошибку. Рассказывал о неэффективных методах — начиная с «делать всё строго по очереди»; и говорил, когда это имеет смысл.
Мой курс я строил из моего опыта — сам я очень долго не мог понять, что это такое и зачем оно нужно. Правда, я учился в 198*-х, и видимо, до меня хорошие книжки тогда просто не дошли.

А сейчас (после разрушения СССР) добавилась ещё одна проблема: СМИ пропагандируют идею о том, что учиться не нужно. Собственно, 199*-е показали, что жизненный успех слабо коррелирует с хорошей учёбой. Да и сейчас это тоже в полной мере имеется.

В идеале надо бы запретить сериалы типа «Студенты» и «Общага» — в которых студенты ни грамма не учатся. Надо снимать сериалы, в которых среди действия читаются лекции, и профессор при этом рассказывает что-то умное в доступной форме. Ну, примерно как в научной фантастике до 196*- годов было принято рассказать какие-то технические подробности супер-техники.
Да кто же это позволит сделать?
Транзакции то человек может и освоил, а как их правильно применять — нет. Тут нужно знать про свои инварианты.
Тут еще стоит добавить про оптимистические блокировки на уровне приложения, где в реальности блокировки не происходит, но транзакция упадет в случае если race condition все-таки произошел.

Обычно, применяют следующие методы борьбы с атакой:
...


  • Самый популярный способ — это тупо забить. Используется повсеместно всякими реактивщиками, асинхронщиками, корутинщиками и прочими хипстерАми.
  • Все изменения выполнять строго последовательно. Используется в большинстве кустарных систем оплаты и некоторых банках.

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

Вас намеренно ввели в заблуждение!


Во-первых идемпотентностью обладают только транзакции с уровнем serializable, а он установлен далеко не везде. Большинство пипла по дефолту работают в read-commited и уверены, что все ОК. Особо продвинутые все-таки кое-где расставляют локи вручную типа SELECT FOR UPDATE, но зачастую забывают. Так работают чуть менее чем все системы.


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


Ну и во-вторых, транзакции практически несовместимы с новомодным асинхронным процессингом и всякими no-blocking архитектурами и практически всегда требуют старый добрый thread-per-request pattern. А это на сегодняшний день расточительство, не везде поддерживается и вообще не модно, не стильно и не молодежно. Тут уж приходится выбирать — шашечки или ехать.

Во-первых идемпотентностью обладают только транзакции с уровнем serializable, а он установлен далеко не везде. Большинство пипла по дефолту работают в read-commited и уверены, что все ОК.

Я включаю понятие "использование правильного уровня изоляции" в понятие "использование транзакций".


Кстати, "большинство пипла" используют ORM, а они, как правило, используют оптимистичные блокировки. В таком случае уровня изоляции read-commited более чем достаточно.


Ну и во-вторых, транзакции практически несовместимы с новомодным асинхронным процессингом [...] и практически всегда требуют старый добрый thread-per-request pattern.

Чушь.

Кстати, "большинство пипла" используют ORM, а они, как правило, используют оптимистичные блокировки. В таком случае уровня изоляции read-commited более чем достаточно.

Здесь стоит поставить звездочку * и дописать внизу:


  • под оптимистичными блокировками подразумеваются медленный и выставленный вручную OPTIMISTIC_WRITE а не дефолтный OPTIMISTIC_READ. В противном случае optimistic lock бесполезен и дублирует проверки БД.
  • ORM гарантирует целостность на уровне одной entity, но не коллекций и отношений.
  • общий гарантированный ORM уровень изоляции со всеми блокировками не превышает уровень изоляции БД.
Only those users with full accounts are able to leave comments. Log in, please.