http://www.ictnews.ir/
http://ictnews.ir
آرشیوی
پیشگیری از حملات سایبری تزریق کد
پیشگیری از حملات سایبری تزریق کد

بی‌تردید یکی از مهم‌ترین حملات سایبری و تهدیدات امنیت نرم‌افزارها و شبکه‌های رایانه‌ای، حمله تزریق کد و یا Injection است.

این نوع حمله سایبری، تهدید جدیدی نیست و جزو سرفصل همه دوره‌های امنیت اطلاعات آموزش داده می‌شود و همواره تیم‌های تحقیقاتی در این حوزه نگاه ویژه‌ای به آن دارند، با این حال حملات تزریق کد همچنان به گستردگی مورد استفاده نفوذگران شبکه قرار می‌گیرد. علت عدم توفیق کامل در مهار چنین حملاتی به ماهیت آن مربوط است. نحوه نفوذ به یک سیستم رایانه‌ای با استفاده از تزریق کد، استفاده از ضعف برنامه‌نویسی به واسطه استفاده از متغیرهای کنترل نشده است. یعنی اگر نقطه ابهامی در کدهای برنامه وجود داشته باشد و مثلا از متغیری استفاده شده باشد که دامنه غیر قابل کنترلی از مقادیر را بپذیرد، آنگاه تزریق کد به برنامه با استفاده از مقداردهی به همان متغیر ابهام‌دار، امکان‌پذیر خواهد بود. به طور کلی استفاده از دستورات نامطمئن در کدهای برنامه، در حین تفسیر به وسیله کامپایلر، ضعف امنیتی محسوب شده و نرم‌افزار را مستعد حمله تزریق کد می‌کند.
اصولا برقراری امنیت اطلاعات از لحاظ تئوری نباید دشوار باشد؛ اگر تهدیدی وجود دارد، باید روش دفاع در مقابل آن استفاده شود. اگر این روش‌های دفاعی به صورت متمرکز مورد استفاده قرار بگیرد، مکانیزم امنیت اطلاعات را شکل می‌دهد. به عنوان مثال در برابر تهدید دسترسی به سایت‌ها و وب‌سرویس‌ها، از یک درگاه احراز هویت استفاده می‌شود که به صورت متمرکز، نقش جلوگیری از دسترسی غیرمجاز را در مقابل تهدید دارد. متاسفانه روش مقابله با حملات تزریق (Injection) به این سادگی نیست و بر اساس توانمندی‌های کنونی در عرصه امنیت نرم‌افزارها، نمی‌توان چارچوب متمرکزی برای مقابله با آن بکار برد. از همین رو است که حمله تزریق در زمره حملات سایبری متداول قرار داده شده است.
کدهای برنامه‌های کاربردی، هدف حمله Injection
هرگاه کدهای برنامه حاوی داده‌های نامطمئن باشد، حمله تزریق کد می‌تواند اتفاق بیفتد. یکی از شایع‌ترین حملات تزریق کد، SQL Injection است که مفسر پایگاه داده را هدف قرار می‌دهد. حمله تزریق SQL برای اولین بار در سال 1998 میلادی شناسایی شد، با این وجود همچنان به وفور اخباری از این نوع حمله انتشار می‌یابد. برای نمونه، برنامه‌نویسی ممکن است نام کاربری و رمز عبور را از طریق درخواست مرورگر گرفته و پرس‌وجوی احراز هویت را بسازد:
در این حالت، نفوذگر می‌تواند به سادگی و از طریق وارد کردن پارامترهایی در قسمت آدرس مرورگر، مفهوم پرس‌وجو را تغییر دهد. در مثال فوق، پرس‌و‌جو از مقادیری استفاده کرده که پایگاه داده مورد هدف، اطلاعات احراز هویت هر کاربری را بر می‌گرداند. در مواردی به همین شکل هکر می‌تواند به همه پایگاه داده دسترسی پیدا کند و یا حتی کنترل مالکیت آن را به دست آورد.
انواع بسیاری از حملات تزریق همچون تزریق کد، تزریق LDAP، تزریق Expression Language و حتی Cross Site Scripting وجود دارد و در کل هر رابط و کامپوننتی که دارای محیط دستور باشد، به طور بالقوه می‌تواند مورد تهدید قرار بگیرد. از سوی دیگر هر نوعی از حمله تزریق، خصوصیات خاص خود را دارد و همین ویژگی مقابله با آنها را دشوار می‌کند.همه حملات تزریق ناشی از داده‌های نامطمئن است، حال باید ببینیم کدام داده نامطمئن است. یک اصل ساده در این رابطه وجود دارد؛ اگر اطمینانی از بابت داده‌ای نداشته باشیم، آن داده نامطمئن است. همه داده‌های مرورگر شامل پارامترهای آدرس، فیلدهای فرم، هدر صفحات و کوکی‌ها، داده‌های نامطمئن محسوب می‌شوند. علاوه بر این داده‌های مرورگر، وب‌سرویس‌ها و بانک‌های اطلاعاتی را هم می‌توان به این لیست اضافه کرد. تاثیر داده‌های نامطمئن بر روی برنامه کاربردی به بمب خوشه‌ای شباهت دارد چرا که با هر بار استفاده از آن داده نامطمئن، یک بردار تزریق بالقوه ایجاد می‌کند. حال برای مقابله با حملات تزریق از چه راهکارهایی باید بهره جست؟ همان طور که عنوان شد راه‌حل مطلق برای جلوگیری از این نوع حملات سایبری وجود ندارد، اما با رعایت برخی اصول و استفاده از 2 رویکرد زیر می‌توان تا حدود زیادی خطر آن را کنترل کرد.
اغلب داده‌های نامطمئن به شکل رشته‌ای کاراکتری بدون محدودیت در سایز، ویژگی‌ها، فرمت و الگو هستند. رشته‌های کاراکتری، ماهیتی مانند بسته‌های پستی دارند که با جعل تاریخ، شماره تلفن و ... قابل سرقت هستند. بنابراین هکرها با کم و زیاد کردن و یا تغییر کاراکترهای رشته‌ای، از آنها سوء‌استفاده می‌کنند. برای اعتبارسنجی داده‌ها با هدف پیشگیری از حمله تزریق کد، برنامه‌نویس باید دانش کافی از کامپایلر و یا مفسر برنامه‌اش داشته باشد. به این مفهوم که نتیجه کامپایل داده‌ها باید تحت کنترل برنامه‌نویس باشد تا خروجی غیر قابل انتظاری نداشته باشد. در غیر این صورت نتایج خارج از کنترل تفسیر داده‌ها فرصت خوبی را در اختیار هکرها قرار خواهد داد.
روش بهتر این است که از یک الگوی خاص برای اعتبارسنجی و تجزیه کدهای برنامه استفاده شود تا خروجی مورد انتظار حاصل شود، به این رویکرد اعتبارسنجی مثبت اطلاق می‌شود. البته در یک برنامه کاربردی با هزاران متغیر ورودی و خروجی برنامه، این کار آسان است. بنابراین برای کنترل و اعتبارسنجی مناسب نیاز به پشتیبانی فریم ورک از مکانیزم‌های خودکار اعتبارسنجی است که این امکانات در محیط‌های برنامه‌نویسی پیشرفته معمولا در نظر گرفته می‌شود. پس ماموریت اول، اعتبارسنجی همه ورودی‌های نامطمئن برنامه است. استفاده از کاراکترهایی مانند ویرگول و نقل قول و ... فرایند اعتبارسنجی را مختل می‌کند. بنابراین به راهکار دیگری هم برای جلوگیری از حمله تزریق کد نیاز است.
جداسازی کد و داده‌های برنامه
یکی از اصول مبانی برنامه‌نویسی، جداسازی کد و داده‌های برنامه از یکدیگر است اما گفتن این اصل بسیار راحت‌تر از عمل به آن است. آنچه واقعا به آن نیاز است، راهی است که داده‌های برنامه را از فرامین و کدها جدا نگه دارد.برخی از کامپایلرها از امکانی به نام رابط برنامه‌نویسی کاربردی پارامتر شده بهره می‌برند که دقیقا با هدف جداسازی داده و کد فراهم شده‌اند. حتما با برنامه‌هایی سروکار داشته‌اید که فقط کاراکترهای خاصی می‌پذیرند. مثلا یک جعبه متن خالی در یک صفحه وب ممکن است فقط فرمت تاریخ شمسی را قبول کند و با ورود هر نوع داده دیگری، اعلام خطا ‌کند. بنابراین برای جلوگیری از تزریق SQL می‌توان ضمن بهره‌گیری از API پارامتر شده، یک الگو برای ورود داده کاربر در نظر گرفت و پرس‌وجوی پایگاه داده را بر اساس آن ایجاد کرد.
در صورت استفاده از کامپایلرهایی که از API پارامتر شده پشتیبانی نمی‌کنند، برای جداسازی داده و کد از تکنیک‌های Escaping و Encoding استفاده می‌شود. در تکنیک Escaping از یک کاراکتر خاصی استفاده می‌شود تا به مفسر برنامه بفهماند که کاراکترهای بعد از Escape همه داده هستند و به عنوان دستور تفسیر نشوند. کاراکتر کوتیشن در جاوااسکریپ نمونه‌ای از Escaping است. تکنیک Encoding هم بسیار شبیه به Escaping است با این تفاوت که کاراکتر خاص مورد استفاده، به کاراکتر یا کاراکترهای دیگری ترجمه می‌شود. مثلا در آدرس بار به جای استفاده از کوتیشن، از 22 درصد استفاده می‌شود.
این تکنیک‌ها از اثرگذاری داده‌های نامطمئن روی معنای دستور جلوگیری می‌کند. تنها مشکلی که در این رویکرد وجود دارد، این است که هر مفسر، تفسیر و قواعد نحوی خاص خود را دارد. مثلا زبان بسیار پرکاربردی مثل HTML از قواعد نحوی متفاوتی مثل جاوااسکریپت و یا CSS escaping و غیره استفاده می‌کند و جداسازی داده و کد در آن دشوارتر است. برای آگاهی از کاراکترهایی که نیاز به استفاده از تکنیک‌های Escape و Encode دارند می‌توان از برخی کتابخانه‌های آنلاین همچون OWASP ESAPI بهره برد.
2 دلیل مهم وجود دارد که نیاز به استفاده توام رویکردهای اعتبارسنجی داده‌ها و جداسازی کد و داده را توجیه می‌کند. اولین دلیل، مقابله اولیه عمیق در برابر تهدیدات سایبری است، پیاده‌سازی کامل هر یک از رویکردها به سادگی میسر نیست. بنابراین با استفاده توامان آنها، لااقل شکاف‌های امنیتی را به حداقل رسانده و مقابله با حملات تزریق را بهبود می‌بخشد.
دلیل دوم ظریف‌تر از قبلی است. اگر یک برنامه کاربردی در مقابل حملات تزریق مصون هم باشد، باز هم نیاز به اعتبارسنجی داده‌ها دارد. چرا که اعتبارسنجی تنها راه تشخیص نفوذ به برنامه‌های کاربردی است.


مطالب مرتبط
نظرات کاربران

ارسال نظر در مورد این مطلب:
نام شما : *
آدرس ایمیل : *
متن نظر : *
کد امنیتی :
Refresh Code

لطفا عبارت درج شده در تصویر بالا را در کادر زیر بنویسید

*
 


کليه حقوق اين سایت متعلق به ICTNEWS است.
انتشار مطالب با ذکر منبع و لینک به سایت مجاز است.
تماس با ما: 88946450  فرم تماس با ما
این پرتال قدرت گرفته از :
سیستم مدیریت پرتال و خبرگزاری دیاسافت
ارتباط با ما : 1000030200