Vebda ijtimoiy tarmoq hisobingiz bilan kirishga imkon beradigan saytlarni ko'p uchratgansiz — bu funksiya odatda mashhur OAuth 2.0 freymvorkida qurilgan. OAuth 2.0 hujumchilar uchun juda qiziq, chunki u ham nihoyatda keng tarqalgan, ham tabiatan joriy qilish xatolariga moyil. Bu hujumchilarga maxfiy foydalanuvchi ma'lumotini olish va hatto autentifikatsiyani butunlay chetlab o'tishga imkon beruvchi zaifliklarga olib kelishi mumkin.
OAuth — keng ishlatiladigan avtorizatsiya freymvorki bo'lib, saytlar va ilovalarga foydalanuvchining boshqa ilovadagi hisobiga cheklangan kirishni so'rashga imkon beradi. Muhimi: OAuth foydalanuvchiga bu kirishni o'z login ma'lumotlarini so'rovchi ilovaga oshkor qilmasdan berishga imkon beradi. Ya'ni foydalanuvchi qaysi ma'lumotni bo'lishishni aniq sozlaydi, hisobini to'liq uchinchi tomonga topshirmaydi.
OAuth 2.0 joriy standart bo'lsa-da, ba'zi saytlar hali eski 1a versiyasidan foydalanadi. Bu materiallarda "OAuth" faqat OAuth 2.0 ni bildiradi.
OAuth 2.0 uch tomon o'rtasidagi o'zaro ta'sirlar orqali ishlaydi:
OAuth jarayoni turlicha amalga oshiriladi — bular "flow" yoki "grant type" deb ataladi. Eng keng tarqalganlari — "authorization code" va "implicit". Umuman, ikkalasi ham quyidagi bosqichlarni o'z ichiga oladi: client ilova foydalanuvchi ma'lumotining bir qismiga kirishni so'raydi; foydalanuvchi OAuth xizmatiga login qilib, ruxsat beradi; client ilova access token oladi; client ilova bu token bilan resource serverdan ma'lumot oladi.
Dastlab bu maqsad uchun mo'ljallanmagan bo'lsa-da, OAuth foydalanuvchilarni autentifikatsiya qilish vositasiga aylandi. Odatda quyidagicha ishlaydi: foydalanuvchi ijtimoiy tarmoq hisobi bilan kirishni tanlaydi; client ilova ijtimoiy tarmoq OAuth xizmatidan foydalanuvchini aniqlaydigan ma'lumotni (masalan email) so'raydi; access token olgach, bu ma'lumotni resource serverdan (odatda /userinfo endpointdan) oladi; keyin uni username o'rniga ishlatib, foydalanuvchini login qiladi.
OAuth zaifliklari qisman spetsifikatsiyaning nisbatan noaniq va moslashuvchan ekani sabab yuzaga keladi. Har bir grant type uchun bir nechta majburiy komponent bo'lsa-da, joriy qilishning katta qismi ixtiyoriy — jumladan foydalanuvchi ma'lumotini xavfsiz saqlash uchun zarur ko'p sozlamalar. Xavfsizlik deyarli butunlay dasturchilar to'g'ri sozlamalar kombinatsiyasini ishlatishiga va o'z choralarini (mustahkam input validation) qo'shishiga tayanadi.
Boshqa saytdagi hisob bilan kirish opsiyasi ko'rinsa, bu OAuth ishlatilayotganining kuchli belgisi. Eng ishonchli yo'l — trafikni Burp orqali o'tkazib, HTTP xabarlarini tekshirish. Grant type'dan qat'i nazar, birinchi so'rov doim /authorization endpointga bo'lib, client_id, redirect_uri, response_type parametrlarini o'z ichiga oladi:
GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.comAuthorization server hostname'ini bilgach, quyidagi standart endpointlarga GET yuboring — ular ko'pincha kalit ma'lumotli JSON konfiguratsiya faylini qaytaradi: /.well-known/oauth-authorization-server va /.well-known/openid-configuration.
Implicit flow'da access token OAuth xizmatidan client ilovaga foydalanuvchi brauzeri orqali URL fragment sifatida yuboriladi. Sessiyani saqlash uchun client ilova bu ma'lumotni (odatda user ID va access token) POST so'rovda serverga yuborib, foydalanuvchiga sessiya cookie beradi. Biroq bu holatda server solishtiradigan maxfiy narsa yo'q — ma'lumotga yashirincha ishoniladi. Agar client ilova access token so'rovdagi boshqa ma'lumotga mos kelishini tekshirmasa, hujumchi serverga yuborilgan parametrlarni o'zgartirib, istalgan foydalanuvchi qiyofasiga kirishi mumkin.
OAuth flow'ining ko'p komponenti ixtiyoriy bo'lsa-da, ba'zilari qat'iy tavsiya etiladi — masalan state parametri. U taxmin qilib bo'lmaydigan qiymatga (foydalanuvchi sessiyasiga bog'liq hash) ega bo'lishi va client ilova uchun CSRF token vazifasini o'tashi kerak. Agar authorization so'rovi state yubormasa, hujumchi OAuth flow'ni o'zi boshlab, so'ng jabrlanuvchi brauzerini uni yakunlashga aldashi mumkin — bu client ilovadagi jabrlanuvchi hisobini hujumchi ijtimoiy tarmog'iga bog'lab egallashga olib kelishi mumkin.
Eng mashhur OAuth zaifligi — OAuth xizmati konfiguratsiyasi hujumchilarga boshqa foydalanuvchilarning code yoki tokenini o'g'irlashga imkon berganda. Grant type'ga qarab code yoki token jabrlanuvchi brauzeri orqali redirect_uri parametridagi /callback endpointga yuboriladi. Agar OAuth xizmati bu URI'ni to'g'ri tekshirmasa, hujumchi CSRF-ga o'xshash hujum qurib, code yoki tokenni hujumchi boshqaradigan redirect_uri ga yuboriladigan qilishi mumkin.
Client ilovalar OAuth xizmatida ro'yxatdan o'tganda haqiqiy callback URI'lar oq ro'yxatini berishi eng yaxshi amaliyot. Biroq bu tekshiruvni chetlab o'tish yo'llari bo'lishi mumkin. redirect_uri parametri bilan tajriba qiling: qo'shimcha yo'llar/parametrlar qo'shing; URI tahlilidagi nomuvofiqliklardan foydalaning; dublikat redirect_uri yuboring; localhost bilan boshlanadigan domenlarni sinang (masalan localhost.evil-user.net).
Mustahkamroq nishonlarda tashqi domenni redirect_uri sifatida yubora olmasangiz ham, oq ro'yxatdagi domendagi boshqa sahifalarga ishora qila olishingiz mumkin. Directory traversal bilan domendagi ixtiyoriy yo'lni berish mumkin. So'ng o'sha sahifalarni code/tokenni sizdirish uchun ekspluatatsiya qiling — eng foydalisi open redirect (jabrlanuvchini token bilan hujumchi domeniga yo'naltirish uchun proxy sifatida).
Har qanday OAuth flow'da foydalanuvchi authorization so'rovidagi scope asosida kirishni tasdiqlaydi. Ba'zan hujumchi OAuth xizmatining buzuq tekshiruvi tufayli tokenni qo'shimcha ruxsatlar bilan "yangilashi" (upgrade) mumkin — authorization code flow'da code/token almashinuvi so'roviga qo'shimcha scope qo'shib, yoki implicit flow'da /userinfo so'roviga yangi scope qo'shib.
OpenID Connect OAuth protokolini kengaytirib, asosiy OAuth ustida turadigan autentifikatsiya qatlamini qo'shadi. Batafsil: OpenID Connect.