تزریق SQL SQLi

حمله‌ای به وب‌سایت که در آن کسی دستورهای پایگاه داده را در یک فرم یا آدرس وب می‌نویسد. سایت آن‌ها را اجرا می‌کند و داده‌هایی را که باید از آن‌ها محافظت کند فاش، عوض یا پاک می‌کند.

  • Cybersecurity

شناخته‌شده با نام

تعریف

تزریق SQL چیست

یک فروشگاه اینترنتی دارید. بازدیدکننده‌ای چیز عجیبی در جعبه جستجو می‌نویسد، Enter را می‌زند و صفحه نام، شماره تلفن و سابقه سفارش همه مشتریانتان را به او نشان می‌دهد. کسی رمزی ندزدیده است. او کلمه‌های درست را در جای اشتباه نوشت و بقیه کار را سایت شما انجام داد. این همان تزریق SQL است.

بیشتر وب‌سایت‌ها اطلاعاتشان را در یک پایگاه داده نگه می‌دارند: انباری مرتب از جدول‌ها، کمی شبیه مجموعه‌ای از صفحه‌گسترده‌ها. سایت برای خواندن یا تغییر این اطلاعات از زبانی به نام SQL (Structured Query Language) استفاده می‌کند. به هر درخواستی که می‌فرستد یک پرس‌وجو می‌گویند، مثلاً «مشتری‌ای را پیدا کن که این ایمیل را دارد».

تزریق SQL وقتی رخ می‌دهد که سایت چیزی را که بازدیدکننده نوشته، مستقیم داخل یکی از این پرس‌وجوها بگذارد. اگر بازدیدکننده به‌جای متن معمولی SQL بنویسد، پایگاه داده فرقی نمی‌بیند و دستور مهاجم را طوری اجرا می‌کند که انگار خود سایت آن را نوشته است. خیلی‌ها این اسم را کوتاه می‌کنند و می‌گویند SQLi.

حمله تزریق SQL چطور انجام می‌شود

کارمند بانکی را تصور کنید که هر یادداشتی را که مشتری به او می‌دهد، کلمه به کلمه به کارکنان خزانه می‌رساند. یادداشت معمولی می‌گوید «موجودی‌ام را نشانم بدهید». یادداشت حقه‌باز می‌گوید «موجودی‌ام را نشانم بدهید و همه صندوق‌ها را هم باز کنید». اگر کارمند هیچ‌وقت یادداشت را از قبل نخواند، کارکنان خزانه همان کار را می‌کنند.

در یک وب‌سایت، مراحل معمولاً این‌طور است:

  1. مهاجم جایی را پیدا می‌کند که متن را به پایگاه داده می‌فرستد: فرم ورود، جعبه جستجو، فرم تماس یا خود آدرس وب، مثل صفحه محصولی که آدرسش با «?id=25» تمام می‌شود.
  2. به‌جای متن معمولی، تکه کوچکی از SQL می‌نویسد. یک نمونه معروف، نوشتن ' OR '1'='1 در خانه رمز عبور یک فرم ورود است.
  3. سایت این متن را بدون بررسی به پرس‌وجوی خودش اضافه می‌کند. حالا پرس‌وجو چیزی شبیه این می‌پرسد: «اگر رمز درست است، یا اگر 1 مساوی 1 است، این شخص را راه بده».
  4. چون 1 همیشه مساوی 1 است، پایگاه داده جواب بله می‌دهد و مهاجم بدون دانستن هیچ رمزی وارد می‌شود.

بعضی حمله‌ها بی‌صداترند. در تزریق SQL کور، صفحه هیچ داده‌ای نشان نمی‌دهد. پس مهاجم از پایگاه داده سؤال‌هایی با جواب بله یا نه می‌پرسد و نگاه می‌کند صفحه چه واکنشی نشان می‌دهد یا بارگذاری‌اش چقدر طول می‌کشد. انجام دستی این کار کند است، برای همین مهاجمان آن را به ابزارهای خودکار رایگان می‌سپارند.

