تزریق SQL SQLi
حملهای به وبسایت که در آن کسی دستورهای پایگاه داده را در یک فرم یا آدرس وب مینویسد. سایت آنها را اجرا میکند و دادههایی را که باید از آنها محافظت کند فاش، عوض یا پاک میکند.
شناختهشده با نام SQLi SQL Injection حمله تزریق SQL تزریق کد SQL تزریق به پایگاه داده حمله تزریقی
تعریف
تزریق SQL چیست
یک فروشگاه اینترنتی دارید. بازدیدکنندهای چیز عجیبی در جعبه جستجو مینویسد، Enter را میزند و صفحه نام، شماره تلفن و سابقه سفارش همه مشتریانتان را به او نشان میدهد. کسی رمزی ندزدیده است. او کلمههای درست را در جای اشتباه نوشت و بقیه کار را سایت شما انجام داد. این همان تزریق SQL است.
بیشتر وبسایتها اطلاعاتشان را در یک پایگاه داده نگه میدارند: انباری مرتب از جدولها، کمی شبیه مجموعهای از صفحهگستردهها. سایت برای خواندن یا تغییر این اطلاعات از زبانی به نام SQL (Structured Query Language) استفاده میکند. به هر درخواستی که میفرستد یک پرسوجو میگویند، مثلاً «مشتریای را پیدا کن که این ایمیل را دارد».
تزریق SQL وقتی رخ میدهد که سایت چیزی را که بازدیدکننده نوشته، مستقیم داخل یکی از این پرسوجوها بگذارد. اگر بازدیدکننده بهجای متن معمولی SQL بنویسد، پایگاه داده فرقی نمیبیند و دستور مهاجم را طوری اجرا میکند که انگار خود سایت آن را نوشته است. خیلیها این اسم را کوتاه میکنند و میگویند SQLi.
حمله تزریق SQL چطور انجام میشود
کارمند بانکی را تصور کنید که هر یادداشتی را که مشتری به او میدهد، کلمه به کلمه به کارکنان خزانه میرساند. یادداشت معمولی میگوید «موجودیام را نشانم بدهید». یادداشت حقهباز میگوید «موجودیام را نشانم بدهید و همه صندوقها را هم باز کنید». اگر کارمند هیچوقت یادداشت را از قبل نخواند، کارکنان خزانه همان کار را میکنند.
در یک وبسایت، مراحل معمولاً اینطور است:
- مهاجم جایی را پیدا میکند که متن را به پایگاه داده میفرستد: فرم ورود، جعبه جستجو، فرم تماس یا خود آدرس وب، مثل صفحه محصولی که آدرسش با «?id=25» تمام میشود.
- بهجای متن معمولی، تکه کوچکی از SQL مینویسد. یک نمونه معروف، نوشتن ' OR '1'='1 در خانه رمز عبور یک فرم ورود است.
- سایت این متن را بدون بررسی به پرسوجوی خودش اضافه میکند. حالا پرسوجو چیزی شبیه این میپرسد: «اگر رمز درست است، یا اگر 1 مساوی 1 است، این شخص را راه بده».
- چون 1 همیشه مساوی 1 است، پایگاه داده جواب بله میدهد و مهاجم بدون دانستن هیچ رمزی وارد میشود.
بعضی حملهها بیصداترند. در تزریق SQL کور، صفحه هیچ دادهای نشان نمیدهد. پس مهاجم از پایگاه داده سؤالهایی با جواب بله یا نه میپرسد و نگاه میکند صفحه چه واکنشی نشان میدهد یا بارگذاریاش چقدر طول میکشد. انجام دستی این کار کند است، برای همین مهاجمان آن را به ابزارهای خودکار رایگان میسپارند.
مهاجم با آن چه کارهایی میتواند بکند
وقتی پایگاه داده از دستورهای او پیروی کند، اندازه آسیب به این بستگی دارد که حساب پایگاه داده سایت اجازه چه کارهایی را دارد. اغلب این اجازه خیلی بیشتر از نیاز سایت است. مهاجم ممکن است بتواند:
- دادههای خصوصی را بخواند، مثل نام، نشانی، ایمیل و سابقه سفارش مشتریان، پروندههای پزشکی یا رمزهای ذخیرهشده
- با حساب کاربر دیگری وارد شود، حتی مدیر سایت
- دادهها را تغییر دهد، مثل قیمتها، موجودیها یا وضعیت سفارشها
- جدولهای کامل یا کل پایگاه داده را پاک کند
- در بعضی پیکربندیها، به خود سرور برسد و فایلهای مخرب روی آن بگذارد
چرا این موضوع برای کسبوکار شما مهم است
تزریق SQL یکی از قدیمیترین حملههای وب است و هنوز هم وجود دارد. OWASP، یک جامعه باز که فهرست مشهور OWASP Top 10 از خطرهای برنامههای وب را منتشر میکند، سالهاست تزریق را در این فهرست نگه داشته است. امتحان کردنش آسان است و خیلی از سایتها هنوز یک فرم فراموششده دارند که راه را برایش باز میگذارد.
برای صاحب کسبوکار، ضرر واقعی بهندرت فنی است. ضرر یعنی فهرست مشتریانی که بیرون رفته، فروشگاهی که با قیمت اشتباه میفروشد، سامانه رزروی که نوبتهای یک هفته را از دست میدهد، یا پیامی که مجبورید برای مشتریان بفرستید تا بگویید دادههایشان فاش شده است. در بسیاری از کشورها، قانونهای حفاظت از داده مثل GDPR هم از شما میخواهند از دادههای شخصی محافظت کنید و نشت داده را گزارش دهید.
آیا همه فرمهای سایت شما با در نظر گرفتن این خطر ساخته شدهاند؟ سایتهایی که با افزونههای قدیمی و با عجله سرهم شدهاند، یا در طول سالها دست افراد زیادی به آنها خورده، بیشتر احتمال دارد نقطه ضعفی را پنهان کرده باشند.
چطور از سایت در برابر تزریق SQL محافظت کنیم
راهحل اصلی شناختهشده است و جواب میدهد. بیشتر محافظت به نحوه ساخت سایت برمیگردد، پس اینها سؤالهای خوبی برای پرسیدن از برنامهنویسان یا ارائهدهنده خدماتتان است.
- دستورهای آماده. به آنها پرسوجوی پارامتری هم میگویند. سایت پرسوجو و متن بازدیدکننده را جدا از هم میفرستد، پس پایگاه داده همیشه آن متن را فقط داده میبیند و هرگز دستور نمیداند. این دفاع اصلی است. فریمورکهای امروزی مثل Laravel وقتی برنامهنویسان از ابزارهای داخلی پایگاه دادهشان استفاده کنند، این کار را بهطور پیشفرض انجام میدهند.
- بررسی ورودیها. خانه شماره تلفن فقط باید عدد بپذیرد و خانه تاریخ فقط تاریخ. رد کردن ورودیهای عجیب در همان ابتدا درهای زیادی را میبندد.
- کمترین دسترسی. حسابی که سایت با آن به پایگاه داده وصل میشود، باید فقط دسترسیهایی را داشته باشد که لازم دارد. یک صفحه جستجوی عمومی هیچ دلیلی برای پاک کردن جدولها ندارد.
- پیامهای خطای کمحرف. یک خطای مفصل پایگاه داده روی صفحه، نقشه را دست مهاجم میدهد. به بازدیدکننده پیامی کوتاه و ساده نشان دهید و جزئیات را در گزارشهای خصوصی نگه دارید.
- بهروزرسانی. سکو، افزونهها و کتابخانهها را بهروز نگه دارید، چون نسخههای قدیمی اغلب حفرههای شناختهشده دارند.
- فایروال برنامههای وب. فیلتری است جلوی سایت که بسیاری از الگوهای شناختهشده حمله را پیش از رسیدن به کد شما مسدود میکند. کمک میکند، اما کد ناامن را تعمیر نمیکند.
- آزمایش منظم. تست نفوذ (حملهای امن و برنامهریزیشده که متخصصان انجام میدهند) و اسکن آسیبپذیری، نقطههای ضعف را پیش از مهاجم پیدا میکنند.
مقایسه چند عادت روزمره اینطور است:
| عادت پرخطر | عادت امنتر |
|---|---|
| چسباندن مستقیم متن بازدیدکننده به پرسوجو | استفاده از دستورهای آماده برای همه پرسوجوها |
| یک حساب پایگاه داده با همه دسترسیها برای همه کارها | یک حساب محدود برای هر بخش از سایت |
| نشان دادن کامل خطاهای پایگاه داده در صفحه | پیامی کوتاه برای بازدیدکننده، جزئیات در گزارشهای خصوصی |
| افزونههایی که ماهها بهروز نشدهاند | بهروزرسانی منظم و فهرستی روشن از همه چیزهای نصبشده |
| فقط آزمایش اینکه امکانات کار میکنند | آزمایش اینکه وقتی کسی چیزی مخرب مینویسد چه اتفاقی میافتد |
اشتباههای رایج
- اعتماد به بررسیهای داخل مرورگر. بررسیهایی که روی دستگاه خود بازدیدکننده اجرا میشوند بهراحتی دور زده میشوند، پس سرور باید همه چیز را دوباره بررسی کند.
- فکر اینکه سایت کوچک در امان است. ابزارهای خودکار تعداد بسیار زیادی سایت را بدون توجه به اندازهشان بررسی میکنند.
- درست کردن یک فرم و فراموش کردن بقیه. جعبه جستجو، فیلترها، آدرس وب و API پشت اپلیکیشن موبایل همه به یک اندازه مراقبت لازم دارند.
- نگه داشتن رمزها بهصورت متن ساده. اگر دادهها نشت کنند، رمزهایی که با هش قوی ذخیره شدهاند (یعنی به کدی درهم تبدیل شدهاند که نمیشود دوباره خواندش) خیلی سختتر سوءاستفاده میشوند.
- تکیه فقط بر فایروال. فیلتر برایتان وقت میخرد. پرسوجوی ناامن پشت آن را باز هم باید درست کرد.
چطور میتوانیم کمک کنیم
در Linkysoft، بررسی تزریق SQL بخشی از خدمات امنیت سایبری ماست. ما روی سایت، اپلیکیشن و API شما حملههای شبیهسازیشده و امن انجام میدهیم، کد را بازبینی میکنیم و فهرستی به زبان ساده از آنچه پیدا کردیم و راه درست کردنش به شما میدهیم. بعد از اصلاحها دوباره آزمایش میکنیم. این کار برای سایتهایی که تیمهای دیگر ساختهاند هم انجامشدنی است و بررسی امنیتی رایگان قدم اول آسانی است.
برای یک سیستم تازه برنامه دارید؟ برنامههای وب و سیستمهای مدیریتی ما از همان طراحی امن ساخته میشوند، با مقاومسازی بر اساس OWASP Top 10 و تست نفوذ پیش از راهاندازی.
پرسشهای متداول درباره تزریق SQL
تزریق SQL به زبان ساده چیست؟
آیا یک سایت کوچک هم ممکن است دچار تزریق SQL شود؟
از کجا بفهمم سایتم در برابر تزریق SQL آسیبپذیر است؟
بهترین راه جلوگیری از تزریق SQL چیست؟
آیا فایروال جلوی تزریق SQL را میگیرد؟
تزریق SQL کور چیست؟
اگر سایتم دچار تزریق SQL شد، چه کنم؟
آیا تزریق SQL فقط مشکل وبسایتهاست؟
هنوز مطمئن نیستید این موضوع چه ارتباطی با پروژه شما دارد؟
به ما بگویید چه چیزی میسازید و ما با زبانی ساده و روشن پاسخ خواهیم داد.