App development-ում ամենավտանգավոր ենթադրություններից մեկն այն է, որ mobile app-ի ներսում տեղադրված որևէ բան իսկապես secret է։
Դա private է թվում, որովհետև կոդը գտնվում է app binary-ի ներսում, ոչ թե հրապարակային webpage-ում։ Բայց երբ app-ը բաշխվում է օգտատերերի սարքերին, այն այլևս նույն ձևով ձեր վերահսկողության տակ չէ։
Սա նշանակում է, որ API key-երը, hidden URL-երը, hardcoded token-ները, private logic-ը և «internal-only» կանոնները app-ի ներսում պետք է դիտվեն որպես վաղ թե ուշ բացահայտվող։
Պարզ իրական օրինակ
Պատկերացրեք՝ թիմը կառուցում է mobile app և դրա մեջ դնում է՝
- third-party API key
- թաքնված admin endpoint URL
- secret flag՝ premium behavior բացելու համար
- business logic, որը ենթադրում է, որ օգտատերերը չեն տեսնի՝ ինչպես են request-երը կազմվում
Թիմը կարող է մտածել՝ «Օգտատերերը միայն interface-ն են տեսնում, ոչ իրական ներսի կառուցվածքը»։
Բայց հարձակվողները պարտավոր չեն հետևել interface-ին։ Նրանք կարող են inspect անել traffic-ը, decompile անել app-ը, reverse engineer անել behavior-ը, replay անել request-երը և փոփոխել client environment-ը։
Հենց դրա համար client app-ը երբեք չպետք է դիտվի որպես վստահելի secret vault։
Ինչու mobile app-ի secret-ները իրականում secret չեն
- App-ը բաշխված է։ Երբ օգտատերը ներբեռնում է այն, կոդն ու asset-ները արդեն «դաշտում» են։
- Traffic-ը կարելի է դիտարկել։ Հարձակվողները հաճախ ուսումնասիրում են՝ ինչպես է app-ը խոսում backend service-ների հետ։
- App-երը կարելի է reverse engineer անել։ Obfuscation-ը կարող է դանդաղեցնել վերլուծությունը, բայց չի ստեղծում իրական secrecy։
- Client behavior-ը կարելի է փոխել։ Հարձակվողները կարող են patch անել app-ը, hook անել function-ները կամ simulate անել request-երը՝ առանց պաշտոնական UI-ից օգտվելու։
Սա է հիմնական միտքը․ mobile client-ը attack surface-ի մաս է, ոչ trusted boundary։
Տարածված վտանգավոր սխալներ
- hardcode անել secret API key-երը app-ի ներսում
- վստահել app-ին, որ այն enforce կանի premium կամ admin կանոնները
- ենթադրել, որ hidden endpoint-ները անվտանգ են, որովհետև UI-ում չեն երևում
- client-side check-երի վրա հենվել price, permission կամ role restriction-ների համար
- չափազանց շատ business logic դնել client-ում՝ առանց backend validation-ի
Այս սխալները տարածված են, որովհետև app-ը «փակ» է թվում։ Իրականում distributed client-երը inspectable են։
Ինչ պետք է իրականում պաշտպանված լինի backend-ում
- Authorization կանոնները։ Server-ը պետք է որոշի՝ օգտատերը ինչ կարող է տեսնել կամ փոխել։
- Զգայուն business logic-ը։ Price, entitlement, approval և permission որոշումները չպետք է կախված լինեն միայն app-ից։
- Secret credentials-ը։ Իրական secret-ները պետք է լինեն trusted server-ներում, ոչ downloadable app-ի ներսում։
- Rate limit-ները և abuse control-ը։ Backend-ը պետք է ենթադրի, որ request-երը կարող են script արվել կամ replay արվել։
- Validation-ը։ Server-ը պետք է validate անի payload-ները, identity-ները և թույլատրելի state change-երը։
Եթե backend-ը կանոնը չի enforce անում, այդ կանոնը ավելի թույլ է, քան շատ թիմեր պատկերացնում են։
Իսկ API key-երի՞ մասին ինչ անել
Որոշ public կամ low-risk third-party key-եր mobile app-երում կարող են լինել, եթե provider-ը հենց client-side օգտագործումն է նախատեսում։ Բայց այդ key-երը պետք է դիտվեն որպես դիզայնով բացահայտվող, ոչ թե իրական secret։
Այդ դեպքերում պաշտպանությունը պետք է գա այսպիսի բաներից՝
- խիստ սահմանափակ scope
- domain, app կամ platform restriction-ներ, եթե provider-ը աջակցում է
- rate limiting
- backend proxy՝ զգայուն գործողությունների համար
Հարցը «Կարո՞ղ է այս key-ը երևալ» չէ։ Ավելի անվտանգ հարցն է՝ «Եթե այս արժեքը դուրս բերվի, ի՞նչ վնաս է հնարավոր»։
Թաքնված դասը․ երբեք մի խառնեք hidden-ը secure-ի հետ
Ծրագրային անվտանգության մեջ թաքնված բաները հաճախ անվտանգ են թվում միայն այն պատճառով, որ սովորական օգտատերերը չեն նկատում դրանք։ Բայց հարձակվողները սովորական օգտատերեր չեն։ Նրանք նայում են հենց այնտեղ, որտեղ թիմերը հույս ունեն, որ ոչ ոք չի նայի։
Հենց դրա համար հասուն անվտանգության մտածելակերպը չի հիմնվում client-ի secrecy-ի վրա։ Այն հիմնվում է server-side enforcement-ի, least privilege-ի, validation-ի և damage containment-ի վրա։
Տարածված վտանգավոր հավատքը
Տարածված միտքն է՝ «Դա app-ի ներսում է, այսինքն՝ օգտատերը չի կարող իրականում վերցնել»։
Դա վտանգավոր մտածելակերպ է։ Երբ app-ը արդեն սարքի վրա է, հարձակվողն ավելի մոտ հասանելիություն ունի դրան, քան ձեր թիմը։
Եզրակացություն
Mobile app-երը կարող են պարունակել օգտակար կոդ, բայց չեն կարող ապահով պահել ուժեղ secret-ներ կամ trusted authority միայնակ։ Եթե ինչ-որ բան իսկապես կարևոր է՝ permissions, money, entitlements, sensitive logic կամ protected resources, backend-ը պետք է enforce անի այն այնպես, կարծես app client-ը կարող է inspect, copy և manipulate արվել։ Որովհետև դա հնարավոր է։