Возможно, стоит пояснить разницу между синхронизацией из thread/process-safe и синхронизацией с помощью Lock🤔
Наша задача — заставить разные процессы и потоки обращаться к базе данных (или любым другим ресурсам) последовательно. Чтобы не случилось так называемого race condition, то есть состояние гонки. Это когда разные потоки или процессы пытаются одновременно что-то сделать с одним и тем же ресурсом.
В этом случае нам нужна какая-то логика ограничения. Пока один процесс не завершил своё действие, другие не могут получить доступ к ресурсу.
Так вот, thread-safe и process-safe означает что отдельно взятые операции записи в БД гарантированно будут последовательны. Запросы из разных процессов или потоков выстроятся в очередь и не будут мешать друг другу. Лучше всего когда этот блок реализован на уровне БД в виде атомарных операций или ещё как-то.
Но зачем нам тогда еще дополнительный Lock?
Этот способ синхронизации используется когда процесс никак не укладывается в одно действие и должен сделать множество операций прежде чем дать доступ следующему. В этом случае процесс ставит некий глобальный Lock на ресурс и никто другой, даже получив законное право на доступ, не может ничего сделать. Все ждут пока этот Lock не будет снят.
Это решается на уровне приложения и правильность реализации полностью в вашей ответственности. Например, если забыли разблокировать или сделали перекрёстный Lock (Deadlock как на картинке), то всё зависнет в бесконечном ожидании.
#basic
Настольная книга.
Если вы давно мечтали увидеть все инструменты в одном месте, а не сохранять кучу разрозненных ссылок "на потом", то мы нашли буквально настольную книгу для исследователей безопасности.
Наполнение:
- Исследование сетей;
- Управление уязвимостями;
- Мониторинг безопасности;
- и многое другое, классное, интересное.
К каждому инструменту идёт краткое описание и минимально полезный набор команд.
Мы себе уже сохранили, рекомендуем поступить также.
#AppSec#DFIR
🧠Кибер ПТУ | 👨🏫Менторство ИБ
📂Другие каналы
• Нашел на GitHub преднамеренно уязвимое банковское веб-приложение, которое содержит множество дыр в безопасности. Такие проекты помогают получить бесценныйопыт ИБ специалистам, пентестерам, DevSecOps и программистам, в части поиска уязвимостей и безопасной разработки. На текущий момент веб-приложение содержит более 40 уязвимостей (на скриншоте выше), которые вам придется найти. Если не справляетесь или недостаточно опыта, то у автора есть подробный гайд по прохождению:
➡️GitHub;
➡️Руководство [VPN].
• Кстати, там еще есть уязвимое мобильное приложение. На сколько оно дырявое не указано, да и подробного гайда нет, но если вам интересно, то забирайте по этой ссылке.
#AppSec#ИБ#Web#Пентест
У Checkmarx вышел отчёт "The Future of APPLICATION SECURITY 2024" содержащий чудесный ТОП3 отмазок "почему уязвимый код ушёл в прод?" (от AppSec менеджеров, CISO и разработчиков).
AppSec менеджеры
1. Чтобы уложиться в дедлайны, связанные с бизнесом, выкаткой фич или безопасностью.
2. Уязвимость должна была быть исправлена в более позднем релизе.
3. Уязвимость не была критической.
CISO
1. Надеялись, что уязвимость не будет эксплуатабельной.🤞
2. Чтобы уложиться в дедлайны, связанные с бизнесом, выкаткой фич или безопасностью.
3. Уязвимость не была эксплуатабельной.
Разработчики
1. Уязвимость должна была быть исправлена в более позднем релизе.
2. Уязвимость не была критической.
3. Чтобы уложиться в дедлайны, связанные с бизнесом, выкаткой фич или безопасностью.
Варианты AppSec менеджеров и Разработчиков различаются только порядком. А вот CISO больше про реальную эксплуатабельность (чтобы это не привело к большому скандалу) и надежду на лучшее. 😏😅
@avleonovrus#Checkmarx#AppSec#fun