در این بخش از مجموعه آشنایی با متدولوژی Burp Suite به بخش بیستم از این متدولوژی به استفاده از ابزار Burp Suite به منظور تشخیص SQL Injection از طریق دستکاری پارامترهای خاص SQL می پردازیم.
تشخیص SQL Injection از طریق دستکاری پارامترهای خاص SQL
در بارزترین موارد، یک نقص تزریق SQL ممکن است با ارائه یک آیتم ورودی غیرمنتظره به برنامه، کشف و به طور قطعی تأیید شود. البته در برخی موارد، اشکالات ممکن است بسیار ظریف بوده و تشخیص آن‌ها دشوار باشد. با این وجود، می‌توانید مراحل مختلف را به روشی منظم انجام دهید تا به طور قابل اعتماد اکثر آسیب پذیری های تزریق SQL را تأیید کنید.
اغلب می‌توان آسیب پذیری های ظریف تزریق SQL را با دستکاری پارامترها با استفاده از نحو یا Syntax خاص SQL و مشاهده تأثیرات روی پاسخ‌های برنامه، تشخیص داد.
Manual testing for numeric SQL-specific parameter manipulation
ابتدا، اطمینان حاصل کنید که Burp به درستی با مرورگر شما پیکربندی شده‌است.
در تب Burp Proxy، اطمینان حاصل کنید که در بخش Proxy و تب Intercept، عبارت Intercept is off نمایش داده شده باشد.
به صفحه ای از برنامه بروید که قصد تست آن را دارید.
به “Burp” برگردید.
در بخش Proxy و تب Intercept، اطمینان حاصل نمایید که Intercept is on تنظیم شده باشد.
در ادامه درخواستی را به سمت سرور ارسال نمایید. در این جا کافی است تا صفحه را Refresh نمایید.
درخواست ارسال شده، توسط ابزار Burp Suite به شما نمایش داده خواهد شد. پارامتری که ما قصد اکسپلویت آن را داریم، پارامتر id بوده که در URL قرار دارد.
بر روی درخواست، راست کلیک نموده و گزینه Send to Repeater را انتخاب کنید.
به تب Repeaterمراجعه کنید. در این قسمت و در بخش‌های Raw و Params امکان تغییر در مقدار پارامترها وجود دارد.
اولین قدم این است که مقدار موجود را به عدد دیگری تغییر دهید.
بدین صورت ما می‌توانیم اطمینان حاصل کنیم که آیا تغییر پارامتر بر برنامه تأثیر دارد یا خیر.
به منظور ارسال درخواست به سرور، بر روی دکمه Go کلیک نمایید.
نتایج درخواست را می‌توانید در بخشResponse ابزار Repeater مشاهده کنید.
در این مثال ما انتخاب کرده ایم که پاسخ را با استفاده از تب Render نشان دهیم.
ما به وضوح می بینیم که User ID، User name و Email تغییر کرده است و برنامه در حال نمایش جزئیات یک کاربر دیگر است.
بدین صورت، ما تأیید کرده ایم که برنامه از پارامتر id برای بازیابی داده‌های ذخیره شده استفاده می‌کند.
مرحله بعدی تشخیص این است که پارامتر به صورت محاسباتی هم کار می‌کند یا خیر.
در این بخش ما یک محاسبه را در پارامتر وارد می‌کنیم و پاسخ سرور را مورد بررسی قرار می‌دهیم.
در این مثال، مقدار 2-3 را ارائه می کنیم و برنامه اطلاعات “User id 1” را برمی گرداند. بنابراین برنامه به صورت محاسباتی نیز پارامتر را ارزیابی می‌کند.
این رفتار ممکن است به آسیب‌پذیری‌های مختلف از جمله تزریق SQL منجر شود.
مرحله بعدی این است که کلمات کلیدی و نحو خاص SQL را به پارامتر ارسال کنیم تا مقدار مورد نیاز را محاسبه نموده، در نتیجه بررسی شود که آسیب‌پذیری تزریق SQL وجود دارد.
یک مثال خوب استفاده از دستور ASCII است که کد ASCII عددی کاراکتر ارائه شده را برمی‌گرداند. در این مثال، چون مقدار ASCII کاراکتر یک عدد 49 می‌باشد، عبارت زیر معادل 1 در SQL است:
50-ASCII(1)
صفحه بدون هیچ خطایی نمایش داده می‌شود و جزئیات کاربر 1 را نشان می‌دهد. این به این دلیل است که ساختار دستوری SQL تزریق شده معادل مقدار 1 است
این موضوع نشان می‌دهد که برنامه، ورودی را به عنوان یک پرس و جو SQL ارزیابی می‌کند.
Manual testing for string based SQL-specific parameter manipulation
ابتدا، اطمینان حاصل کنید که Burp به درستی با مرورگر شما پیکربندی شده‌است.
در تب Burp Proxy، اطمینان حاصل کنید که در بخش Proxy و تب Intercept، عبارت Intercept is off نمایش داده شده باشد.
به صفحه ای از برنامه بروید که قصد تست آن را دارید.
به “Burp” برگردید.
در بخش Proxy و تب Intercept، اطمینان حاصل نمایید که Intercept is on تنظیم شده باشد.
در ادامه درخواستی را به سمت سرور ارسال نمایید. در این جا کافی است تا بر روی دکمه Help کلیک نمایید.
درخواست ارسال شده، توسط ابزار Burp Suite به شما نمایش داده خواهد شد. پارامتری که ما قصد اکسپلویت آن را داریم، پارامتر id بوده که در URL قرار دارد.
بر روی درخواست، راست کلیک نموده و گزینه Send to Repeater را انتخاب کنید.
به تب Repeater بروید. بر روی دکمه Go کلیک کنید تا درخواست به سرور ارسال شود.
شما می‌توانید پاسخ را در سمت مقابل بخش Repeater مشاهده نمایید.
در این قسمت و در بخش‌های Raw و Params امکان تغییر در مقدار پارامترها وجود دارد.
در این مثال ما یک حرف z را به مقدار پارامتر اضافه کرده ایم.
کاراکتر اضافی باعث تغییر در پاسخ از برنامه می‌شود.
این نشان می‌دهد که پارامتر جاری به منظور بازیابی محتوا مورد استفاده قرار می‌گیرد.
مرحله بعدی تأیید این است که مقدار پارامتر به عنوان یک پرس و جو SQL ارزیابی می‌شود یا خیر. بدین ترتیب احتمال وجود آسیب پذیری تزریق SQL تأیید می‌شود.
در این مثال مقدار پارامتر را از user-info.php به user’%20′-info.php تغییر داده ایم.
%20 معادل URL-encoded شده Space است که از این فاصله می‌توان برای به هم پیوستن رشته‌ها در برخی پایگاه‌های داده SQL استفاده کرد.
اگر اکنون پاسخ برنامه با پاسخ اصلی مطابقت داشته باشد، واضح است که برنامه در حال ارزیابی پارامتر در یک پرس و جوی SQL است.
در این مورد هیچ پیام خطایی یا تغییری در پاسخ وجود ندارد.
این موضوع نشان می‌دهد که ورودی به روشی ناامن در یک پرس و جوی SQL گنجانده شده است.
می‌توانیم این موضوع را در بخش Response تب Repeater یا با ارسال درخواست از طریق مرورگر به برنامه تأیید کنیم.
