OATH API-ի հիմնական խոցելիությունները
OATH API-ի գլխավոր խոցելիությունը. Ներածություն
Երբ խոսքը վերաբերում է շահագործմանը, API-ները սկսելու լավագույն տեղն են: API մուտքը սովորաբար բաղկացած է երեք մասից. Հաճախորդներին տրված են թոքեններ Լիազորման սերվերի կողմից, որն աշխատում է API-ների կողքին: API-ն հաճախորդից ստանում է մուտքի նշաններ և դրանց հիման վրա կիրառում է հատուկ տիրույթի թույլտվության կանոններ:
Ժամանակակից ծրագրային հավելվածները խոցելի են մի շարք վտանգների նկատմամբ: Շարունակեք արագացնել ամենավերջին շահագործումները և անվտանգության թերությունները. Այս խոցելիության համար հենանիշեր ունենալը կարևոր է կիրառման անվտանգությունն ապահովելու համար նախքան հարձակումը տեղի ունենալը: Երրորդ կողմի հավելվածներն ավելի ու ավելի են հիմնվում OAuth արձանագրության վրա: Այս տեխնոլոգիայի շնորհիվ օգտատերերը կունենան ավելի լավ ընդհանուր օգտագործման փորձ, ինչպես նաև ավելի արագ մուտք և թույլտվություն: Այն կարող է ավելի ապահով լինել, քան սովորական թույլտվությունը, քանի որ օգտվողները պարտավոր չեն բացահայտել իրենց հավատարմագրերը երրորդ կողմի հավելվածի միջոցով՝ տվյալ ռեսուրսից օգտվելու համար: Թեև արձանագրությունն ինքնին ապահով և ապահով է, դրա իրականացման ձևը կարող է ձեզ բաց թողնել հարձակման համար:
API-ների նախագծման և հոսթինգի ժամանակ այս հոդվածը կենտրոնանում է OAuth-ի բնորոշ խոցելիությունների, ինչպես նաև անվտանգության տարբեր մեղմացումների վրա:
Կոտրված օբյեկտի մակարդակի թույլտվություն
Հարձակման հսկայական մակերես կա, եթե թույլտվությունը խախտվում է, քանի որ API-ներն ապահովում են օբյեկտների հասանելիություն: Քանի որ API-ին հասանելի տարրերը պետք է վավերացվեն, դա անհրաժեշտ է: Իրականացնել օբյեկտի մակարդակի թույլտվության ստուգումներ՝ օգտագործելով API gateway: Մուտք պետք է թույլատրվի միայն նրանց, ովքեր ունեն համապատասխան թույլտվության հավատարմագրեր:
Կոտրված օգտվողի նույնականացում
Չլիազորված նշանները հարձակվողների համար API-ներ մուտք գործելու ևս մեկ հաճախակի միջոց են: Նույնականացման համակարգերը կարող են կոտրվել, կամ սխալմամբ բացահայտվել է API բանալին: Նույնականացման նշանները կարող են լինել օգտագործված հաքերների կողմից մուտք ձեռք բերելու համար: Մարդկանց իսկությունը հաստատեք միայն այն դեպքում, եթե նրանց կարելի է վստահել, և օգտագործեք ուժեղ գաղտնաբառեր: OAuth-ի միջոցով դուք կարող եք դուրս գալ միայն API ստեղներից և մուտք ունենալ դեպի ձեր տվյալները: Դուք միշտ պետք է մտածեք, թե ինչպես եք մտնելու և դուրս գալու վայր: OAuth MTLS Sender Constrained Tokens-ը կարող է օգտագործվել Mutual TLS-ի հետ համատեղ՝ երաշխավորելու, որ հաճախորդները սխալ վարքագիծ չեն դրսևորեն և նշաններ չեն փոխանցի սխալ կողմին՝ այլ մեքենաներ մուտք գործելիս:
API-ի առաջխաղացում.
Տվյալների չափազանց մեծ ազդեցություն
Հրապարակվող վերջնակետերի քանակի սահմանափակումներ չկան: Շատ ժամանակ ոչ բոլոր հնարավորություններն են հասանելի բոլոր օգտատերերին: Բացահայտելով ավելի շատ տվյալներ, քան անհրաժեշտ է, դուք վտանգի տակ եք դնում ձեզ և ուրիշներին: Խուսափեք զգայունության բացահայտումից տեղեկություն քանի դեռ դա բացարձակապես անհրաժեշտ է: Մշակողները կարող են նշել, թե ով ինչ մուտք ունի՝ օգտագործելով OAuth Scopes-ը և Claims-ը: Հայցերը կարող են սահմանել, թե օգտվողի տվյալների որ բաժինները հասանելի են: Մուտքի վերահսկումը կարող է դառնալ ավելի պարզ և հեշտ կառավարելի՝ օգտագործելով ստանդարտ կառուցվածք բոլոր API-ներում:
Ռեսուրսների բացակայություն և տոկոսադրույքի սահմանափակում
Սև գլխարկները հաճախ օգտագործում են ծառայության մերժման (DoS) հարձակումները՝ որպես սերվերը ճնշելու և դրա գործարկման ժամանակը զրոյի հասցնելու կոպիտ միջոց: Առանց ռեսուրսների սահմանափակումների, որոնք կարող են կոչվել, API-ն խոցելի է թուլացնող հարձակման համար: «Օգտագործելով API gateway կամ կառավարման գործիք, դուք կարող եք սահմանել սակագների սահմանափակումներ API-ների համար: Զտումը և էջադրումը պետք է ներառվեն, ինչպես նաև սահմանափակվեն պատասխանները:
Անվտանգության համակարգի սխալ կազմաձևում
Անվտանգության կազմաձևման տարբեր ուղեցույցներ բավականին համապարփակ են՝ անվտանգության սխալ կազմաձևման զգալի հավանականության պատճառով: Մի շարք փոքր բաներ կարող են վտանգել ձեր հարթակի անվտանգությունը: Հնարավոր է, որ հետին նպատակներով սև գլխարկները կարող են հայտնաբերել զգայուն տեղեկատվություն, որն ուղարկվել է ի պատասխան սխալ հարցումների:
Զանգվածային հանձնարարություն
Պարզապես այն պատճառով, որ վերջնական կետը հրապարակայնորեն սահմանված չէ, չի նշանակում, որ այն չի կարող մուտք գործել մշակողների կողմից: Գաղտնի API-ն կարող է հեշտությամբ կալանավորվել և հակադարձ նախագծվել հաքերների կողմից: Նայեք այս հիմնական օրինակին, որն օգտագործում է բաց Bearer Token «մասնավոր» API-ում: Մյուս կողմից, հանրային փաստաթղթերը կարող են գոյություն ունենալ մի բանի համար, որը նախատեսված է բացառապես անձնական օգտագործման համար: Բացահայտված տեղեկատվությունը կարող է օգտագործվել սև գլխարկների կողմից ոչ միայն կարդալու, այլև օբյեկտների բնութագրերը շահարկելու համար: Համարեք ձեզ հաքեր, երբ որոնում եք ձեր պաշտպանական միջոցների հնարավոր թույլ կետերը: Թույլ տվեք միայն պատշաճ իրավունքներ ունեցողներին մուտք ունենալ վերադարձվածին: Խոցելիությունը նվազագույնի հասցնելու համար սահմանափակեք API-ի պատասխանների փաթեթը: Հարցվողները չպետք է ավելացնեն որևէ հղում, որը բացարձակապես պարտադիր չէ:
Խթանված API՝
Ակտիվների ոչ պատշաճ կառավարում
Բացի մշակողների արտադրողականության բարձրացումից, ընթացիկ տարբերակները և փաստաթղթերը կարևոր են ձեր սեփական անվտանգության համար: Նախապես պատրաստվեք նոր տարբերակների ներդրմանը և հին API-ների հնացմանը: Օգտագործեք ավելի նոր API-ներ՝ թույլ չտալու, որ ավելի հինները մնան օգտագործման մեջ: API-ի ճշգրտումը կարող է օգտագործվել որպես փաստաթղթավորման ճշմարտության հիմնական աղբյուր:
Ներարկում
API-ները խոցելի են ներարկման համար, բայց նաև երրորդ կողմի մշակողների հավելվածները: Վնասակար կոդը կարող է օգտագործվել տվյալները ջնջելու կամ գաղտնի տեղեկությունները գողանալու համար, ինչպիսիք են գաղտնաբառերը և վարկային քարտերի համարները: Ամենակարևոր դասը, որը պետք է վերցնել դրանից, լռելյայն կարգավորումներից կախված չլինելն է: Ձեր ղեկավարությունը կամ դարպասի մատակարարը պետք է կարողանա բավարարել ձեր եզակի հավելվածի կարիքները: Սխալների հաղորդագրությունները չպետք է պարունակեն զգայուն տեղեկատվություն: Ինքնության տվյալների արտահոսքը համակարգից դուրս կանխելու համար Pairwise կեղծանունները պետք է օգտագործվեն նշաններում: Սա երաշխավորում է, որ ոչ մի հաճախորդ չի կարող միասին աշխատել՝ օգտատիրոջը նույնականացնելու համար:
Անբավարար գրանցում և մոնիտորինգ
Երբ հարձակումն իսկապես տեղի է ունենում, թիմերը պահանջում են լավ մտածված արձագանքման ռազմավարություն: Մշակողները կշարունակեն շահագործել խոցելիությունը՝ առանց բռնվելու, եթե չկան հուսալի անտառահատումների և մոնիտորինգի համակարգ, ինչը կմեծացնի կորուստները և կվնասի հասարակության ընկալմանը ընկերության մասին: Ընդունեք խիստ API մոնիտորինգի և արտադրության վերջնական կետի փորձարկման ռազմավարություն: Սպիտակ գլխարկների փորձարկողները, ովքեր վաղ հայտնաբերում են խոցելիությունը, պետք է պարգևատրվեն պարգևատրման սխեմայով: Գրանցամատյանի հետքը կարող է բարելավվել՝ ներառելով օգտվողի ինքնությունը API գործարքների մեջ: Համոզվեք, որ ձեր API-ի ճարտարապետության բոլոր շերտերը ստուգվում են՝ օգտագործելով Access Token-ի տվյալները:
Եզրափակում
Պլատֆորմի ճարտարապետները կարող են սարքավորել իրենց համակարգերը՝ հարձակվողներից մեկ քայլ առաջ պահելու համար՝ հետևելով խոցելիության սահմանված չափանիշներին: Քանի որ API-ները կարող են ապահովել Անձնական նույնականացման տեղեկատվության (PII) հասանելիություն, նման ծառայությունների անվտանգության պահպանումը կարևոր է ինչպես ընկերության կայունության, այնպես էլ օրենսդրությանը համապատասխանելու համար, ինչպիսին է GDPR-ը: Երբեք մի ուղարկեք OAuth նշանները անմիջապես API-ի վրա՝ առանց API Gateway-ի և Phantom Token Approach-ի օգտագործման:
Խթանված API՝
