در دهه 1990، سیستم کلاینت/سرور طلایهدار صنعت ارتباطات بود. توان پردازش کامپیوترها و افزایش سرعت شبکهها منجر به ظهور برنامههای کاربری زیادی شد که اغلب به میانافزارهای برنامهنویسی و منابع داده شرکتها متصل میشدند. اما این برنامههای کاربردی و کامپیوترهایی که برنامهها در آن اجرا میشدند، در مقابل ویروسها و سایر حملات آسیبپذیر بودند. وقتی طراحی برنامههای کاربردی ضعیف است، اطلاعات حساس در معرض خطر خواهند بود.
امروزه برنامههای کاربری تلفنهمراه، طلایهدار بازار بهشمار میروند. تلفیق توان پردازش تلفنهای همراه مبتنیبر آندروئید و iOS و سایر سیستمعاملهای تلفنهمراه با سرعت شبکههای سلولی باندپهن، منجر به ظهور برنامههای کاربردی بیشتری برای تلفنهای همراه با همان رویکرد قدیمی شده است: اتصال به میانافزارهای مدیریت برنامهنویسی و منابع داده شرکتی. اما این برنامههای کاربردی و دستگاههایی که این برنامهها روی آنها اجرا میشوند، مانند گذشته همواره در معرض خطر هستند. بله، درست حدس زدید: این دژاوویی است با یک تفاوت مهم! در حالیکه بیشتر برنامههای کاربردی کلاینت/سرور در محدوده شبکههای محلی یا شبکههای گسترده شهری اجرا میشوند، برنامههای کاربردی تلفنهمراه مستقل از شبکههای شهری اجرا شده و از طریق اینترنت جهانی به سرویسها دسترسی دارند. همین امر سبب شده است بهخصوص در مواردیکه برنامههای کاربری بهصورت صحیح و با تدابیر امنیتی و کنترل دسترسی طراحی نشوند، بهطور بالقوه در معرض آسیبهای امنیتی بزرگ قرار گیرند.
سرعت میکُشد
امــروزه ابزارهـــایی نظیـــر پلتفـــرمهــای PhoneGap و Appcellerator’s Titanium درکنار سایر ابزارهای توسعه پلتفرمهای تلفنهمراه در دسترس هستند که از بسیاری جهتها، بهواسطهای توسعه یکپارچه دوران سیستمهای کلاینت/سرور نظیر ویژوالبیسیک و PowerBuilder شباهت دارند. بنابراین، برنامهنویسان و گروههای کوچک برنامهنویس میتوانند بهراحتی برنامههای کاربردی برای موبایلی طراحی کنند که با سرویسهای وب ارتباط داشته باشند و بتوانند آنها را به سیستمهای backend که با نرخ بالا روی Amazon عرضه شدهاند، مرتبط کنند. اما متأسفانه همه این تلاشها بدون درنظرگرفتن تدابیر امنیتی انجام میشود و بهاین ترتیب، چنین برنامههایی در مقابل خطرات امنیتی، آسیبپذیر خواهند بود. اگرچه توجه زیادی به حفظ امنیت دستگاهها شده است، این برنامهها از آسیبپذیری بالایی برخوردار هستند.
اگر شرکتها، نظیر شرکت مخابراتی SkyTech خوششانس باشند، این حفرهها ممکن است فقط یک عذرخواهی عمومی در پی خواهد داشت. هنگامیکه یک دانشجوی علوم کامپیوتر در یکی از دانشکدههای فنیحرفهای، از یک اسکنر امنیتی دانلود شده رایگان روی برنامه موبایل SkyTech، (که امکان جهتنام و انتخاب واحدهای درسی را برای دانشجویان فراهم میکند) استفاده میکرد، متوجه وجود حفرههای امنیتی در این برنامه شد. این حفرهها به هرکس اجازه میداد به اطلاعات شخصی دانشجویان دیگر، دسترسی پیدا کند.
برنامهنویسان، تنها افرادی نیستند که ممکن است درگیر پیچیدگیهای امنیتی برنامههای تلفنهمراه باشند. بهعنوان مثال، میتوان به جهش ناگهانی API وب OnStar متعلق به شرکت جنرال موتورز اشاره کرد. این شرکت، زمانیکه فهمید یک مالک متهور چِوی ولت، بهمنظور بازیابی اطلاعات آماری مربوط به ماشین خود از مراکز داده OnStar، از مهندسی معکوس API این برنامه استفاده کرده است، ناگزیر شد تلاش خود را در زمینه طراحی یک API عمومی، سرعت بخشد. خوشبختانه، این اقدام، خرابکارانه نبود. اما این شرکت، برخلاف قوانین مربوط به حفظ حریم شخصی GM، سایتی طراحی کرد که سایر رانندگان، قادر به انجام اقدام مشابه بودند. این کار با ورود آنها به حساب کاربری خود در OnStar انجام میشد. امروزه این سایت روی واسطکاربردی امنتری، اجرا میشود.
ساکت نگهداشتن مشترکین
کِوین نیکِلز رئیس و مدیرعامل شرکت FatFractal میگوید: «این دستهبندی زمانیکه کامپیوترها شروع به برقراری ارتباط با یکدیگر میکنند، یک مشکل به شمار میرفت.» برای جلوگیری از بروز چنین مشکلاتی، لازم است برنامهنویسان به بررسی موضوعات آدرسدهی از قبیل نظارت بر امنیت و دسترسی کاربران بپردازند. نیکلز اضافه میکند: «تلاش برنامهنویسان در بررسی این مسائل، اغلب از آغاز پروژه نیست.»
یکی از عناصر کلیدی در طراحی امنیت در برنامههای کاربردی تلفنهمراه، این است که این اطمینان بهوجود آید که کلاینت – خواه برنامه موبایل و خواه برنامه تحت مرورگر- پردازش محدودی انجام میدهند. دنی بویس بنیانگذار شرکت Speek میگوید: «بهطورکلی بهترین کار این است که کد بهکار رفته روی دستگاه را تا حد ممکن، کوچک در نظر بگیریم.» شرکت Speek یک سرویسدهنده تلفن کنفرانس مبتنیبر ابرمجازی است که از طریق کلاینت تلفنهمراه و مرورگرهای وب، کار میکنند. (بویس همچنین عضو هیئت علمی دانشگاه و مدیر سابق بخش توسعه و برنامهنویسی برنامههای کاربردی تلفن همراه و وب برای شرکت آزمایشگاهی SAT است) وی میگوید: «روی تلفنهمراه هر مشترک، اطلاعاتی است که شما نمیتوانید آنها را کنترل کنید. ما بار سنگینی از دوش مشترکان برمیداریم؛ بهاین ترتیب که بر آنچه برنامه، ارسال یا دریافت میکند، نظارت میکنیم.»
وی همچنین میگوید بسیار مهم است که یکپارچگی دادهها با سایر سرویسهای موجود در برنامه حفظ شود، نه سرویسهای موجود روی تلفن همراه: «برای مثال، برنامههای تبلیغاتی موجود در برنامههای موبایل، ممکن است کد مخرب داشته باشند. ما به مشترکان توصیه میکنیم از طریق برنامهنویسی به این نوع یکپارچگی دست پیدا کنند. آنچه از خارج از برنامه به تلفنهمراه وارد میشود، هیچگونه دسترسی به منابع سیستم نخواهد داشت.”»
دنی کویکندال، مدیرعامل و مدیر ارشد بخش تحقیقات آزمونهای امنیتی NT، میگوید: «هرچه فروشگاههای برنامه کاربردی و دادهها روی دستگاه مشترکان کمتر است، از لحاظ امنیتی وضعیت مطلوبتر خواهد بود. بسیاری از برنامهنویسان تصور میکنند فقط ترافیک دادههای ارسالی از برنامه موبایل و دادههای دریافتی توسط آنها را باید تحت تدابیر امنیتی قرار داد.» وی میافزاید: «برنامهنویسان از این منطق برای مشترکان تلفنهمراه استفاده میکنند.» بهاین ترتیب که دستورات به سیستمهای برنامهنویسی ناملموس توسط مشترکان، ارسال میشود و دادههای خام پردازش میشوند. اما درخواستهای ارسالی از برنامهکاربری میتوانند توسط اشخاصی که روی دستگاه خود، برنامه مشابهی دارند و با استفاده از برنامههای خرابکارانهای که ممکن است وضعیت ترافیک را به تصویر بکشند یا توسط اشخاصی که اطلاعات دریافتی توسط تلفنهمراه را به تصویر میکشند، به سرقت روند. کویکندال میگوید: «چنین چیزی جنونآمیز است.» در عین حال اضافه میکند: «این روش سرقت اطلاعات، بسیار رایج است.»
اساسیترین نیاز برنامههای موبایل، رمزگذاری ترافیک در بخش مدیریت برنامهنویسی است که در پایینترین سطح، با رمزگذاری لایه سوکت امن (SSL) انجام میشود. اما این رمزگذاری، بهدلیل ماهیت اتصال دستگاههای سیار، بهتنهایی کافی نیست. بسیاری از تلفنهای هوشمند، بهطور خودکار به شبکههای Wi-Fi بازی که مشخصات آنها در تلفن ذخیره شدهاست، متصل میشوند. این ویژگی باعث میشود اتصال آنها به دستگاههای خرابکاری که مشابه یک پروکسی SSL عمل کرده و درحالیکه کل ترافیک عبوری را رمزگشایی، ثبت و ذخیره کرده و دوباره رمزگذاری میکنند، بهراحتی صورت پذیرد. در عینحال، که SSL بهطورمعمول یک سد در مقابل حملات مبتنیبر مرورگر در کامپیوترها بهشمار میرود، برخی برنامههای موبایل در مقابل آنها آسیبپذیر هستند. نمونهای از چنین حملاتی، میتوان به حملات Man In The Middle اشاره کرد. در این نوع حمله، یک پیام خطا به برنامه ارسال میشود که کاربر مجبور به تأیید آن شده و به کد اجازه میدهد درباره آنچه میخواهد انجام دهد، تصمیم بگیرد. در برخی موارد، برنامهها بهگونهای طراحی شدهاند که چنین پیامهایی را تأیید کنند، بهاینترتیب، دستگاه در مقابل حمله Man In The Middle آسیبپذیر خواهد بود. کویکندال میگوید: «من میتوانم با یک لپتاپ و اتصال Wi-Fi در یک مکان عمومی مثل یک فروشگاه بنشینم و بهعنوان یک Man-In-The-Middle به اینترنت دسترسی پیدا کرده و ترافیک ارسالی از تلفنهای همراه افراد را بدون اینکه آنها متوجه شوند، مشاهده کنم و بهروزرسانی شدن برنامههای موبایل آنها را ببینم.» از آنجا که بسیاری از برنامههای موبایل بدون مداخله کاربر بهروزرسانی میشوند، نیازی نیست کاربران تغییری در تنظیمات اتصال ایجاد کنند. اگر در این میان، دادهها با استفاده از یک حمله Man-In-The-Middle وارد دستگاه مشترک شود، هیچ کنترل امنیتی روی آن صورت نخواهد گرفت و چنین حملهای میتواند به سیستمهای مدیریت برنامهنویسی آسیب برساند.
آسیب دیگری که ممکن است به دستگاه سرویسگیرنده وارد شود، زمانیاست که مشترک بخواهد دادههای بیشتری روی دستگاه خود ذخیره کند. حتی دادههای موقت (اطلاعاتی که بهصورت محلی ذخیره میشوند تا برای نمایشگر پردازش شوند یا به قسمت مدیریت برنامهنویسی ارسال شوند) نیز گاهی آسیبپذیر هستند. نیکِلز میگوید: «دسترسی به برنامه و سرقت آن، چندان آسان نیست.» وی میافزاید: «بهکارگیری پایگاههای دادهای نظیر SQLite، فراتر از مسئله حافظه دائمی یا موقت یک تلفن است. لازم است دادهها واضح نبوده و رمزنگاری شوند. علاوهبرآن، دادهها را باید در جایی ذخیره کرد که دسترسی به آنها بهسادگی امکانپذیر نشود.
همواره از اطلاعات خود محافظت کنید
استفاده از یک API مناسب برای برقراری ارتباط بین برنامهکاربردی مشترک و بخش مدیریت برنامهنویسی (به این معنا که دادهها در کجا ذخیره شوند که از امنیت بالایی برخوردار باشند و نیز نحوه پردازش آنها بهگونهای که توان کمتری مصرف شود) میتواند امنیت کلی برنامه را تأمین کند. نیکلز میگوید: «اگر در بخش اگر بیشترین یکپارچگی را در Backend ایجاد کنید، نتیجه بهتری خواهد گرفت.» همچنین میافزاید: «شما میتوانید آنچه را توسط تلفنهمراه، ارسال و دریافت میشود کنترل کرده و به روند بهبود اجرای برنامه روی تلفنهمراه کمک کنید.» در عین حال، لازم است بسته به نوع دادههایی که به کاربران اجازه دسترسی به آنها را میدهید، به کارهای بیشتر از در نظر گرفتن API مورد استفاده در برنامه نیاز خواهید داشت تا این اطمینان حاصل شود که پیام دریافتی از سوی شما، آغاز یک حمله هک نیست.
بهگفته نیکلز، تنها راهی که این اطمینان را میدهد که کاربران بخش Backend، کاربران قانونی برنامه هستند، این است که کنترل دسترسی، مدیریت نشست (session) و نظارتهای قدرتمند روی ارتباط دادهها صورت گیرد و واسطهای شناختهشده که دسترسی به دادهها را محدود میکنند، بهکار گرفته شوند. نیکلز میگوید: «آنچه شما باید انجام دهید این است که مشخص کنید بدون ورود به حساب کاربری یک مشترک، چه کارهایی میتوانید انجام دهید. همچنین باید درباره آنچه کاربران به آن دسترسی دارند، بسیار حساس بود.»
خطر نبود نظارت یکسان بر دسترسی کاربران، توسط حامد الخباز شرح داده شده است. حامد الخباز، دانشجویی است که در برنامهکاربردی SkyTech مربوط به اطلاعات یک دانشجو، متوجه وجود یک مشکل امنیتی شد. او فهمید URLهای مرتبط با بخشهای مختلف اطلاعات این دانشجو، نسخه بخشبخش شدهای از شماره دانشجویی او بوده است. او URL مربوط به عکس خود را به سیستم همکلاسی خود ارسال کرد و مشاهده شد، بدون نیاز به ورود به حساب کاربری، تصویر قابل دسترسی است. او همچنین نشان داد سایر اطلاعات مربوط به دانشجویان دیگر نیز از این قائده مستثنی نیستند.
در برنامههای تلفنهای همراه نیز اشکال مختلف تشخیص هویت برای دسترسی کاربران به اطلاعات وجود دارد که البته، در بسیاری از آنها، مدیریت session قدرتمندی وجود ندارد و بسیاری از sessionها اجازه دارند برای همیشه برقرار شوند. این امر، بهدلیل ماهیت اتصال دائمی دستگاههای سیار است.
کویکندال میگوید: «هر برنامهکاربردی تحت وب، بعد از گذشت مدت زمان محدودی، شما را از حساب کاربری خارج میکند.» وی همچنین میافزاید: «اما برنامههای تلفنهمراه، چنین ویژگیای ندارند. زیرا این به آن معنا است که کاربران باید دوباره خود از مرحله تشخیص هویت عبور کنند یا کلماتعبور باید در بخشی از دستگاه ذخیره شوند.» وی اضافه میکند: «بههمین دلیل، sessionهای برنامههای تلفنهمراه، هیچگاه بهطور خودکار منقضی نخواهند شد.»
این خصوصیت، برای مهاجمانی که در میان راه به ترافیک دادهها دسترسی دارند، یک موقعیت خوب به شمار میرود. کویکندال میگوید: «یک خرابکار میتواند از ترافیک ارسالی و دریافتی، چندین بار استفاده کند. استفاده دوباره از ترافیک یک کاربر، کار سادهای است و اگر بتوانیم آن نشست را باز نگه داریم، میتوانیم به این موفقیت دست یابیم.»
یک راه برای مقابله با این نفوذ، اعمال روشی است که در فریمورک باز تشخیص هویت OAuth 2.0 بهکار گرفته میشود که به آن “Nonce” یا “Number used once” میگویند. Nonce یک رشته تصادفی است که بهصورت خاص، برای هر درخواست ارسال شده توسط یک برنامه با نشست مرورگر، تولید میشود. از Nonce در بخش اتصال به مهر زمان استفاده میشود تا این اطمینان حاصل شود که این درخواست، قبلاً ارسال نشده است. Nonce بههمراه یک توکن نشست که به همراه یک رمز توکن ساخته میشود، ارسال میشود (رمز توکن، کلیدی است که یکبار توسط بخش Backend ایجاد میشود تا نظیر یک سند تشخیص هویت که هیچگاه دوباره به برنامهکاربردی باز نخواهد شد، عمل کند). کویکندال میگوید: «برای هر درخواست، باید یک توکن نشست مبتنیبر کلید و نیز یک کد بررسی خطا برای کل بلوک دادهای که قرار است ارسال شود و همچنین یک Nonce که برای هر انتقال داده، منحصر بهفرد است، ارسال کنید. با استفاده از نشست و Nonce مدیریت نشست آسانتر خواهد شد، اما این در شرایطی است که کارهای مذکور، به درستی انجام شود» (شکل1).