Ադմին ենթադոմեյնը չի կանգնեցնում CSRF-ը. չորս ստուգում մեկնարկից առաջ

Ադմին ինտերֆեյսը admin.example.com տեղափոխելը իրական բարելավում է. այն ադմին քուքիները հեռու է պահում հանրային էջերից, երկու հավելվածներին առանձին քեշ է տալիս և թույլ է տալիս ավելի խիստ ցանցային քաղաքականություն ուղղել մեկ հոսթանվան։ Բայց դա CSRF վերահսկողություն չէ և հանրային կայքի կոդը անվտանգ չի դարձնում մուտք գործած ադմինիստրատորի առջև բաց թողնելու համար։ Անջատումը փոխում է այն, ինչ բրաուզերը սահման է համարում, ոչ այն, ինչ սերվերը ստուգում է, ուստի նախքան ավարտված համարելը կատարեք այս չորս ստուգումները։

Կարդացեք ծագումը և կայքը որպես երկու տարբեր բառ

Ծագումը սխեման է, հոսթը և պորտը, ուստի https://www.example.com-ը և https://admin.example.com-ը տարբեր ծագումներ են։ Կայքը SameSite իմաստով սխեման գումարած գրանցելի դոմեյնն է, ուստի այդ երկու հոսթանունները սովորաբար նույն կայքն են։ Այդ տարբերությունը ողջ թակարդն է. SameSite հատկանիշը չի օգնի քույր ենթադոմեյնների միջև, որովհետև բրաուզերը հարցումը բոլորովին կայք-անցում չի համարում։ Ուղղեք ադմին ինտերֆեյսը իսկապես այլ գրանցելի դոմեյնի, օրինակ admin-example.net-ի, և հարցումը իսկապես դառնում է կայք-անցում, և հենց այնտեղ SameSite=Lax կամ Strict-ը սկսում է անել աշխատանք, որի վրա կարելի է հույս դնել։

Փորձարկեք այն բրաուզերում, ոչ թե դատողություններ արեք դրա մասին։

Բեռնեք հանրային կայքը, բացեք ծրագրավորողի գործիքները և տեսեք, թե որ քուքիներն է բրաուզերը կցում ադմին հոսթին ուղղված հարցմանը։ Եթե քուքին Domain հատկանիշ չունի, այն միայն հոսթի համար է և մնում է իր անվան վրա. եթե կրում է Domain=example.com, այն գնում է յուրաքանչյուր քրոջ մոտ, և նոր ենթադոմեյնը այդ քուքիի համար ձեզ ոչինչ չտվեց։

Առանձնացրեք պատասխանը կարդալը հարցումն ուղարկելուց

Նույն ծագման քաղաքականությունը սահմանափակում է պատասխանների ընթերցումը ծագումների միջև։ Այն չի կանգնեցնում հարցման ուղարկումը և չի խանգարում, որ ձևը կրի հավատարմագրեր, որոնք բրաուզերն արդեն ունի։ Պարզ հարցումը՝ ձևի բովանդակության տեսակով կամ սովորական GET-ով, հասցվում է առանց նախնական ստուգման. հետո CORS-ը որոշում է, թե արդյոք կանչող սկրիպտը կարող է կարդալ պատասխանը։ CSRF-ը ամբողջությամբ ապրում է ուղարկելու կողմում։

Դրա համար սերվերին պետք է բացահայտ ստուգում վիճակը փոփոխող գործողությունների համար։ Սեսիային կապված սինխրոնացման թոքենը կամ սերվերի վրա համեմատվող կրկնակի ուղարկման քուքին ծածկում է այդ դեպքը. Origin կամ Referer համեմատությունը արժե ավելացնել որպես երկրորդ դարպաս, բայց ոչ որպես միակը, որովհետև ոչ ամեն հարցում է կրում վերնագիրը և ոչ ամեն պրոքսի է պահում այն։ OWASP-ի CSRF-ի կանխարգելման ուղեցույցը SameSite-ը համարում է մի շերտ մի քանիսի մեջ հենց այդ պատճառով։

Որոշեք, թե ցանցային դարպասն իրականում ինչ է ապացուցում

