
Ինչու ծրագրավորողները դեռ չեն հասկանում CORS. դասեր Zoom-ի localhost խոցելիությունից
Խորհրդատու Քրիս Ֆոսթերի 2019 թվականի հոդվածը Zoom-ի localhost խոցելիության օրինակով ցույց է տալիս, թե ինչպես է CORS-ի չհասկանալը ստեղծում իրական անվտանգության խնդիրներ և ինչպիսին պետք է լինի ճիշտ լուծումը։
Full-stack ծրագրավորման խորհրդատու Քրիս Ֆոսթերի 2019 թվականին գրված և ծրագրավորողների շրջանում մինչ օրս շրջանառվող հոդվածը պնդում է, որ չափազանց շատ վեբ ծրագրավորողներ չեն հասկանում Cross-Origin Resource Sharing (CORS) մեխանիզմը, և այդ թյուր ընկալումն իրական անվտանգության հետևանքներ է ունենում։ Որպես օրինակ նա վերցնում է Zoom-ի աշխատասեղանային հաճախորդի localhost խոցելիությունը, որը 2019 թվականի հուլիսին հրապարակել է անվտանգության հետազոտող Ջոնաթան Լայչուխը։
Zoom-ի localhost թակարդը
Zoom-ի հաճախորդը համակարգչում տեղադրում էր վեբ սերվեր, որը լսում էր http://localhost:19421 հասցեն։ Երբ օգտատերը բացում էր Zoom-ի հղում, zoom.us կայքը հարցում էր ուղարկում այդ տեղական սերվերին՝ հանձնարարելով բացել բնիկ հավելվածը։ Սովորական AJAX հարցման փոխարեն էջը պատկեր էր բեռնում տեղական վեբ սերվերից, և պատկերի չափերը կոդավորում էին սերվերի կարգավիճակի կամ սխալի կոդը։ Իր հրապարակման մեջ Լայչուխը ենթադրեց, որ դա արվել է CORS-ը շրջանցելու համար, քանի որ, իր խոսքով, զննարկիչները լիովին անտեսում են CORS քաղաքականությունը localhost-ում աշխատող սերվերների համար։
Ֆոսթերը նշում է, որ այդ պնդումը սխալ է. Chrome-ը հարգում է CORS վերնագրերը նաև տեղական վեբ սերվերների համար, իսկ localhost-ին ուղղված խաչաձև հարցումները աջակցվում են բոլոր զննարկիչներում. ծրագրավորողները դա անում են անընդհատ, երբ Create React App-ի ճակատային մասը աշխատում է մի պորտում, իսկ API-ն՝ մյուսում։ Նրա կարծիքով պատկերի հնարքը նշանակում է, որ Zoom-ը կա՛մ չէր հասկանում CORS-ը, կա՛մ գիտակցաբար շրջանցում էր այն. գինը բարձր ստացվեց. բնիկ հավելվածում գործողություններ սկսել և պատասխանը կարդալ կարող էր ոչ միայն zoom.us-ը, այլև համացանցի ցանկացած այլ կայք։
Ինչպիսին կլիներ անվտանգ լուծումը
Տեղական վեբ սերվերը պետք է տրամադրեր REST API և ուղարկեր Access-Control-Allow-Origin վերնագիր https://zoom.us արժեքով, որպեսզի նրա հետ խոսել կարողանար միայն zoom.us դոմենում աշխատող JavaScript-ը։ Բացի այդ, zoom.us-ը պետք է ուղարկեր Content Security Policy վերնագիր, որն արգելում է iframe-ում ցուցադրումը, որպեսզի էջերը չկարողանան լուռ բացել հանդիպումներ ֆոնում։ Այնուամենայնիվ մնում է նաև, որ ցանկացած էջ կարող է զննարկիչը վերահղել zoom.us հղմանը՝ չսպասված հանդիպման համար։ Ֆոսթերը դա դասում է ոչ թե անվտանգության խոցելիության, այլ օգտատիրական փորձի որոշումների շարքին և համաձայն չէ դրա հետ. ծրագրաշարը պետք է կանխատեսելի լինի, իսկ հղման վրա սեղմելը չպետք է ձեր տեսախցիկն ու խոսափողը հասանելի դարձնի անծանոթներին։
Ինչու շփոթմունքը չի վերանում
Խնդիրը չի սահմանափակվում Zoom-ով. այլ ընկերություններ նույնպես բռնվել են նույն խոցելիությամբ, իսկ Stack Overflow-ը լի է CORS-ի մասին հարցերով, որոնց կողքին հաճախ անվտանգ չեն լռելյայն կարգավորումներ. օրինակ՝ enable-cors.org-ում հրապարակված Express-ի օրինակը, որը բառացի պատճենելու դեպքում հավելվածը դարձնում է խոցելի։ Տեխնիկական արդարացումները նույնպես չեն դիմանում. Firefox-ը կարող է արգելափակել որոշ հարցումներ ապահով աղբյուրից ոչ ապահով աղբյուր, սակայն localhost-ին աջակցում է, իսկ բնիկ հավելվածները կարող են ստեղծել ինքնաստորագրված վկայական։ Նույն աղբյուրի քաղաքականության շրջանցումը կարող է ստիպել կոդը աշխատել, ամփոփում է հեղինակը, սակայն ավելի ուշ խնդիրներ է ստեղծում. և մինչ օրս պարզ չէ՝ CORS-ը չափազանց բարդ API է, թե պարզապես ծրագրավորողների կրթությունը բավարար չէ։
SiTech — AI-ով հզորացված վեբ մշակում
Ստեղծում ենք արագ ու ժամանակակից կայքեր և AI-ը ներդնում իրական բիզնես գործընթացներում։ Ունե՞ք նախագիծ կամ հարց։ Ուրախ կլինենք օգնել։