Սոկետի զուգընկեր, թե փոխանցված վերնագիր. ո՞ր հասցեին վստահել։

Ձեր հավելվածին հասնող հարցումը կրում է հասցեի երկու տեսակի ապացույց՝ ցանցային կապը բացած զուգընկերը և HTTP դաշտ, որը պնդում է ավելի վաղ հաճախորդի հասցեն։ Նրանք պատասխանում են տարբեր հարցերի։ Սոկետի զուգընկերը դիտվում է, իսկ վերնագիրը պնդում է նա, ով գրել է այն, և ոչ մեկը չպետք է լռությամբ փոխարինի մյուսին մատյանում կամ մուտքի կանոնում։ Ստորև բերված համեմատությունը դրանք առանձին է պահում, ապա ցույց է տալիս միակ դասավորությունը, որում վերնագիրը դառնում է օգտագործելի։

Նկարագրեք ուղին, նախքան ինչ-որ բան համեմատելը.

Client -> approved reverse proxy -> application origin

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

Հասցեի ապացույցի երկու տեսակ

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

Փոխանցման դաշտը մետատվյալ է շղթայի մասին։ X-Forwarded-For, X-Real-IP և ստանդարտացված դաշտը Forwarded կարող է գրել ցանկացած հաճախորդ, որը հասնում է դրանք արձագանքող վերջնակետի, ուստի դրանց վստահելիությունը լիովին կախված է նրանից, թե ում էր թույլատրված դրանք սահմանել։

Պահեք երկուսն էլ հարցման համատեքստում տարբեր անուններով։ Հավելվածը, որը վերագրում է զուգընկերոջը վերնագրով, կորցնում է վստահության սխալը հետագայում վերակառուցելու ունակությունը, և դա հենց այն պահն է, երբ դա ձեզ պետք է։

Վերնագիրը երբեք չի վերաուղղորդում կապը

Փոխանցման դաշտում հասցե գրելը չի փոխում սերվերին հասնող TCP կապի աղբյուրը և չի փոխում երթուղավորումը ուղու ոչ մի կետում։ Սովորական VPN երթուղավորումը կամ աղբյուրային NAT-ը երթևեկությունը հասցնում է առանց որևէ HTTP վերնագրի։ Նույն կերպ, տրանզիտ դարպասը չի վերագրում պատշաճ պաշտպանված HTTPS փոխանակումը առանց TLS վերջնակետի դասավորությունը փոխելու։

Հակառակ սխալը նույնքան տարածված է. HTTPS-ը չի դարձնում հաճախորդի տրամադրած փոխանցման վերնագիրը ճշմարիտ։ Այն պաշտպանում է կեղծ պնդման փոխադրումը ճիշտ այնպես, ինչպես ճշմարիտի։

Եթե գործընկերը առաջարկում է վերնագրի փոփոխություն՝ երթուղավորման խնդիրը լուծելու համար, ախտորոշումն արդեն սխալ է գնացել։ Ուղղեք ուղին կամ ուղղեք միջնորդի կարգավորումը, որը գրում է վերնագիրը։

Անվանեք միջնորդին, որին թույլատրված է պնդել

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

NGINX-ի իրական IP մոդուլը հստակ ցույց է տալիս բաժանումը։ set_real_ip_from անվանում է այն ուղարկողներին, ում պնդումը հաշվի է առնվում, և real_ip_header ասում է, թե որ դաշտն է կրում այն. առաջինը կատարում է վստահությունը, երկրորդը միայն ասում է, թե որտեղ նայել։

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Միայն վերնագիր ընտրող հրահանգն ինքնին դեռ ոչինչ չի հաստատում այն մասին, թե ով է ուղարկել արժեքը։

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

Գիտակցաբար զբաղվեք բազմաթռիչք շղթաներով

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

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

Երբ ավելացնում եք թռիչք, վերանայեք այդ փաստաթուղթը։ Վստահելի միջնորդի առջև տեղադրված նոր բեռնվածքի հավասարակշռիչը կարող է փոխել, թե որ հասցեն է հաղթում, առանց որևէ մեկի հավելվածը խմբագրելու։

Պահեք երկու դիտարկումներն էլ մատյանում

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

Հիշեք, թե ինչ է նշանակում զույգը։ Վերնագիրն ավելացնում է համատեքստ, որը տրամադրում է ձեր վստահելու ընտրած բաղադրիչը. զուգընկերը մնում է միակ հասցեն, որը ձեր հյուրընկալողն իրականում տեսել է։ Նրանցից ոչ մեկը անհատական ինքնության ապացույց չէ, և ցանկացածը որպես ապացույց դիտարկող ձևավորումը սխալ կլինի ինչ-որ մեկի հարցում։