حمله تزریق کد چیست؟ معرفی حملات Injection و روش مقابله با آنها
حملات injection یا تزریق کد مانند تزریق SQL، OS و LDAP زمانی اتفاق می افتد که داده های بی اعتبار به عنوان دستور یا کوئری به یک مفسر فرستاده می شود. داده مخرب مهاجم می تواند مفسر را به اجرای دستورات ناخواسته مجبور کند و یا اینکه به مهاجمین اجازه دهد که به داده هایی بدون انجام احراز هویت دسترسی یابند.
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
- عامل تهدید: عامل تهدید و حمله می تواند با توجه به برنامه متفاوت باشد، به عبارتی می توان گفت که هر برنامه خاص یک عامل مخصوص به خود را دارد. این طور فرض کنید که هرکس می تواند اطلاعات نامعتبر را به سیستم (شامل کاربران بیرونی، کاربران درونی و مدیران) بفرستد.
- روش حمله: روش حمله و تخریب مهاجمین آسان است. مهاجمین اطلاعات متنی ساده ای را می فرستند که Syntax مفسر را به هم می ریزد. تقریبا می توان گفت که هر ورودی اطلاعات (حتی ورودی های داخلی) می تواند یک مسیر برای حمله باشد.
- ضعف امنیتی: حملات تزریقی وقتی اتفاق می افتد که یک برنامه اطلاعات غیر قابل اعتماد را به یک مفسر می فرستد. این نوع حمله ها بسیار شایع هستند، به خصوص در کدهایی که از یکدیگر ارث می برند. معمولا این نوع حمله ها در SQL، LDAP، XPath، کوئری های NoSQL، دستورات سیستم عاملی، تجزیه کننده های (Parser) XML، هدرهای SMTP، آرگومان های برنامه و ... دیده می شود. پیدا کردن نقاط ضعف برنامه در برابر حمله تزریقی را در هنگام تست کد به راحتی می توان پیدا کرد اما زمان آزمایش برنامه این کار مشکل می شود. اسکنرها و fuzzerها به مهاجمین کمک می کنند تا نقاط ضعف برنام در مقابل injection را پیدا کنند.
- آسیب فنی: تزریق کد می تواند به از دست رفتن یا تخریب اطلاعات، مشکل در پاسخگویی و یا عدم دسترسی منجر شود. گاهی اوقات با استفاده از تزریق کد می توان کنترل کامل هاست را به دست گرفت.
- آسیب تجاری: ارزش تجاری اطلاعاتی که تحت تاثیر قرا گرفته است و پلتفرم اجرا کننده مفسر را در نظر بگیرید. همه اطلاعات می توانست دزدیده، دستکاری و یا حذف شود. اعتبارتان را می توانید تخریب کنید؟
آیا من در برابر تزریق کد آسیب پذیرم؟
بهترین راه برای فهمیدن اینکه یک برنامه در مقابل تزریق کد آسیب پذیر است یا نه، این است که تمام اطلاعات غیر قابل اعتماد را قبل از رسیدن به دستورها و کوئری ها از هم جدا کنیم. برای فراخوانی های SQL، به این معنی است که در عبارات و stored procedure ها از متغیرهای قیدی استفاده کنیم و از کوئری های دینامیک جلوگیری کنیم.برای اینکه بفهمید کدتان از مفسر بدون خطر استفاده می کند، کدتان را چک کنید. چک کردن کد یکی از سریع ترین و دقیق ترین روش ها برای این کار است. ابزارهای تحلیل گر کد به متخصصین تحلیل امنیت کمک می کنند تا کاربرد مفسر و جریان داده درون برنامه را بررسی کنند.
تسترهای نفوذی هم هستند که اعمال برنامه را واکاوی می کنند و نقاط ضعف را استخراج می کنند. همچنین می توانید از روش های اسکن دینامیک استفاده کنید. با این روش می توانید بعضی از نقاط ضعف برنامه تان در برابر تزریق کد را پیدا کنید. اسکنرها همیشه نمی توانند به مفسر دسترسی پیدا کنند و در پیدا کردن حملات موفقیت آمیز، مشکل دارند. هرچه قدر در برنامه تان مدیریت خطا را قوی تر انجام دهید، پیدا کردن نقاط ضعف در برابر تزریق کد ساده تر می شود.
چگونه از تزریق کد در برنامه ام جلوگیری کنم؟
مهم ترین مسئله در پیشگیری از این نوع حمله ها، جدا کردن داده های غیر قابل اعتماد از دستورها و کوئری ها است.
- گزینه مناسب استفاده از یک API امن است. این API باید از استفاده کامل از مفسر جلوگیری کند و یا یک رابط با استفاده از پارامترها ایجاد کند. هنگام استفاده از APIها هم مراقب باشید، چراکه با اینکه بعضی از آن ها از رابط پارامتری استفاده می کنند، اما همچنان در برابر تزریق کد خطرپذیر هستند.
- اگر API پارامترسازی شده نیست، هنگام استفاده از کاراکترهای خاص با استفاده از روش های رمزنگاری مفسر، کدهای تان را رمز نگاری کنید.
- اعتبارسنجی مثبت یا همان "لیست سفید" برای داده های ورودی نیز مفید است، اما یک دفاع کامل نیست، چون در ورودی بسیاری از برنامه ها کاراکترهای خاص را می بینیم. اگر کاراکترهای خاص داشتیم، تنها راه حل های 1 و 2 که در بالا ذکر شد، امن هستند.
چند سناریو نمونه برای حملات تزریق کد
سناریو 1. برنامه از داده های غیر قابل اعتماد در ساختار این دستور آسیب پذیر SQL استفاده می کند:
String query = “SELECT * FROM accounts WHERE custID=’” + request.getParameter(“id”) + “’”;
سناریو 2. همانند سناریو بالا، اعتماد کورکورانه برنامه به فریم ورک باعث شده که کوئری های غیذ قابل اعتماد داشته باشیم. (مانند Hibernate Query Language):
QUERY HQLQuery = session.createQuery(“FROM accounts WHERE custID=’” + request.getParameter(“id”) + “’”);
در هر دو مثال، مهاجم می تواند مقدار پارامتر id را با ‘ or ‘1’=’1 مقدار دهد. برای مثال:
http://example.com/app/accountView?id=’ or ‘1’=’1
این کار باعث می شود که کوئری بالا تمام اطلاعات جدول accounts را در خروجی ارایه دهد. حملات خطرناک تر می توانند اطلاعات را دستکاری کنند و یا stored procedureها را درخواست کنند.
نویسنده: پویا فضلعلی
منبع: انجمن تخصصی فناوری اطلاعات ایران
هرگونه نشر و کپی برداری بدون ذکر نام منبع و نویسنده دارای اشکال اخلاقی می باشد.