CORS Սխալ կազմաձևում. Չափազանց թույլատրելի քաղաքականության ռիսկերը

Ազդեցություն

Հարձակվողը կարող է գողանալ զգայուն, վավերացված տվյալներ [S2] խոցելի հավելվածի օգտատերերից: Եթե ​​օգտատերը այցելում է վնասակար կայք, երբ մուտք է գործել խոցելի հավելված, ապա վնասակար կայքը կարող է խաչաձեւ ծագման հարցումներ կատարել հավելվածի API-ին և կարդալ պատասխանները [S1][S2]: Սա կարող է հանգեցնել անձնական տեղեկատվության հափշտակման, ներառյալ օգտվողի պրոֆիլները, CSRF նշանները կամ անձնական հաղորդագրությունները [S2]:

Արմատային պատճառ

CORS-ը HTTP վերնագրերի վրա հիմնված մեխանիզմ է, որը թույլ է տալիս սերվերներին նշել, թե որ սկզբնաղբյուրները (տիրույթ, սխեման կամ նավահանգիստ) են թույլատրվում բեռնել [S1] ռեսուրսները: Խոցելիությունը սովորաբար առաջանում է, երբ սերվերի CORS քաղաքականությունը չափազանց ճկուն է կամ վատ է իրականացվում [S2]:

• արտացոլված ծագման վերնագիր. Որոշ սերվերներ կարդում են Origin վերնագիրը հաճախորդի հարցումից և կրկնում այն Access-Control-Allow-Origin (ACAO) պատասխանի վերնագրում [S2]: Սա արդյունավետորեն թույլ է տալիս ցանկացած կայքի մուտք գործել [S2] ռեսուրս:
• Սխալ կազմաձևված Wildcards. Թեև * նիշը թույլ է տալիս ցանկացած ծագման մուտք գործել ռեսուրս, այն չի կարող օգտագործվել հավատարմագրեր պահանջող հարցումների համար (օրինակ՝ թխուկներ կամ Թույլտվության վերնագրեր) [S3]: Մշակողները հաճախ փորձում են շրջանցել դա՝ դինամիկ կերպով ստեղծելով ACAO վերնագիրը՝ հիմնված [S2] հարցման վրա:
• Սպիտակ ցուցակում «null»: Որոշ հավելվածներ սպիտակ ցուցակում են null սկզբնաղբյուրը, որը կարող է գործարկվել վերահղված հարցումների կամ տեղական ֆայլերի միջոցով, ինչը թույլ է տալիս վնասակար կայքերին դիմակայել որպես null սկզբնաղբյուր՝ մուտք ստանալու համար: [S2][S3].
• Վերլուծման սխալներ. Origin վերնագրի վավերացման ժամանակ ռեգեքսի կամ տողերի համընկնման սխալները կարող են թույլ տալ հարձակվողներին օգտագործել այնպիսի տիրույթներ, ինչպիսիք են trusted-domain.com.attacker.com [S2]:

Կարևոր է նշել, որ CORS-ը պաշտպանություն չէ միջկայքային հարցումների կեղծումից (CSRF) [S2]-ից:

Բետոնե ամրացումներ

• Օգտագործեք ստատիկ սպիտակ ցուցակ. Խուսափեք Access-Control-Allow-Origin վերնագրի դինամիկ ձևավորումից հարցման Origin վերնագրից [S2]: Փոխարենը, համեմատեք հարցման ծագումը [S3] վստահելի տիրույթների կոշտ կոդավորված ցանկի հետ:
• Խուսափեք «զրոյական» ծագումից. Երբեք մի ներառեք null-ն ձեր [S2] թույլատրելի ծագման սպիտակ ցուցակում:
• Սահմանափակել հավատարմագրերը. Սահմանել Access-Control-Allow-Credentials: true միայն այն դեպքում, եթե բացարձակապես անհրաժեշտ է կոնկրետ խաչաձեւ ծագման փոխազդեցության համար [S3]:
• Օգտագործեք պատշաճ վավերացում. Եթե դուք պետք է աջակցեք մի քանի ծագման, համոզվեք, որ Origin վերնագրի վավերացման տրամաբանությունը ամուր է և չի կարող շրջանցվել ենթադոմեյնների կամ նմանատիպ տեսք ունեցող [S2] տիրույթների կողմից:

Ինչպես է FixVibe-ն փորձարկում դրա համար

FixVibe-ն այժմ ներառում է սա որպես փակ ակտիվ ստուգում: Դոմենի ստուգումից հետո active.cors-ն ուղարկում է նույն ծագման API հարցումներ՝ սինթետիկ հարձակվողի ծագմամբ և վերանայում CORS պատասխանի վերնագրերը: Այն արտացոլում է կամայական ծագում, նիշերի հավատարմագրում CORS և լայն բաց CORS ոչ հրապարակային API վերջնակետերում՝ խուսափելով հանրային ակտիվների աղմուկից: