چگونه می‌توان از حملات SQL Injection جلوگیری کرد؟
در این مقاله قصد داریم روش های جلوگیری از حملات Sql Injection را مورد بحث قرار بدیم. ما همچنین تهدیدات و رویکردهایس را که می‌توانید اتخاذ کنید ذکر خواهیم کرد.
مدل داده:
مدل داده مورد استفاده، مدل داده زیر است.
در این مقاله، خیلی روی داده متمرکز نخواهیم شد، بلکه بیشتر روی کدی خواهیم بود که می‌توانیم برای جلوگیری از حملات SQL Injection استفاده کنیم. این کد می‌تواند به راحتی متناسب با نیازهای شما اصلاح شود، یا اگر برخی از آنها را از دست دادیم می‌توانید برخی از چک‌ها را اضافه کنید.
تهدیدات مربوط به غیر از SQL Injection:
ابتدا می‌خواهیم در مورد تهدیدها و اقداماتی که تنها مربوط به SQL Injection نیست و می‌توانید انجام دهید صحبت کنم. بیایید آنها را لیست کنیم:
- قانون طلایی این است که به هیچکس اعتماد نکنید. این مخفف کارمندان، مهاجمان بالقوه و حتی برنامه‌های شما است. مشتریان می‌خواهند که این برنامه همان کاری را که نیاز دارند انجام دهد و انتظار ندارند که به هیچ وجه به صورت غیر برنامه ریزی شده مورد استفاده قرار گیرد و این اغلب منجر به راه حل‌های سریع می‌شود که چنین مواردی را پوشش نمی‌دهد. پایگاه داده "بازی" اعداد بزرگ است. اگر فرصتی برای وقوع یک اتفاق حتمی را از دست دهید، دیر یا زود اتفاق می افتد. این می‌تواند منجر به چیزی شود که شما به راحتی می‌توانید از آن چشم پوشی کنید، اما همچنین با خراب شدن داده‌های خود (منقضی، حذف و غیره). بنابراین، به هیچکس حتی به خودتان اعتماد نکنید. حداقل برای مواردی که انتظار چنین رخدادی برای آنها بیشتر است بررسی‌هایی را انجام دهید که موارد این چنینی را پوشش دهد.
- تهدید رایج دیگر حتی فنی نیست. رمزهای عبور خود را ایمن نگه دارید، آنها را در جایی قرار ندهید که کسی به راحتی به آنها دسترسی داشته باشد و بعداً برای یک حمله احتمالی از آنها استفاده کند.
- نیازی نیست که افراد خارج از سازمان، یا حتی در داخل سازمان شما، تمام جزئیات مربوط به سازمان شما را بداند. این مخفف پایگاه داده است، اما همچنین برای هر چیز دیگری در سازمان شما یا داده‌ها در قالب کاغذ، کد safe / vault و غیره است.
- این یکی مربوط به قبلی و مخفف هر دو است – پایگاه داده و به طور کلی. مجموعه‌ای از نقش‌ها و مجوزها را تعیین کنید که می‌توانند در داخل سازمان، سیستم IT و غیره کارهایی را انجام دهد.
برای جلوگیری از حملات مرتبط با SQL Injection چه کاری می‌توانید انجام دهید؟
ما در این مقاله درباره SQL Injection صحبت کردیم، بنابراین وقت بیشتری را برای توضیح آن در اینجا نمی‌گذرانیم. قبل از رفتن به قلب این مقاله، من اقدامات و روش‌های مربوط به SQL / IT را ذکر می‌کنم که می‌توانید برای جلوگیری از حملات SQL Injection استفاده کنید. من لیست آنها را که عمدتاً مربوط به SQL هستند را شروع می‌کنم و با این موارد "همیشه سبز" در IT خاتمه می‌دهم.
- از پرس و جوهای پارامتر شده، ORM یا رویه‌های ذخیره شده استفاده کنید. این نه تنها بررسی‌های پیاده سازی شده را به شما ارائه خواهد داد (یا این‌هایی که سیستم ارائه می‌دهد یا این‌هایی که شما پیاده سازی کرده‌اید) بلکه ساختار پایگاه داده را از نظر مهاجم احتمالی پنهان می‌کند. هر چه اطلاعات کمتری در مورد پایگاه داده خود افشا کنید، بهتر است.
- از نقش‌ها و امتیازات برای کنترل آنچه کاربر مطمئن می‌تواند با پایگاه داده شما انجام دهد استفاده کنید. با این روش اقداماتی را که یک مهاجم بالقوه می‌تواند در صفحات و فرم‌های شما انجام دهد محدود خواهید کرد.
- برای یافتن عبارات rouge SQL، دستورات را وارد کنید و نظارت کنید.
- هر کد قدیمی را که استفاده نمی‌کنید حذف نمایید. اگر نیازی به آن ندارید، بهتر است از شر آن خلاص شوید تا اینکه آن را به عنوان یک فرصت احتمالی برای استفاده به روش نامطلوب باقی بگذارید.
- نرم افزار خود را به روز رسانی کنید تا اطمینان حاصل کنید که جدیدترین پچ ها (Patch) روی سیستم شما اعمال شده باشند.
- از فایروال استفاده کنید.
روش ما مبتنی بر استفاده از سرور SQL پویا، توابع تعریف شده توسط کاربر و رویه‌های ذخیره شده است. ما همچنین فقط مقادیری را که به عنوان مقادیر متنی منتقل می‌شوند، آزمایش خواهیم کرد. برای تأیید اینکه رشته ورودی ایمیل است یا مقدار کدپستی، بررسی‌هایی را اجرا نمی‌کنیم.
راه حلی برای جلوگیری از حملات Sql:
در راه حل ما، آنچه را که قبلاً در این مجموعه آموخته‌ایم ترکیب خواهیم کرد و کدی ایجاد خواهیم کرد که به عنوان ستون فقرات برای جلوگیری از حملات SQL Injection استفاده می‌شود. فرض اصلی من این است که روش‌های ذخیره شده باید برای هر عملی، از درج ساده یا دستورات انتخاب شده تا گزارش‌های پیچیده، استفاده شوند. با این کار برنامه فقط نام رویه‌ها و پارامترهای ذخیره شده را منتقل می‌کند. به این ترتیب مهاجم بالقوه جزییاتی در مورد ساختار پایگاه داده ما ندارد و همچنین می‌توانیم به کاربران امتیازاتی اعطا کنیم که به آنها امکان بدهد فقط روش‌های مشخصی را اجرا کنند. هدف اصلی این است که آخرین مورد را در اینجا آزمایش کنیم و این پارامترهایی است که به روش ما منتقل می‌شود. برای انجام این کار، ما یک تابع ایجاد می‌کنیم که بررسی را انجام می‌دهد، و نحوه عملکرد آن را در ترکیب با یک روش ذخیره شده برای اجرای یک پرس و جو ساده SQL نشان می‌دهیم (همچنین نشان خواهیم داد اگر پارامترها را آزمایش نکنیم چه اتفاقی می افتد).
جلوگیری از حملات SqlInjection - نمونه عملکرد:
ابتدا، تابعی ایجاد خواهیم کرد که رشته ورودی منتقل شده به روش را آزمایش می‌کند. در این تابع، ما همه زیرشاخه‌هایی را که نمی‌خواهیم به عنوان بخشی از مقادیر پارامتر منتقل شوند، لیست می‌کنیم. در اینجا باید مراقب باشیم زیرا ممکن است بخواهیم از برخی از این مقادیر استفاده کنیم، بنابراین مقادیری را که انتظار دارید حذف کنید. من با کاراکترهای خاص و کلمات رزرو شده در برنامه این جا پیش رفته‌ام. ایده این است که اگر همه چیز خوب باشد، تابع مقدار 1 را بر می‌گرداند و در غیر ای صورت مقدار 0 را بر می‌گرداند. بنابراین، بیایید به تعریف عملکرد نگاه کنیم:
بیایید اکنون تابع را با مقادیر کم فراخوانی کنیم تا آزمایش کنیم دقیقاً همان چیزی است که ما می‌خواستیم.
مشاهده می‌کنید که این عملکرد دقیقاً برای این ترکیبات 1 برگشته است که در آن از هیچ رشته "ممنوعه" استفاده نکرده‌ایم و در موارد دیگر 0 برگشته است.
جلوگیری از SQL Injection _ نمونه روش:
اکنون ما آماده هستیم تا یک روش ذخیره شده را بنویسیم که برای قرار دادن داده‌ها در جدول مشتری با استفاده از عملکرد ایجاد شده قبلی برای آزمایش پارامترهای ورودی استفاده می‌شود. من فقط پارامترهای متنی را در اینجا آزمایش می‌کنم، زیرا آنها پارامترهایی هستند که می‌توان هر چیزی را عبور داد.
اگر از همه بررسی‌ها عبور شود، ما یک عمل درج انجام خواهیم داد، در غیر این صورت، خطایی رخ می‌دهد. بیایید اکنون نگاهی به کد روش بیاندازیم:
همانطور که مشاهده می‌کنید، ما پارامترهای نام مشتری (customer_name) و آدرس مشتری (customer_address) را در این روش آزمایش کرده‌ایم. بیایید 3 رویه را فرا بخوانیم.
در 2 فراخوانی اول، حداقل یک شرط ناموفق است و بنابراین دستور درج نشده است. در فراخوانی 3، همه چیز خوب بود، و ما یک ردیف جدید وارد کردیم.
گرچه این رویکرد به خوبی کار خواهد کرد، اما تغییرات زیادی وجود دارد که می‌توانید در اینجا انجام دهید:
- مجموعه دیگری از زیرلایه ها / کلمات کلیدی را که می‌خواهید در بدنه تابع عملکرد آزمایش کنید، انتخاب کنید.
- شما می‌توانید فقط در نسخه‌های خاص و کمی متفاوت، این مقادیر را امتحان کنید – به عنوان مثال، ما از %drop% استفاده کرده‌ایم و شاید برای شما drop% مفید باشد.
- همچنین می‌توانید مقادیر دیگر را قبل از انجام اقدامات آزمایش کنید. به عنوان مثال، شما می‌توانید آزمایش کنید که آیا مقداری عدد صحیح در مجموعه مقادیر مورد انتظار است (کلید خارجی مربوط به کلید اصلی در جدول مختلف است، مقدار عددی در برخی بازه‌ها قرار دارد) و خطاهای سفارشی را برای توصیف دقیق آنچه در اینجا اتفاق افتاده است افزایش دهید.
نتیجه گیری:
هیچ راه حلی مانند گلوله‌ای نقره‌ای در مورد چگونگی جلوگیری از حملات SQL Injection وجود ندارد. هنوز هم می‌توانید کارهای زیادی برای محافظت از خود انجام دهید. در این مقاله، ما در کنار سایر اقدامات امنیتی که می‌توانید انجام دهید، از روشی استفاده کرده‌ایم که می‌توانید انتخاب کنید. هنوز، به خاطر داشته باشید که رویکردها می‌توانند بسیار متفاوت باشند، در عین حال کاملاً مشابه (بیانیه‌های آماده شده، ORM). این‌ها همیشه به میل شما به نحوه مقابله با SQL Injection احتمالی بستگی ندارد بلکه به چندین فاکتور دیگر بستگی دارند، به عنوان مثال فناوری پشته‌ای که استفاده می‌کنید بنابراین، اگر تصمیم دارید با رویکرد SP پیش بروید، می‌توانید از آنچه در اینجا ذکر شد به عنوان ستون فقرات استفاده کنید و اگر روش دیگری را انتخاب کنید، می‌توانید از ایده کلی استفاده کنید.
توضیحات خود را بنویسید