پایگاه داده فقط خواندنی است
تاکنون، ما هیچ کاری بجز پرس و جوی پایگاه داده انجام نداده ایم، و هرچند که یک دستور SELECT فقط خواندنی است، آن بدان معنا نیست که SQL هم فقط خواندنی می باشد. SQL برای خاتمه دستور از نقطه و ویرگول استفاده می کند، و اگر ورودی بطور صحیح حذف نگردد، شاید هیچ چیز وجود نداشته باشد که مانع از این شود که ما فرمان غیر مرتبطمان را در پایان پرس و جو رشته ای کنیم.
موثرترین نمونه هست:
SELECT email, passwd, login_id, full_name
FROM members
WHERE email= ‘x’; DROP TABLE members; --‘; Boom!
قسمت اول یک آدرس ایمیل ساختگی –‘x—را مهیا می کند و ما توجه نمی کنیم که این پرس و جو چه چیزی را برمی گرداند: ما تنها داریم آن را از این شیوه استنتاج می کنیم درنتیجه ما می توانیم یک فرمان SQL غیر مرتبط را معرفی نماییم. این یکی مبادرت به حذف جدول تمام اعضا می نماید، که واقعا خیلی منصفانه به نظر نمی رسد.
این نشان می دهد که نه تنها ما می توانیم دستورات مجزای SQL را اجراء کنیم، بلکه ما می توانیم بانک اطلاعاتی را نیز تغییر دهیم. این امید بخش است.
اضافه کردن یک عضو جدید
مشخص است که ما ساختار مختصری از جدول اعضا را می دانیم، آن شیوه ای موجه به نظر میرسد برای اضافه کردن یک رکورد جدید بدان جدول: اگر این شیوه عمل نماید، ما به سادگی قادر خواهیم بود با مجوزهای تازه درج شده امان مستقیما وارد صفحه شروع شویم.
این، نه بطور شگفت آور، یک کم SQL بیشتری را می طلبد، و ما بخاطر سهولت ارائه آن را روی چندین خط مخفی نموده ایم، اما بخش ما همچنین یک رشته پیوسته است:
SELECT email, passwd, login_id, full_name
FROM members
WHERE email= ‘x’;
INSERT INTO members(‘email’,’passwd’,’login_id’,’full_name’)
VALUES (‘steve@unixwiz.net’, ‘hello’, ‘steve’, ‘steve Friedl’);--‘;
حتی اگر ما واقعا نامهای جدول و فیلدمان را درست بدست آورده ایم، در روش هجوم موفق ما، چندین چیز می توانست حاصل گردد:
ما ممکن است برای وارد کردن این اندازه متن بطور مستقیم در فرم تحت وب، جای کافی نداشته باشیم )اگرچ با نسخه نویسی روی این کاری انجام میشود، آن از اطمینان کمتری برخوردار است(.
کاربر برنامه تحت وب ممکن است مجوز ورودINSERT در جدول اعضا نداشته باشد.
بدون شک فیلدهای دیگری در جدول اعضا وجود دارند، بعضی از آنها ممکن است به مقادیر اولیه نیاز داشته باشند که باعث میشود که باعث رد مجوز INSERT میشوند.
اگر هم ما رکورد جدیدی را وارد کنیم، خود برنامه ممکن است خوب عمل نکند بخاطر فیلدهای تهی خودکار درج شده ای که ما برای آنها مقادیری را فراهم نکردیم.
یک "عضو" معتبر ممکن است نه تنها به یک رکورد در جدول اعضا، بلکه به اطلاعات مربوطه در جداول دیگر نیاز دارد، از این رو اضافه کردن به یک جدول تنها ممکن است کافی نباشد.
در موضوع حاضر، ما در #4 یا #5 با مانعی برخورد می کنیم- ما واقعا نمی توانیم مطمئن باشیم—زیرا به هنگام رفتن به صفحه شروع اصلی)لاگ این( و وارد شدن در نام کاربری+کلمه عبور بالا، یک خطای سرور برگردانده شد. این بیانگر آن است که فیلدهایی که ما تعیین نکردیم بسیار ضروری بودند، اما با این وجود بطور درست بکار نرفتند.
یک شیوه ممکن در اینجا سعی می کند فیلدهای دیگر را حدس بزند، این شیوه نوید دهنده یک پروسه مشکل و طلانی مدت می باشد: هرچند ما ممکن است قادر باشیم فیلدهای "مشخص" دیگر را حدس بزنیم، تصور سازمان این برنامه بسیار سخت است.
ما بکار بردن یک راه متفاوت را متوقف کردیم.
یک کلمه عبور را برای من میل کنید
ما سپس دریافتیم که اگرچه ما قادر نیستیم رکورد جدیدی را به بانک اطلاعاتی اعضا اضافه کنیم، ما می توانیم بانک اطلاعاتی مجود را تغییر دهیم، و این شیوه ای بود که مدخلی را برای ما بدست آورده بود.
از یک مرحله قبل، ما فهمیدیم که
bob@example.com
اکانتی در آن سیستم داشت، و ما از تزریق SQL برای به روز کردن رکورد بانک اطلاعاتیش با آدرس ایمیلمان استفاده کردیم:
SELECT email, passwd, login_id, full_name
FROM members
WHERE email= ‘x’;
UPDATE members
SET email= steve@unixwiz.net
WHERE email= bob@example.com;
پس از اجرا کردن این، ما البته، پیغام "ما آدرس ایمیل شما را نمی دانستیم" را دریافت نمودیم، اما انتظار می رفت بخاطر آدرس ایمیل تسنعی بود که ساخته بودیم. UPDATE با آن برنامه عمل نمی کرد، لذا آن کاملا اجراء می گردید. ما سپس از پیوند معمولی"من کلمه عبورم را از دست دادم" با آدرس ایمیل به روز شده استفاده کردیم، یک دقیقه بعد این ایمیل را دریافت نمودیم:
از)فرستنده(: system@example.com
به)گیرنده(: steve@unixwiz.net
موضوع: ورود به شبکه داخلی(Intranet login)
این ایمیل در پاسخ به درخواست شما برای اطلاعات ورود به سیستم شبکه داخلی می باشد.
شناسه کاربریتان هست: bob
کلمه عبورتان هست: hello
اکنون حالا فقط موضوع پیگیری جریان استاندارد ورود به سیستم برای دست یابی به آن سیستم بعنوان یک کارمند عالی رتبه سیستم اطلاعات مدیریت مطرح بود و این برای یک کاربر شاید محدود بسیار عالی بود که ما با شیوه INSERT مان ممکن بود ایجاد کنیم.
ما دریافتیم که سایت شبکه داخلی کاملا جامع باشد، از بین چیزهای دیگر- آن شامل یک لیست از کلیه کاربران بود. این شرط خوبی است که بسیاری از سایتهای شبکه داخلی همچنین اکانتهایی در شبکه گروهی)مشارکتی( ویندوز دارند، و شاید برخی از آنها از کلمه عبور یکسانی در هر دو جا استفاده کرده اند. از اینرو، واضح است که ما یک راه آسانی را برای بازیابی کردن کلمه عبور شبکه داخلی داریم، و با وجودی که ما پورت شبکه خصوصی باز PPTP در دیوار آتشین گروهی قرار داده بودیم، مبادرت کردن به این گونه دست یابی باید آسان باشد.
ما یک بررسی موضعی روی تعدادی اکانت بدون موفقیت انجام داده بودیم، و ما واقعا نمی توانیم بفهمیم که آیا آن "یک کلمه عبور بد است" یا "نام اکانت شبکه داخلی از نام اکانت ویندوز فرق می کند". اما ما فکر می کنیم که ابزار مکانیزه بعضی از این کارها را می توانستند آسانتر انجام دهند.
شیوه های دیگر
در این کار بخصوص، ما دسترسی کافی پیدا کرده ایم که ما نیازی را احساس نمی کردیم برای بیشتر انجام دادن، اما گامهای دیگری می توانست برداشته شود. ما به اعمالی دست خواهیم زد که می توانیم حالا درموردشان بیندیشیم، هرچند ما کاملا مطمئن هستیم که این جامع و کامل نیست.
ما بعلاوه اطلاع داریم که تمام روشها با بانکهای اطلاعاتی عمل نمی کنند، و ما با بعضی از آنها)شیوه ها( در اینجا آشنا میشویم.
از xp_cmdshell استفاده کنید
نرم افزار SQL server شرکت مایکروسافت از یک پروسه گرد آمده xp_cmdshell که مجوز اندازه مقادیر را برای اجراء مطلق دستور صادر می نماید پشتیبانی می کند، و اگر این کار برای کاربر شبکه مجاز است، سازش کامل سرور شبکه اجتناب ناپذیر است.
آنچه که ما تاکنون انجام داده بودیم به برنامه تحت وب و پایگاه داده اصلی محدود گردید، اما اگر ما بتوانیم دستوراتی را اجراء کنیم، سرور شبه خودش نمی تواند کمک کند ولی سازگار میشود. دست یابی به xp_cmdshell معمولا به اکانتهای اجرائی محددود میشود، واگذار کردن آن به کاربران کمتر ممکن است.