Ադմին հոսթի առջև VPN ելքերի թույլատրելի ցանկը լավ վերահսկողություն է և թույլ ինքնության պահանջ։ Այն ապացուցում է, որ հարցումը եկել է VPN-ի տված հասցեից, որը կարող են կիսել այդ ելքի բոլորը, և ոչինչ չի ասում, թե ով կամ ինչ սարք է դրա հետևում։ Վերաբերվեք դրան որպես մուտքի զտիչ, ոչ որպես նույնականացում։

Պահեք այն անկախ հարցման մակարդակի ստուգումներից։ Եթե ցանկը միակ բանն է հարձակվողի և վիճակը փոփոխող վերջնակետի միջև, մեկ սխալ կարգավորված երթուղին, մեկ split-tunnel հաճախորդը կամ մեկ փոխառված նոթբուքը ամբողջությամբ հեռացնում է վերահսկողությունը։

Գրանցեք նաև սպասվող միջակայքերից դուրս մերժումները։ Դրանց պոռթկումը ամենաօգտակար ազդանշանն է, որ ինչ-որ մեկը հետազոտում է ձեր նոր կառուցած սահմանը, իսկ լռությունը ազդանշան է, որ զտիչը բոլորովին չի հասնում։

Պահեք քուքիները, մուտքը և լիազորումը բացահայտ

Քուքիի շրջանակը որոշում է արդյունքի մեծ մասը։ Ծնող դոմեյնի քուքին ուղարկվում է ադմին հոսթին, ուստի հանրային կայքում սկրիպտի ներարկումը կարող է գործել ադմինիստրատորի սեսիայով. միայն հոսթի քուքին չի կարող։ Նախընտրեք միայն հոսթի ձևը, ավելացրեք Secure հատկանիշը և օգտագործեք __Host- նախածանցը, որտեղ հարթակը սատարում է, որովհետև այդ նախածանցը պահանջում է Secure, Path=/ և առանց Domain հատկանիշի։ Կարդացեք պատասխանի վերնագիրը, ոչ թե քուքիների ամանը. Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, առանց Domain հատկանիշի։ Բրաուզերը դեն է նետում Domain կրող __Host- քուքին, ուստի քույր հոսթերի վրա դեռ երևացող քուքին ապացույց է, որ նախածանցը երբեք չի կիրառվել։

Հետո պահեք լիազորումը սերվերի վրա, յուրաքանչյուր հարցման համար, ամեն ադմին վերջնակետում, ոչ միայն մուտքի պահին։ Թույլատրելի ցանցից եկած հարցումը դեռ պետք է նույնականացվի և լիազորվի այն գործողության համար, որը պահանջում է. հոսթանունը գործող անձ չէ։ Եթե հանրային և ադմին հավելվածները կիսում են մուտքի հոսքը կամ սեսիաների պահոցը, գրեք այդ կապը, որովհետև դա ամենակարճ ճանապարհն է հանրային կայքի սխալից ադմին գործողության։

Կրկին ստուգեք սահմանը անջատումից հետո

Անցկացրեք բացասական թեստերը, ոչ միայն հաջող ուղին. առանց թոքենի կայք-անցում ձևը պետք է մերժվի, այլ սեսիայի թոքենը պետք է մերժվի, և ոչ մի GET չպետք է փոխի վիճակ։ Ստուգեք քուքիների հատկանիշները ծրագրավորողի գործիքներում, հաստատեք, որ Origin ստուգումը գործարկվում է անհամապատասխան հարցման դեպքում, և փորձեք ադմին հոսթը VPN միջակայքից դուրս՝ տեսնելու զտիչը աշխատելիս։

Այս ամենը չի վերացնում հենց ադմին հավելվածի ներսում XSS սխալը։ Առանձին հոսթանունը բրաուզերի կողմի մեկուսացման սահման է՝ իրական արժեքով, և այն չի փոխարինում անվտանգ կոդի կատարման կանխարգելմանը կամ սերվերի կողմի հարցումների պաշտպանությանը։ Անջատումից հետո ցանկը ավելի կարճ է, քան թվում է. առանձին ծագում, միայն հոսթի քուքիներ, թոքեն ամեն փոփոխության վրա, մուտքի զտիչ, որին որպես ինքնություն չեք վստահում, և յուրաքանչյուր հարցման համար որոշված լիազորում։