مهاجم با آن چه کارهایی می‌تواند بکند

وقتی پایگاه داده از دستورهای او پیروی کند، اندازه آسیب به این بستگی دارد که حساب پایگاه داده سایت اجازه چه کارهایی را دارد. اغلب این اجازه خیلی بیشتر از نیاز سایت است. مهاجم ممکن است بتواند:

  • داده‌های خصوصی را بخواند، مثل نام، نشانی، ایمیل و سابقه سفارش مشتریان، پرونده‌های پزشکی یا رمزهای ذخیره‌شده
  • با حساب کاربر دیگری وارد شود، حتی مدیر سایت
  • داده‌ها را تغییر دهد، مثل قیمت‌ها، موجودی‌ها یا وضعیت سفارش‌ها
  • جدول‌های کامل یا کل پایگاه داده را پاک کند
  • در بعضی پیکربندی‌ها، به خود سرور برسد و فایل‌های مخرب روی آن بگذارد

چرا این موضوع برای کسب‌وکار شما مهم است

تزریق SQL یکی از قدیمی‌ترین حمله‌های وب است و هنوز هم وجود دارد. OWASP، یک جامعه باز که فهرست مشهور OWASP Top 10 از خطرهای برنامه‌های وب را منتشر می‌کند، سال‌هاست تزریق را در این فهرست نگه داشته است. امتحان کردنش آسان است و خیلی از سایت‌ها هنوز یک فرم فراموش‌شده دارند که راه را برایش باز می‌گذارد.

برای صاحب کسب‌وکار، ضرر واقعی به‌ندرت فنی است. ضرر یعنی فهرست مشتریانی که بیرون رفته، فروشگاهی که با قیمت اشتباه می‌فروشد، سامانه رزروی که نوبت‌های یک هفته را از دست می‌دهد، یا پیامی که مجبورید برای مشتریان بفرستید تا بگویید داده‌هایشان فاش شده است. در بسیاری از کشورها، قانون‌های حفاظت از داده مثل GDPR هم از شما می‌خواهند از داده‌های شخصی محافظت کنید و نشت داده را گزارش دهید.

آیا همه فرم‌های سایت شما با در نظر گرفتن این خطر ساخته شده‌اند؟ سایت‌هایی که با افزونه‌های قدیمی و با عجله سرهم شده‌اند، یا در طول سال‌ها دست افراد زیادی به آن‌ها خورده، بیشتر احتمال دارد نقطه ضعفی را پنهان کرده باشند.

چطور از سایت در برابر تزریق SQL محافظت کنیم

راه‌حل اصلی شناخته‌شده است و جواب می‌دهد. بیشتر محافظت به نحوه ساخت سایت برمی‌گردد، پس این‌ها سؤال‌های خوبی برای پرسیدن از برنامه‌نویسان یا ارائه‌دهنده خدماتتان است.

  • دستورهای آماده. به آن‌ها پرس‌وجوی پارامتری هم می‌گویند. سایت پرس‌وجو و متن بازدیدکننده را جدا از هم می‌فرستد، پس پایگاه داده همیشه آن متن را فقط داده می‌بیند و هرگز دستور نمی‌داند. این دفاع اصلی است. فریم‌ورک‌های امروزی مثل Laravel وقتی برنامه‌نویسان از ابزارهای داخلی پایگاه داده‌شان استفاده کنند، این کار را به‌طور پیش‌فرض انجام می‌دهند.
  • بررسی ورودی‌ها. خانه شماره تلفن فقط باید عدد بپذیرد و خانه تاریخ فقط تاریخ. رد کردن ورودی‌های عجیب در همان ابتدا درهای زیادی را می‌بندد.
  • کمترین دسترسی. حسابی که سایت با آن به پایگاه داده وصل می‌شود، باید فقط دسترسی‌هایی را داشته باشد که لازم دارد. یک صفحه جستجوی عمومی هیچ دلیلی برای پاک کردن جدول‌ها ندارد.
  • پیام‌های خطای کم‌حرف. یک خطای مفصل پایگاه داده روی صفحه، نقشه را دست مهاجم می‌دهد. به بازدیدکننده پیامی کوتاه و ساده نشان دهید و جزئیات را در گزارش‌های خصوصی نگه دارید.
  • به‌روزرسانی. سکو، افزونه‌ها و کتابخانه‌ها را به‌روز نگه دارید، چون نسخه‌های قدیمی اغلب حفره‌های شناخته‌شده دارند.
  • فایروال برنامه‌های وب. فیلتری است جلوی سایت که بسیاری از الگوهای شناخته‌شده حمله را پیش از رسیدن به کد شما مسدود می‌کند. کمک می‌کند، اما کد ناامن را تعمیر نمی‌کند.
  • آزمایش منظم. تست نفوذ (حمله‌ای امن و برنامه‌ریزی‌شده که متخصصان انجام می‌دهند) و اسکن آسیب‌پذیری، نقطه‌های ضعف را پیش از مهاجم پیدا می‌کنند.

