Возможно, стоит пояснить разницу между синхронизацией из thread/process-safe и синхронизацией с помощью Lock🤔
Наша задача — заставить разные процессы и потоки обращаться к базе данных (или любым другим ресурсам) последовательно. Чтобы не случилось так называемого race condition, то есть состояние гонки. Это когда разные потоки или процессы пытаются одновременно что-то сделать с одним и тем же ресурсом.
В этом случае нам нужна какая-то логика ограничения. Пока один процесс не завершил своё действие, другие не могут получить доступ к ресурсу.
Так вот, thread-safe и process-safe означает что отдельно взятые операции записи в БД гарантированно будут последовательны. Запросы из разных процессов или потоков выстроятся в очередь и не будут мешать друг другу. Лучше всего когда этот блок реализован на уровне БД в виде атомарных операций или ещё как-то.
Но зачем нам тогда еще дополнительный Lock?
Этот способ синхронизации используется когда процесс никак не укладывается в одно действие и должен сделать множество операций прежде чем дать доступ следующему. В этом случае процесс ставит некий глобальный Lock на ресурс и никто другой, даже получив законное право на доступ, не может ничего сделать. Все ждут пока этот Lock не будет снят.
Это решается на уровне приложения и правильность реализации полностью в вашей ответственности. Например, если забыли разблокировать или сделали перекрёстный Lock (Deadlock как на картинке), то всё зависнет в бесконечном ожидании.
#basic
• Нашел интересный ресурс, который содержит информацию об основных веб-уязвимостях. Особенность данной платформы в том, что каждый из перечисленных методов можно выполнить самостоятельно, следуя подсказкам и примерам. А еще каждый пример является интерактивным, поэтому вам будет легче воспринимать материал и практиковаться. Содержание следующее:
➡SQL Injection;
➡Cross-Site Scripting;
➡Command Execution;
➡Clickjacking;
➡Cross-Site Request Forgery;
➡Directory Traversal;
➡Reflected XSS;
➡DOM-based XSS;
➡File Upload Vulnerabilities;
➡Broken Access Control;
➡Open Redirects;
➡Unencrypted Communication;
➡User Enumeration;
➡Information Leakage;
➡Password Mismanagement;
➡Privilege Escalation;
➡Session Fixation;
➡Weak Session IDs;
➡XML Bombs;
➡XML External Entities;
➡Denial of Service Attacks;
➡Email Spoofing;
➡Malvertising;
➡Lax Security Settings;
➡Toxic Dependencies;
➡Logging and Monitoring;
➡Buffer Overflows;
➡Server-Side Request Forgery;
➡Host Header Poisoning;
➡Insecure Design;
➡Mass Assignment;
➡Prototype Pollution;
➡Regex Injection;
➡Remote Code Execution;
➡Cross-Site Script Inclusion;
➡Downgrade Attacks;
➡DNS Poisoning;
➡SSL Stripping;
➡Subdomain Squatting.
➡️https://www.hacksplaining.com/lessons
#web
🔴 Уязвимости аутентификации | Безопасность web приложений.
• В этом ролике подробно описаны механизмы аутентификации, чем опасны их уязвимости и как можно их защитить. Также автор рассказывает, как работают механизмы аутентификации и разбирает на примерах прохождение лаб на платформе — https://portswigger.net/web-security
• 0:00 — уязвимости аутентификации;
• 0:22 — аутентификация это / типы аутентификации;
• 1:30 — как возникают уязвимости / последствия уязвимостей;
• 2:16 — как используются уязвимости на практике / Лаба 1;
• 6:18 — как используются уязвимости на практике / Лаба 2;
• 8:45 — как защитить механизмы аутентификации;
• 10:32 — где проходить лаборатории.
➡️https://youtu.be/lWYJ1vD9OEM
#web