Comments 10
Хочу какой-то демо сервис уязвимый к разному типа атак, на котором можно упражняться. Еще неплохо бы реальных примеров работы с вашей тулзой racepwn.
Реально вопрос другой: «Как можно брать на работу по написанию приложения, работающего с деньгами, программиста, не усвоившего транзакции?», или, что то же самое, «Как можно принимать для работы с деньгами программы от программиста, не усвоившего транзакции?».
Попробуем найти ответ:
- Решения принимают менеджеры. Конечно, брать на работу программиста должен руководитель группы программистов, т.е. по идее — тоже программист, но взрослый, опытный и ответственный. Но беда в том, что руководителя группы программистов назначает менеджер, который ни разу не программист.
- Критерии назначения на должность (особенно на руководящую должность) в крупных организациях весьма своеобразные (на взгляд людей моего уровня, разумеется). В частности, есть критерий «родственник большого начальника» — который заведомо сильнее критерия «взрослый, опытный и ответственный.»
- У меня есть серьёзные основания полагать, что скоро появится критерий принадлежности к правильной конфессии. Да собственно, кое-где он уже вовсю применяется.
- Система образования деградирует. Причём давно — по утверждениям некоторых людей, аж примерно с 196*-х годов.
- Эффект Даннинга-Крюгера учитываем.
Когда я преподавал студентам, я рассказывал им о транзакциях. Причём рассказ строился не столько о том, как они устроены и работают — сколько о том, зачем они вообще нужны. Рассказывал о неработающих методах — причём подсовывал их так, чтобы студенты сами заметили ошибку. Рассказывал о неэффективных методах — начиная с «делать всё строго по очереди»; и говорил, когда это имеет смысл.
Мой курс я строил из моего опыта — сам я очень долго не мог понять, что это такое и зачем оно нужно. Правда, я учился в 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 уровень изоляции со всеми блокировками не превышает уровень изоляции БД.
en.wikipedia.org/wiki/Nagle%27s_algorithm
Race condition в веб-приложениях