مقایسه چند عادت روزمره این‌طور است:

عادت پرخطرعادت امن‌تر
چسباندن مستقیم متن بازدیدکننده به پرس‌وجواستفاده از دستورهای آماده برای همه پرس‌وجوها
یک حساب پایگاه داده با همه دسترسی‌ها برای همه کارهایک حساب محدود برای هر بخش از سایت
نشان دادن کامل خطاهای پایگاه داده در صفحهپیامی کوتاه برای بازدیدکننده، جزئیات در گزارش‌های خصوصی
افزونه‌هایی که ماه‌ها به‌روز نشده‌اندبه‌روزرسانی منظم و فهرستی روشن از همه چیزهای نصب‌شده
فقط آزمایش اینکه امکانات کار می‌کنندآزمایش اینکه وقتی کسی چیزی مخرب می‌نویسد چه اتفاقی می‌افتد

اشتباه‌های رایج

  • اعتماد به بررسی‌های داخل مرورگر. بررسی‌هایی که روی دستگاه خود بازدیدکننده اجرا می‌شوند به‌راحتی دور زده می‌شوند، پس سرور باید همه چیز را دوباره بررسی کند.
  • فکر اینکه سایت کوچک در امان است. ابزارهای خودکار تعداد بسیار زیادی سایت را بدون توجه به اندازه‌شان بررسی می‌کنند.
  • درست کردن یک فرم و فراموش کردن بقیه. جعبه جستجو، فیلترها، آدرس وب و API پشت اپلیکیشن موبایل همه به یک اندازه مراقبت لازم دارند.
  • نگه داشتن رمزها به‌صورت متن ساده. اگر داده‌ها نشت کنند، رمزهایی که با هش قوی ذخیره شده‌اند (یعنی به کدی درهم تبدیل شده‌اند که نمی‌شود دوباره خواندش) خیلی سخت‌تر سوءاستفاده می‌شوند.
  • تکیه فقط بر فایروال. فیلتر برایتان وقت می‌خرد. پرس‌وجوی ناامن پشت آن را باز هم باید درست کرد.

چطور می‌توانیم کمک کنیم

در Linkysoft، بررسی تزریق SQL بخشی از خدمات امنیت سایبری ماست. ما روی سایت، اپلیکیشن و API شما حمله‌های شبیه‌سازی‌شده و امن انجام می‌دهیم، کد را بازبینی می‌کنیم و فهرستی به زبان ساده از آنچه پیدا کردیم و راه درست کردنش به شما می‌دهیم. بعد از اصلاح‌ها دوباره آزمایش می‌کنیم. این کار برای سایت‌هایی که تیم‌های دیگر ساخته‌اند هم انجام‌شدنی است و بررسی امنیتی رایگان قدم اول آسانی است.

برای یک سیستم تازه برنامه دارید؟ برنامه‌های وب و سیستم‌های مدیریتی ما از همان طراحی امن ساخته می‌شوند، با مقاوم‌سازی بر اساس OWASP Top 10 و تست نفوذ پیش از راه‌اندازی.

پرسش‌های متداول درباره تزریق SQL

