Ծրագրային ապահովման անվտանգության ամենակարևոր գաղափարներից մեկը սա է․ ապացուցել, թե օգտատերը ով է, նույնը չէ, ինչ որոշել՝ նա ինչ կարող է անել։
Այս տարբերությունը պարզ է հնչում, բայց շատ լուրջ անվտանգության սխալներ լինում են հենց այն պատճառով, որ համակարգը ճիշտ անում է authentication-ը և հետո ենթադրում է, թե authorization-ն էլ ինքնաբերաբար ապահով է։
Այդպես չէ։
Հիմնական տարբերությունը
- Authentication-ը պատասխանում է՝ Ո՞վ ես դու։
- Authorization-ը պատասխանում է՝ Ի՞նչ իրավունք ունես անել։
Եթե օգտատերը հաջողությամբ մուտք է գործում, authentication-ը հաջողվել է։ Բայց դա չի նշանակում, որ նա պետք է կարողանա տեսնել բոլոր հաշիվները, փոփոխել բոլոր ռեսուրսները, ներբեռնել բոլոր ֆայլերը կամ կանչել բոլոր admin endpoint-ները։
Պարզ իրական օրինակ
Պատկերացրեք mobile banking app։
Դուք մուտք եք գործում email-ով, գաղտնաբառով և OTP-ով։ Դա authentication է։
Հետո փորձում եք բացել հաշվի տվյալները endpoint-ով՝ օգտագործելով մեկ ուրիշ հաճախորդի account ID-ն։ Կանգնեցնո՞ւմ է ձեզ համակարգը, թե՞ ոչ՝ դա authorization-ի հարց է։
Եթե backend-ը ստուգում է միայն՝ «Օգտատերը մուտք գործա՞ծ է», բայց մոռանում է ստուգել՝ «Այս մուտք գործած օգտատե՞րն է այս հաշվի տերը», ապա համակարգում կա իրական անվտանգության խոցելիություն։
Ահա թե ինչու շատ վտանգավոր bug-երը կապված չեն կոտրված login screen-ի հետ։ Դրանք կապված են login-ից հետո բաց թողնված permission check-երի հետ։
Ինչու սա այսքան կարևոր է կայքերում և mobile app-երում
- Մուտք գործած օգտատերերն էլ կարող են սպառնալիք լինել այլ օգտատերերի տվյալների համար։ Authentication-ը դեռ չի նշանակում, որ ամեն գործողություն անվտանգ է։
- API-ները հեշտ է փորձարկել։ Հարձակվողները կարող են փոխել ID-ները, parameter-ները և request-երը։
- Frontend-ի կանոնները բավարար չեն։ UI-ում կոճակը թաքցնելը backend endpoint-ը չի պաշտպանում։
- Mobile app-ը վստահելի client չէ։ Backend-ը պետք է ինքը enforce անի permissions-ը։
Թաքնված վտանգն այն է, որ թիմերը հաճախ լավ են պաշտպանում login flow-ը, բայց բավարար չեն պաշտպանում login-ից հետո կատարվող գործողությունները։
Authorization-ի սխալների տարածված օրինակներ
- օգտատերը կարող է կարդալ մեկ ուրիշի պրոֆիլը՝ URL-ում ID փոխելով
- հաճախորդը կարող է տեսնել ուրիշ հաճախորդի invoice-ը կամ document-ը
- սովորական օգտատերը կարող է կանչել admin-only API route
- mobile app-ը տեսողականորեն թաքցնում է admin feature-ը, բայց endpoint-ը դեռ աշխատում է, եթե ուղիղ կանչվի
- օգտատերը կարող է update կամ delete անել ռեսուրս, որը իրենը չէ
Այս խնդիրները հաճախ կոչվում են access control failure-ներ, և դրանք իրական արտադրանքներում ամենավնասակար bug-երից են։
Ինչու ծրագրավորողները պատահմամբ այս սխալն են անում
- ենթադրում են, որ «logged in» լինելը բավարար է
- վստահում են frontend-ին, որ այն կսահմանափակի գործողությունները
- որոշ endpoint-ներում ստուգում են role-երը, բայց մոռանում են object ownership-ը
- ֆիչերները արագ են կառուցում և permission check-երը ավելացնում են անհետևողականորեն
- ավելի շատ թեստավորում են happy path-ը, քան hostile path-ը
Այսինքն՝ bug-ը հաճախ գալիս է ոչ թե վատ մտադրությունից, այլ ոչ ամբողջական մտածելակերպից։
Ինչպես է պետք ճիշտ մտածել
Ամեն զգայուն գործողության համար backend-ը պետք է տա այսպիսի հարցեր՝
- Օգտատերը authentication անցե՞լ է։
- Այս օգտատերն ունի՞ պահանջվող role-ը։
- Այս օգտատե՞րն է այս կոնկրետ resource-ի տերը։
- Այս state-ում այս գործողությունը թույլատրելի՞ է։
- Այս տվյալն ընդհանրապես պե՞տք է տեսանելի լինի այս օգտատիրոջ համար։
Սա է իրական authorization-ը։ Դա մեկ մեծ yes/no switch չէ։ Դա action-ին և resource-ին կապված ստուգումների շարք է։
Թաքնված դասը․ անվտանգությունը հաճախ ապրում է «ձանձրալի» ստուգումների մեջ
Մարդիկ հաճախ պատկերացնում են app security-ը որպես encryption, token-ներ կամ advanced attack defense։ Դրանք կարևոր են։ Բայց շատ իրական breach-եր լինում են ավելի սովորական բանի պատճառով՝ սովորական endpoint-ում բաց թողնված permission check-ի։
Հենց դրա համար ուժեղ թիմերը authorization-ին վերաբերվում են որպես product rule, ոչ թե միայն տեխնիկական մանրուք։ Հարցը միայն «Կարո՞ղ է օգտատերը մուտք գործել» չէ։ Հարցն է նաև՝ «Մուտք գործելուց հետո կոնկրետ ինչի՞ պետք է նա կարողանա դիպչել»։
Տարածված վտանգավոր հավատքը
Տարածված միտքն է՝ «UI-ն այդ feature-ը չի ցույց տալիս, այսինքն՝ օգտատերը չի կարող մուտք գործել դրան»։
Դա վտանգավոր մտածելակերպ է։ Հարձակվողներին ձեր կոճակները պետք չեն։ Նրանք կարող են ուղիղ կանչել API-ները, փոխել request-երը և փորձարկել endpoint-ները՝ առանց նորմալ ինտերֆեյսից օգտվելու։
Եզրակացություն
Authentication-ը ապացուցում է անձը։ Authorization-ը վերահսկում է ուժը։ Անվտանգ արտադրանքին երկուսն էլ պետք են։ Եթե ձեր կայքը կամ mobile app-ը ստուգում է միայն՝ ով է օգտատերը, բայց ոչ՝ ինչի է նա իրավունք ստանալու կամ փոփոխելու, ապա շատ լուրջ անվտանգության խոցելիություն կարող է թաքնված լինել նույնիսկ կատարյալ աշխատող login flow-ի հետևում։