Արգելափակեք բաց տեքստը Android հավելվածներում՝ առանց VPN-ի վրա հենվելու
Բաց տեքստը բեռնվածքում և բաց տեքստը ուղու վրա տարբեր խնդիրներ են։ Առաջինը լուծեք հավելվածում, երկրորդը՝ թունելով կամ սարքի քաղաքականությամբ։
Երկու բոլորովին տարբեր բաներ անվանում են բաց տեքստի արգելափակում Android-ում։ Մեկը հավելվածի ներսում գտնվող քաղաքականությունն է, որը հրամայում է իր սեփական ցանցային կույտին մերժել սովորական HTTP-ը։ Մյուսը սարքի մակարդակի կարգավորում է, որը փորձում է պաշտպանել ամեն ինչ հեռախոսում միաժամանակ, սովորաբար ուղղորդելով երթևեկությունը VPN-ով։ Դրանք լուծում են տարբեր խնդիրներ, և երկրորդը չի կարող շտկել առաջինը. թունելը պաշտպանում է հեռախոսի և ելքի միջև ընկած հատվածը, մինչդեռ HTTP խոսող հավելվածը շարունակում է HTTP խոսել այն ամենի հետ, ինչ գտնվում է այդ ելքից այն կողմ։
Երկու խնդիր մեկ անվան տակ
Առաջին խնդիրը բեռնվածքն է. հավելվածը հավատարմագրեր կամ նշաններ է գրում մի հարցման մեջ, որը ծայրից ծայր գաղտնագրված չէ, ուստի յուրաքանչյուր թռիչք, որը կարող է տեսնել այն, կարող է կարդալ այն։ Երկրորդը ուղին է. հավելվածը կարող է լինել լիովին կարգին, և դուք դեռ ուզում եք, որ տեղական Wi-Fi օպերատորը ոչինչ չիմանա այն մասին, թե ուր է այն միանում։ VPN-ը լուծում է երկրորդը և միայն երկրորդը։
Այդ տարբերությունը որոշում է, թե ումն է շտկումը։ Բեռնվածքը պատկանում է նրան, ով առաքում է հավելվածը, քանի որ միայն այդ կոդն է որոշում, թե որ URL-ն է կանչվում և արդյոք վավերացվում է սերտիֆիկատ։ Ուղին պատկանում է սարքին կամ ցանցին, քանի որ խոսքը այն մասին է, թե ուր են գնում փաթեթները, ոչ թե ինչ են պարունակում։
Առաջին ուղի. հավելվածը, որը դուք վերահսկում եք
Եթե դուք եք առաքում հավելվածը, շտկումը տրանսպորտի որոշում է՝ գումարած քաղաքականություն, որը պարտադրում է այն։ Ուղղեք յուրաքանչյուր վերջնակետ HTTPS-ի, թողեք հոսթի անվան և սերտիֆիկատի վավերացումը միացված, և ջնջեք սովորական HTTP-ի պահուստային տարբերակը՝ այն մեկ կոնֆիգուրացիոն դրոշից հեռու թողնելու փոխարեն։ Վերահղումն այստեղ չի օգնում. 301 ստացած HTTP հարցումն արդեն ուղարկել է իր վերնագրերն ու մարմինը բաց տեսքով, ուստի հավատարմագրերը երբեք չպետք է ճամփորդեն այն ենթադրությամբ, որ վերահղումը կպաշտպանի դրանք։
Android 7.0-ից սկսած՝ քաղաքականությունն արտահայտում է Network Security Configuration-ը։ Ստորև ֆայլը ամենափոքր օգտակար տարբերակն է. այն մերժում է բաց տեքստը ամենուր, եթե տիրույթին բնորոշ բացառությունը այլ բան չի ասում։
<network-security-config>
<base-config cleartextTrafficPermitted="false" />
</network-security-config>Հղում արեք այդ ռեսուրսին մանիֆեստից, ապա նախքան առաքումը կարդացեք արդեն գոյություն ունեցող բացառությունները։ Հին կարգաբերման տիրույթը կամ վճարային մատակարարի SDK գրառումը կարող են լուռ նորից թույլատրել բաց տեքստը այն հոսթի համար, որը դուք փորձում էիք պաշտպանել։
Տարբերակի երկու մանրամասն արժե իմանալ։ API 28 կամ ավելի նոր թիրախավորող հավելվածներն արդեն լռելյայն մերժում են բաց տեքստը, ուստի դեռ սովորական HTTP խոսող հավելվածը կա՛մ թիրախավորում է ավելի հին API մակարդակ, կա՛մ ինչ-որ տեղ բացառություն ունի։ Իսկ երբ ցանցային անվտանգության կոնֆիգուրացիա կա, հին android:usesCleartextTraffic մանիֆեստի ատրիբուտն այլևս չի որոշում հարցը, ինչի պատճառով երբեմն թվում է, թե այդ դրոշը փոխելը ոչինչ չի անում։
Երկրորդ ուղի. հավելվածը, որը դուք չեք վերահսկում
Տեղադրված երրորդ կողմի հավելվածի համար դուք չեք կարող վերագրել նրա անվտանգության կոնֆիգուրացիան օգտվողի կարգավորմամբ։ Իրատեսական տարբերակներն են արտադրանքի սեփական անվտանգ միացման կառավարումը, արդեն TLS օգտագործող աջակցվող այլընտրանքը, կամ կառավարվող սարքի քաղաքականությունը, որը սահմանափակում է, թե ինչ կարող է սարքը գործարկել։ Դրանք տարբեր պարտավորություններ են, և միայն երրորդն է մասշտաբավորվում սարքերի պարկի վրա։
Ցանցային կանոններն ավելի թույլ փոխարինիչներ են, քան թվում են։ Միայն 443 պորտին թույլ տալը չի պարտադրում նույնականացված TLS, քանի որ շատ բաց տեքստի արձանագրություններ կարող են տեղափոխվել այդ պորտ, իսկ 80 պորտի արգելափակումը չի ծածկում այլ պորտերի բաց տեքստը։ Դիտարկիչի միայն-HTTPS ռեժիմը նույնպես սահմանափակված է այդ դիտարկիչով, ոչ թե նույն հեռախոսի առանձին փոստի կամ չաթի հավելվածով։
Ընդհատման սերտիֆիկատ տեղադրելը, որպեսզի երթևեկությունը գաղտնագրված թվա, վստահության փոփոխություն է, ոչ թե շտկում։ Այն փոխարինում է հավելվածի սերվերի նույնականացումը ձերով, և այն հավելվածը, որն ի սկզբանե սերտիֆիկատներ չէր վավերացնում, դրանով չի շտկվում. դուք միայն տեղափոխեցիք, թե ով կարող է կարդալ հոսքը։
Որտեղ է VPN-ն օգնում և որտեղ՝ ոչ
Թունելը ճիշտ գործիքն է, երբ պահանջը այն է, որ տեղական ցանցը ոչինչ չիմանա կապի մասին, կամ որ հավելվածը հասնի մի մասնավոր ծառայության, ուր այլ կերպ չի հասնի։ Այն սխալ գործիք է HTTP հաճախորդին HTTPS խոսել ստիպելու համար, քանի որ հարցումը թունելից դուրս է գալիս ճիշտ այնպես, ինչպես մտել էր։
Android-ը ավելացնում է գործնական սահմանափակում. հարթակը միաժամանակ մեկ VPN ծառայություն է աշխատեցնում. Այդ տեղը զբաղեցնող տեղական զտիչ հավելվածը մրցում է ձեզ իրոք անհրաժեշտ հեռավոր թունելի հետ, և նրանց միջև անցումը սարքի մակարդակի գործողություն է, ոչ թե հավելվածի։ Այդ մեկ տեղը լավ պատճառ է բեռնվածքի քաղաքականությունը հավելվածում պահելու և թունելը ուղու համար թողնելու համար։
Միակ դեպքը, երբ երկուսը համընկնում են, ձեր կողմից նույնպես վարվող մասնավոր սերվերն է։ Այնտեղ թունելը կարող է ուղին մասնավոր դարձնել, թեև արձանագրությունը դեռ բաց տեքստ է, ինչը նվազեցնում է ազդեցությունը, բայց չի փոխում, թե ինչ է բեռնվածքը։ Վերաբերվեք դրան որպես ռիսկի նվազեցում, ոչ որպես տվյալների գաղտնագրում։
Ինչ փորձարկել նախքան արգելափակված անվանելը
Սկսեք այն լռելյայնից, որը զարմացնում է մարդկանց. API 28 կամ ավելի նոր թիրախավորող հավելվածն արդեն պետք է մերժի բաց տեքստը, ուստի ստուգեք թիրախ մակարդակը նախքան լռելյայնը կրկնօրինակող կոնֆիգուրացիա ավելացնելը։ Ապա դիտավորյալ փորձարկեք ձախողման դեպքը. սովորական HTTP հոսթին ուղղված հարցումը պետք է ձախողվի, ոչ թե լուռ հաջողվի պահուստային տարբերակով։
adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartextՀաջողության դեպքի համար հաստատեք, որ HTTPS կանչը վավերացնում է իրական սերտիիկատների շղթա, և որ անվստահելի սերտիֆիկատով փոխանցողը մերժվում է, ոչ թե հանդուրժվում։ Ցանկացած սերտիֆիկատի հետ հաջողվող ձեռնասեղմումը ոչինչ չի ապացուցել տրանսպորտի անվտանգության մասին։
Երրորդ կողմի հավելվածի համար գրեք այն սահմանը, որը իրոք կարող եք պարտադրել՝ լինի դա կառավարվող սարքի քաղաքականություն, ցանցային կանոն, թե ոչինչ, և ասեք այն ընդունման չափանիշներում։ Android-ի անվտանգության կոնֆիգուրացիայի ուղեցույցը թվարկում է հարթակի լռելյայնները և թե որ բաղադրիչներն են հարգում քաղաքականությունը, և հենց այդ մասն է որոշում, թե ձեր կոնֆիգուրացիան ընդհանրապես ինչ-որ բան անում է։