بخشی از مقاله
چکیده
PostMessage مکانیزم ارتباطی در HTML5 برای تبادل پیام بین وبسایتهایی با منشأ متفاوت است. این روش امروزه در طراحی وب به خصوص در سایتهایی که قسمتی از محتوای خود را از سایتهای دیگر تأمین میکنند، بسیار مورد توجه قرار گرفته است. چالش بزرگی که استفاده از postMessage دربر دارد، واگذاری تعیین صحت ارسالکننده یا دریافتکننده پیام به برنامهنویس است. در این مقاله به معرفی سناریوی حمله به سایتهای آسیبپذیری که از این روش ارتباطی بهره میبرند، پرداخته شده است.
همچنین دو روش دفاعی برای مقابله با این حملات ارائه شده است. روش دفاعی اول بر مبنای ایجاد یک کلید مشترک بین ارسالکننده و دریافتکننده و روش دوم مبتنی بر ایجاد امضای شخصی برای ارسالکننده و بررسی صحت امضا در گیرنده پیام است. در قسمت ارزیابی مقاله یک سناریوی حمله واقعی اجرا و راههای دفاعی ارائه شده نیز مورد بررسی قرار گرفته است. بررسی راههای دفاعی از موفقیت این دو روش در مقابله با حملات معرفی شده حکایت دارد.
در HTML5 که جدیدترین نسخه استاندارد HTML است و به سرعت نیز در حال استفاده و رشد است واسط postMessage برای تبادل پیام و اجرای اسکریپت بین دو صفحه با منشأ متفاوت در نظر گرفته شده است. توسط این واسط، چارچوبی ارائه میشود که اسکریپتی در یک دامنه میتواند دادههایی به اسکریپتی در دامنهی دیگر انتقال دهد. در واقع این تابع یک پیام بیندامنهای1 ارسال میکند.
برای این کار مرورگر منشأ گیرنده را در پیام قرار میدهد و آن را به قاب دریافتکننده ارسال میکند؛ اما وظیفه آزمودن این دامنه و اینکه تشخیص داده شود که پیام ارسالی از طرف فرستندهای معتبر است، بر عهدهی گیرنده گذارده شده است .[2][1] بررسی این مورد امنیتی و واگذاری آن به برنامهنویس، چالشهای بسیاری را ایجاد میکند. به همین علت متد postMessage در صدر مهم-ترین آسیبپذیریهای HTML5 قرار گرفته است که این مسئله خود مبین اهمیت و بهروز بودن این زمینه است .[3] در این پژوهش به بررسی عملی ارتباط بین منشائی از طریق postMessage پرداخته خواهد شد. مهمترین نوآوریهای این پژوهش عبارتند از:
· ارائه یک سناریوی حمله جهت نفوذ به سایتهای آسیبپذیری که از postMessage برای ارتباط بین منشائی بهره بردهاند.
· ارائه دو روش دفاعی موثر در برابر اینگونه حملات که به راحتی قابلاجرا در سایتهای جدید و همچنین وبسایتهای قبلاً طراحیشده، است. در این دو روش حمله که اولی بر مبنای کلید مشترک و روش دوم منطبق بر امضا است نیازی به تغییر در مرورگر و یا تغییرات زیاد در کد سایتهای آسیبپذیر نیست و تنها با اضافه کردن روش دفاعی در هنگام ارسال یا دریافت پیام به راحتی از حملات موجود جلوگیری میشود.
· ارائه یک مثال عملی از حمله و دفاع و بررسی جوانب و چالشهای موجود در ادامه این پژوهش ابتدا و در بخش دوم مطالعات مقدماتی در حوزه ارتباط بین منشائی بررسی میشود. در بخش سوم نحوه ارتباط از طریق postMessage و حملات ممکن در صورت استفاده ناصحیح از این متد بیان میگردد. سپس در بخش چهارم روشهای دفاعی پیشنهاد شده، معرفی میشود و نهایتاً در بخش آخر به بیان جمعبندی و نتیجهگیری مقاله پرداخته خواهد شد.
-2 مطالعات پیشین
نویسندگان مقاله [4] از جمله نخستین افرادی هستند که بر روی موضوع انتقال امن بین قابهای مختلف فعالیت داشتهاند. از جملهی روشهای ارائه شده توسط این افراد بهبود امنیت واسط postMessage بوده است. واسط ذکرشده در ابتدا برای مرورگر Opera 8 پیادهسازی شده بود و امروزه توسط تمامی مرورگرها پشتیبانی میشود. در ابتدا توابع ارائه شده توسط این واسط شامل ضعفهای بود.
نویسندگان مقاله در تحقیقات پیشین خود واسطی با نام CommRequest برای مرورگر استفاده شده در پروژهی MashupOS ارائه داده بودند .[5] به کمک این واسط دادهها بین دامنههای مختلف قابل انتقال است. زمانی که یک صفحه بخواهد پیامی را به صفحهای دیگر در دامنهای متفاوت ارسال کند باید برای پیام ارسالی ویژگیهایی را به شکل زیر در نظر بگیرد. به کمک این واسط، CommServer پیامها را تنها به مقصد مشخص شده، میفرستد. بنابراین محرمانگی پیامها رعایت میشود. با اینکه CommRequest امنیت لازم را فراهم مینموده است اما به دلیل اینکه postMessage در زمان نوشتن مقاله در مراحل استانداردسازی و نشر عمومی بوده است، نویسندگان مقاله ترجیح دادهاند تا با الهام از CommRequest واسط postMessage را امن سازند.
برای این منظور پارامتری با نام origin در پیامها در نظر گرفته شده است که در آن مقصد پیام به صورت واضح مشخص میشود. در این حالت فرستنده با مشخص نمودن مقصد پیام، باعث میشود که مرورگر پیام را تنها به همان قاب مشخص شده بفرستد. با این الحاق، یک قاب میتواند به پیامهای دریافتی با استفاده از کد زیر پاسخ دهد. روش پیشنهادی اگر چه در مواردی میتواند راهگشا باشد اما کماکان از سه ضعف عمده رنج میبرد. اول اینکه همانگونه که ذکر شد در postMessage به دلیل افزایش انعطافپذیری، بررسی صحت منشأ به عهده برنامهنویس گذارده میشود. همین مورد سبب بسیاری از خطاها و عدم استفاده صحیح از منشأ میشود.
عیب دوم در این روش در سایتهای پویا نمایان است برای مثال یک صفحه خارجی - مانند دکمه "Like" فیسبوک - ممکن است در هزاران سایت تکرار شود و از طرف دیگر یک سایت پویا ممکن است مطالب خود را از بخشهای مختلف یک سایت دیگر تأمین کند - نمایش تمام توئیتهای شامل یک کلمه خاص در وبسایت - . مشخص است در این حالات بررسی آدرس سایت به صورت مطلق کاری وقتگیر و عملاً غیرممکن است .[6] ضعف نهایی هم عدم توانایی مقابله با حملاتی است که از نادیده گرفتن تغییرات document.domain ایجاد میشود. به طور مثال اگر دامنه یک سایت از x.a.com به a.com تغییر کند و پیامی را به y.b.com بفرستد، y.b.com همچنان منشأ پیام را x.a.com میبیند و نفوذگر میتواند از این شرایط استفاده کند .[7]
از دیگر حملات ممکن در حوزه استفاده ناصحیح از postMessage، حمله مردمیانی است که در [8] بیان شده است در این روش حمله نفوذگر مابین ارسالکننده و گیرنده پیام قرار گرفته است و با استفاده از عدم بررسی صحیح منشأ پیام، ارتباط مخربی را با هر دو طرف برقرار میکند. در [9] تحقیقی آماری در رابطه با postMessage انجام شده است. طبق این بررسی از دههزار سایتی که بالاترین رتبه را در سایت 1Alexa دارند، 2245 سایت از متد postMessage استفاده میکنند؛ که این رقم خود بیانگر استفاده فراوان از این متد و امکان بروز مشکلات امنیتی عدیده در آن است.
در تحقیق آماری دیگر در همان مقاله که بر روی 136 دریافتکننده postMessage انجام پذیرفته، مشخص گردید حدود 65 دریافتکننده هیچگونه آزمونی برای تعیین صحت منشأ پیام ارسالی، انجام نمیدهند و در 14 مورد دیگر که در 261 سایت بهکاررفته این عمل به صورت اشتباه انجام شده است. این تحقیق خود نشانگر آسیبپذیری آشکار و وسیعی است که در بسیاری از سایتهای معروف و پربازدید وجود دارد. این تحقیق عملاً نشان میدهد که بررسی آدرس سایت به صورت مطلق عملاً در مواجهه با این آسیبپذیری ناکام بوده است.
روش پیشنهادی در [9] استفاده از توکن بین قابهای ارسالکننده و دریافتکننده میباشد. به این ترتیب که به محض اینکه یک صفحه وب پویا با یکی از سایتهای تولیدکننده محتوا ارتباطی برقرار نمود، یک توکن بین دو سایت به اشتراک گذاشته میشود و هر ارتباطی بین دو سایت تنها در صورت اطلاع طرفین از توکن ممکن خواهد بود. اگر چه این روش دفاعی در مقابل بسیاری از حملات این حوزه مفید است یعنی چنانچه در ابتدا بین سایت اصلی و صفحه خارجی توکن اشتراکی معین گردد دیگر نفوذگر نمیتواند در سایت خود پیامی را برای صفحه خارجی ارسال یا از آن دریافت نماید؛ اما مسلم است که این راه دفاعی مستلزم تغییرات در مرورگرها است که عملی هزینهبر و زمانبر است.
-3 حملات مبتنی بر postMessage
برای بررسی نحوه انجام حملات ممکن به یک سایت از طریق postMessage ابتدا به بررسی نحوه کارکرد این متد پرداخته و سپس یک نمونه عملی از نحوه حمله ذکر میگردد.
- 1-3 ارتباط بین منشأ از طریق postMessage
همانگونه که بیان شد متد postMessage برای ارتباط میان دو صفحه یا دو سایت که دارای منشأ متفاوتی هستند به کار میرود. بیشترین کاربرد این متد مربوط به حالاتی است که یک صفحه محتوای خود را از صفحات تولیدکننده محتوا دریافت میکند. به عنوان نمونه فرض کنید سایت a.com قابی از سایت b.com به عنوان یک تولیدکننده محتوا در خود دارد. سایت b.com میتواند یک سایت آماری در مورد بازدیدکنندگان سایت اصلی یا سایتی جهت امتیازدهی به مطالب یا به اشتراکگذاری مطالب در یک شبکه اجتماعی باشد، اما نکته مهم این است که در این صورت سایت میزبان باید دارای مکانیزمی جهت ارسال و دریافت پیام از قاب داخلی خود باشد. در شکل 1 شمای کلی از این حالت ارائه شده است.
نحوه ارتباط دو صفحه به این صورت است که ابتدا سایت a.com پیامی برای قاب داخلی خود که محتویات آن از b.com تهیه میشود، ارسال می-کند. معمولاً تولیدکنندگان محتوا نظارتی بر اینکه پیام واصله از کدام سایت برای آنها ارسال شده ندارند. دلیل این امر هم مشخص است، یک تولیدکننده محتوا ممکن است در هزاران سایت و صفحات متعدد از سایت-های دیگر تکرار شود. بنابراین بررسی منشأ سایت ارسالکننده در عمل برای سایتهای تولیدکننده محتوا دشوار است.
از طرف دیگر حتی اگر قرار به بررسی منشأ باشد، این عمل بر عهده برنامهنویس است که همین امر نیز سبب بروز مشکلات فراوان میشود. بسیاری از برنامهنویسان قدیمی به تازگی با این روش مبادله آشنا شدهاند و اصولاً با الزامات بررسی منشأ پیام آشنایی ندارند . از سوی دیگر حتی اگر برنامهنویس بخواهد این بررسی را انجام دهد با چالش دیگری روبهرو خواهد بود، معمولاً به صورت دقیق مشخص نیست که محتوای مورد نیاز توسط کدام صفحه یا کدام زیر دامنهی سایت میزبان درخواست میشود.
برای مثال یک تولیدکننده محتوا که اطلاعات آماری در مورد سایت مقصد ایجاد میکند، وابسته به نوع اطلاعات درخواستی و همچنین ویژگیهای سایت هدف، ممکن است با بخشهای مختلفی از سایت میزبان در ارتباط باشد. با وجود چنین چالشی در عمل بررسی مطلق آدرس مانند تصویر 1 مشکلی را حل نخواهد نمود. در نتیجه برنامهنویسان در این حوزه معمولاً منشأ را به وسیله عبارات منظم یا تکنیکهای برنامهنویسی بررسی میکنند که این بررسی نیز بسیار دشوار و مسئله برانگیز است.
