Race condition'lar business logic kamchiliklari bilan chambarchas bog'liq keng tarqalgan zaiflik turi. Ular vebsaytlar so'rovlarni yetarli himoyasiz parallel (concurrent) qayta ishlaganda yuzaga keladi. Bu bir nechta alohida oqim (thread) bir vaqtda bir xil ma'lumot bilan ishlashiga olib kelib, "to'qnashuv" (collision) va kutilmagan xatti-harakatga sabab bo'ladi. Race condition hujumi ataylab to'qnashuv keltirib chiqarish uchun ehtiyotkorlik bilan vaqtlangan so'rovlardan foydalanadi.
To'qnashuv mumkin bo'lgan vaqt oralig'i "race window" deb ataladi. Bu, masalan, ma'lumotlar bazasi bilan ikki o'zaro ta'sir orasidagi soniyaning ulushi bo'lishi mumkin.
Eng mashhur race condition turi biror business logic chegarasini oshib ketishga imkon beradi. Masalan, checkout paytida bir martalik chegirma kodi kiritishga imkon beruvchi onlayn-do'konni ko'rib chiqing. Chegirmani qo'llash uchun ilova quyidagi qadamlarni bajaradi:
Endi hech qachon bu kodni qo'llamagan foydalanuvchi uni deyarli bir vaqtda ikki marta qo'llashga urinsa nima bo'lishini ko'ring. Ilova vaqtinchalik sub-holatdan (sub-state) o'tadi — u so'rovni qayta ishlashni boshlaganda kirib, kodni "ishlatilgan" deb belgilaganda chiqadigan holat. Bu chegirmani xohlagancha ko'p marta olishga imkon beruvchi kichik race window yaratadi. Bu hujumning ko'p variantlari bor:
Limit overrun'lar "time-of-check to time-of-use" (TOCTOU) kamchiliklarining bir turi.
Jarayon nisbatan oddiy: biror xavfsizlik ta'siriga ega bir martalik yoki rate-limitli endpoint'ni aniqlab, unga ketma-ket tez so'rovlar yuborib, chegarani oshib bo'ladimi, ko'ring. Asosiy qiyinchilik — so'rovlarni shunday vaqtlashki, kamida ikki race window mos kelib to'qnashuv yuzaga kelsin. Burp Suite 2023.9 Repeater'ga parallel so'rovlar guruhini yuborish imkonini qo'shadi: HTTP/1 uchun last-byte sinxronizatsiya, HTTP/2 uchun esa single-packet attack (bitta TCP paketda 20-30 so'rovni bir vaqtda yuborish).
Turbo Intruder kengaytmasi ham single-packet attack'ni qo'llab-quvvatlaydi. U Python bilishni talab qiladi, lekin murakkabroq hujumlar (ko'p qayta urinish, juda ko'p so'rov) uchun mos:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2
)
# '1'-gate'ga 20 ta so'rov navbatga qo'yish
for i in range(20):
engine.queue(target.req, gate='1')
# '1'-gate'dagi barcha so'rovlarni parallel yuborish
engine.openGate('1')Amalda bitta so'rov ortda butun ko'p bosqichli ketma-ketlikni ishga tushirishi va ilovani bir necha yashirin holatdan o'tkazishi mumkin — biz bularni "sub-holatlar" deb ataymiz. Agar bir xil ma'lumot bilan o'zaro ta'sir qiladigan bir yoki bir nechta HTTP so'rovni aniqlasangiz, bu sub-holatlardan foydalanib, ko'p bosqichli ish oqimlaridagi logic kamchiliklarning vaqtga sezgir variantlarini ochishingiz mumkin. Masalan, buzuq MFA ish oqimida login'ning birinchi qismini bajarib, so'ng forced browsing bilan to'g'ridan-to'g'ri ilovaga o'tib, MFA'ni butunlay chetlab o'tish mumkin:
session['userid'] = user.userid
if user.mfa_enabled:
session['enforce_mfa'] = True
# MFA kodini generatsiya qilib foydalanuvchiga yuborish
# brauzerni MFA kodi formasiga yo'naltirishBu — bitta so'rov ichidagi ko'p bosqichli ketma-ketlik. Muhimi, u foydalanuvchi vaqtinchalik yaroqli login sessiyasiga ega bo'lgan, lekin MFA hali majburiy bo'lmagan sub-holatdan o'tadi. Hujumchi login so'rovini maxfiy, autentifikatsiyalangan endpoint'ga so'rov bilan birga yuborib, bundan foydalanishi mumkin.
Yashirin ko'p bosqichli ketma-ketliklarni aniqlash uchun quyidagi metodologiya tavsiya etiladi:
Bu race condition'larning eng intuitiv shakli — bir vaqtda bir nechta endpoint'ga so'rov yuborish. Onlayn-do'konlardagi klassik logic kamchilikni o'ylang: savatga mahsulot qo'shib, to'lab, so'ng buyurtma tasdiqlash sahifasiga force-browsing qilishdan oldin yana mahsulot qo'shish. To'lov tekshiruvi va buyurtma tasdiqlash bitta so'rov ichida bajarilsa, to'lov tekshirilgan va buyurtma tasdiqlangan oraliqdagi race windowda savatga yana mahsulot qo'shishingiz mumkin.
Multi-endpoint race condition'larni sinaganda, so'rovlarni bir vaqtda yuborsangiz ham har birining race window'larini tekislashda muammoga duch kelishingiz mumkin. Buning sabablari: tarmoq arxitekturasi kiritgan kechikishlar va endpoint'ga xos qayta ishlash kechikishlari. "Connection warming" — asosiy hujumdan oldin ahamiyatsiz so'rovlar yuborib, keyingi qayta ishlash vaqtlarini silliqlash usuli.
Ba'zan race condition texnikalari o'zi to'qnashuvga sabab bo'lmasa ham, yuqori aniqlikdagi vaqtlashni ta'minlab, vaqtga sezgir hujumlarga imkon beradi. Masalan, ilova xavfsizlik tokenini generatsiya qilishda joriy vaqtni urug' (seed) sifatida ishlatsa, ikki so'rovni bir vaqtda yuborib, ikkalasiga bir xil token yaratishga majbur qilishingiz mumkin.
Ko'p ilovalar obyektlarni bosqichma-bosqich yaratadi — bu esa obyekt vaqtinchalik nomuvofiq holatda bo'ladigan oynani ochishi mumkin. Masalan, foydalanuvchini yaratishda avval yozuv qo'shilib, keyin unga API kaliti beriladi; shu oraliqda obyekt yarim qurilgan holatda bo'ladi. Ba'zan ilovalar ma'lumot kiritilmagan ustunni standart qiymat bilan to'ldiradi — masalan tashqi kiritmasiz null qiymat. Hujumchi bu oynani ekspluatatsiya qilishi mumkin.