تزریق SQL به زبان ساده چیست؟
ترفندی است که در آن کسی دستورهای پایگاه داده را در فرم سایت یا آدرس وب می‌نویسد. اگر سایت این متن را بررسی نکند، پایگاه داده دستورها را اجرا می‌کند. آن وقت مهاجم می‌تواند داده‌ها را بخواند، عوض کند یا پاک کند.
آیا یک سایت کوچک هم ممکن است دچار تزریق SQL شود؟
بله. بیشتر حمله‌ها از ابزارهای خودکاری می‌آیند که سایت‌ها را بدون توجه به اندازه‌شان، به‌طور تصادفی بررسی می‌کنند. هر سایتی که فرم، جعبه جستجو یا پایگاه داده‌ای پشت خود دارد، می‌تواند هدف باشد.
از کجا بفهمم سایتم در برابر تزریق SQL آسیب‌پذیر است؟
مطمئن‌ترین راه، تست نفوذ یا اسکن آسیب‌پذیری توسط کسانی است که می‌دانند دنبال چه بگردند. آن‌ها حمله را به‌شکلی امن امتحان می‌کنند و می‌گویند کدام صفحه‌ها در خطرند. دیدن خطاهای عجیب پایگاه داده در صفحه‌های سایت هم یک نشانه هشدار است.
بهترین راه جلوگیری از تزریق SQL چیست؟
برای هر پرس‌وجوی پایگاه داده از دستورهای آماده (Prepared Statements) استفاده کنید که به آن‌ها پرس‌وجوی پارامتری هم می‌گویند. این روش متن بازدیدکننده را از دستور جدا نگه می‌دارد، پس پایگاه داده هرگز آن را اجرا نمی‌کند. کنار آن، بررسی ورودی‌ها، محدود کردن دسترسی‌های پایگاه داده و به‌روزرسانی منظم را هم اضافه کنید.
آیا فایروال جلوی تزریق SQL را می‌گیرد؟
فایروال برنامه‌های وب بسیاری از الگوهای شناخته‌شده حمله را مسدود می‌کند و لایه اضافی خوبی است. اما کد ناامنِ پشت سرش را درست نمی‌کند و مهاجمان مدام راه‌های تازه‌ای برای دور زدن فیلترها پیدا می‌کنند. خود کد باید امن باشد.
تزریق SQL کور چیست؟
نوعی از این حمله است که در آن صفحه هیچ داده‌ای از پایگاه داده نشان نمی‌دهد. مهاجم سؤال‌هایی با جواب بله یا نه می‌پرسد و می‌بیند صفحه چطور تغییر می‌کند یا پاسخ دادنش چقدر طول می‌کشد. کندتر است، اما باز هم می‌تواند محتوای پایگاه داده را لو بدهد.
اگر سایتم دچار تزریق SQL شد، چه کنم؟
حمله را متوقف کنید یا بخش آسیب‌دیده را از دسترس خارج کنید، بعد پرس‌وجوی ضعیف را پیدا و درست کنید. رمزها و کلیدها را عوض کنید، بررسی کنید چه داده‌هایی خوانده یا تغییر داده شده و در صورت نیاز داده‌های سالم را از نسخه پشتیبان برگردانید. بسته به قانون کشوری که در آن کار می‌کنید، شاید لازم باشد به مشتریانتان هم خبر بدهید.
آیا تزریق SQL فقط مشکل وب‌سایت‌هاست؟
نه. اپلیکیشن‌های موبایل، برنامه‌های کامپیوتری و هر سیستمی که متن کاربر را به پایگاه داده SQL می‌فرستد، ممکن است همین ضعف را داشته باشد. در اپلیکیشن‌ها خطر معمولاً در API است، یعنی اتصالی که اپلیکیشن با آن با سرورش حرف می‌زند.

هنوز مطمئن نیستید این موضوع چه ارتباطی با پروژه شما دارد؟

به ما بگویید چه چیزی می‌سازید و ما با زبانی ساده و روشن پاسخ خواهیم داد.