Ushbu bo'limda CSRF tokenlari nima ekanini, ular CSRF hujumlaridan qanday himoya qilishini va bu himoyalarni qanday chetlab o'tish mumkinligini tushuntiramiz.
CSRF token — server tomonidan generatsiya qilinadigan va mijoz bilan bo'lishiladigan unikal, maxfiy va taxmin qilib bo'lmaydigan qiymat. Maxfiy amalni (masalan formani yuborish) bajarishda mijoz to'g'ri CSRF tokenini qo'shishi shart, aks holda server so'rovni rad etadi. Tokenni mijoz bilan bo'lishishning keng tarqalgan yo'li — uni HTML formasida yashirin parametr sifatida qo'shish:
<form name="change-email-form" action="/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="example@normal-website.com">
<input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
<button class='button' type='submit'>Update email</button>
</form>To'g'ri joriy qilinganda CSRF tokenlari hujumchiga haqiqiy so'rov qurishni qiyinlashtiradi, chunki hujumchi tokenning to'g'ri qiymatini taxmin qila olmaydi.
CSRF zaifliklari odatda CSRF tokenlarining buzuq tekshiruvi tufayli yuzaga keladi. Quyida hujumchilarga bu himoyalarni chetlab o'tishga imkon beruvchi eng keng tarqalgan muammolarni ko'rib chiqamiz.
Ba'zi ilovalar POST metodida tokenni to'g'ri tekshiradi, lekin GET metodida tekshiruvni o'tkazib yuboradi. Bunday holatda hujumchi tekshiruvni chetlab o'tish uchun GET metodiga o'tishi mumkin:
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLmBa'zi ilovalar token mavjud bo'lganda uni to'g'ri tekshiradi, lekin token butunlay tashlab yuborilsa tekshiruvni o'tkazib yuboradi. Bunday holatda hujumchi tokenni o'z ichiga olgan butun parametrni (nafaqat qiymatini) olib tashlab, tekshiruvni chetlab o'tishi mumkin.
Ba'zi ilovalar token so'rovni yuborayotgan foydalanuvchi bilan bir xil sessiyaga tegishli ekanini tekshirmaydi. Buning o'rniga ilova chiqarilgan tokenlarning global to'plamini saqlaydi va shu to'plamdagi istalgan tokenni qabul qiladi. Bunday holatda hujumchi o'z hisobi bilan login qilib, haqiqiy token oladi va uni CSRF hujumida jabrlanuvchiga uzatadi.
Oldingi zaiflikning bir variantida ba'zi ilovalar CSRF tokenni cookie'ga bog'laydi, lekin sessiyani kuzatuvchi cookie'ga emas. Bu ilova ikki xil freymvork ishlatganda (biri sessiya uchun, biri CSRF himoyasi uchun) osongina yuz beradi:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.comBu holatni ekspluatatsiya qilish qiyinroq, lekin baribir zaif. Agar vebsaytda hujumchiga jabrlanuvchi brauzeriga cookie o'rnatish imkonini beruvchi biror xatti-harakat bo'lsa, hujum mumkin. Hujumchi o'z hisobi bilan login qilib, token va tegishli cookie'ni oladi, cookie o'rnatish xatti-harakati orqali o'z cookie'sini jabrlanuvchi brauzeriga joylab, tokenini jabrlanuvchiga uzatadi.
Yana bir variantda ba'zi ilovalar chiqarilgan tokenlarning server tomonidagi yozuvini saqlamaydi, balki har bir tokenni cookie va so'rov parametrida takrorlaydi. Keyingi so'rov tekshirilganda ilova shunchaki so'rov parametridagi token cookie'dagi qiymatga mos kelishini tekshiradi. Bu ba'zan CSRF'ga qarshi "double submit" himoyasi deb ataladi:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.comBu holatda ham vebsaytda cookie o'rnatish funksiyasi bo'lsa, hujumchi CSRF hujumini amalga oshira oladi. Bu yerda hujumchiga o'zining haqiqiy tokeni ham kerak emas — u shunchaki token o'ylab topadi, cookie o'rnatish orqali uni jabrlanuvchi brauzeriga joylaydi va shu tokenni jabrlanuvchiga uzatadi.