توضیح اساسی جملات SQL Injection

Mohsen_mahyar@yahoo.com

 

توضیح اساسی جملاتSQL Injection

Page 1 of 77 ( SQL Injection Tutorial by Dangerous Wolf

 

 )

Structured Query Language Injection توضیح اساسی جملات

SQL Injection Tutorial

Second Release

By Dangerous Wolf

به نام او که هر چه داریم از اوست

پیش گفتار:

بسیاری از محققان، دانشمندان و فلاسفه ، سال 2000 را سال دست یابی به آرمان های بلند و ماور ا طبیعی خود می دیدند . با این

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

نشد. هر چند تلاش های بسیاری صورت گرفت و دستاوردهای بسیاری حاصل شد، اما آن رویای دیرین بشر هیچ گاه به تحقق نپیوست .

لذا دانشمندا ن سال 2020 را سال آرمان های خود قرار داده و تا زمان موعود، اصل را بر تولید علم نهادند نه انتقال علم . با این حال

برای شروع، لازم است که فرد مقداری از طریق انتقال علم، ذهنیت و مهارت هایی اولیه، به دست آورد . پس از آن به تنهایی باید در این

دریای مواج و پر تلاط م به حرکت بپردازد . بر همین اصل یعنی انتقال علم (مهارت های اولیه تا حرفه ای) و نیز بنا بر درخواست های

نوشته و آنرا در جهت رفع مشکلات، عزیزان ارائه دهم. به هر حال SQL Injection حول مبحث Tutorial بسیاری بر آن شدم، تا یک

نباید فراموش کرد که تنها سیستمی را می تو ان از نظر امنیت مقداری در حد بالا در نظر گرفت که خاموش و از هم جدا باشد و در یک

محفظه فلزی از جنس تیتانیوم قفل و توسط امواج گاما احاطه و در انباری زیر زمینی با عمق 300 متر ، مدفون شده باش د و با گازهای

اعصاب و سربازان بسیار قوی جثه حول آن حفاظت شده باش د. حتی هنوز هم نمی توان گفت که امنیت ب ه صورت 100 درصد ، اِعمال

شده است . پس باید فکر عبارت صد در صد را در مباحث امنیتی به خصوص امنیت شبکه از سر بیرون کرد . همچنین باید خاطر نشان

را مورد SQL Injection کرد که این مقاله از 10 بخش مرتبط به هم تشکیل شده که هر کدام، از دیدگاه های مختلف ، مبحث

بحث و بررسی قرار می دهند . این نکته نیز باید ذکر شود که هر بخش بنابه دلایلی دارای مقدمه ای است . به هر حال هیچ گاه فراموش

و روش های مشابه آن انجام می شوند از ارزش کمتری برخوردار هستند. Injection نکنیم که حملاتی که از طریقِ سری حملاتِ

با تشکر از عزیزانی که در عین کار بسیار، حقیر را در ارائه این مجموعه یاری فرمودند:

James Marshall – The top admin of "Astalavista Security Committee"

Adrian Lamo – "H4G1S Destroying Group" – Became WhiteHat

Zinho – The top admin of "Hackers Center Committee"

Steve Example – Gold Member of "Unix Wizard"

IDESpinner – The top admin of "Cracking Is Life –cracking- Team"

Page 2 of 77 ( SQL Injection Tutorial by Dangerous Wolf )

بخش 1: مقدمه

ها برای آرشیوِ درخواستِ مبنی بر Dynamic Content های مدرن از جزئیات متحرک یا Web Application بسیاری از

خود استفاده می کنند . این قدرت تحرک معمولا به وسیله دریافت اطلاعات به روز از بانک اطلاعاتی آرشیو windowing برنامه های

می باشد و بسی اری از SQL ،(Web Data Store) ها برای ذخایراطلاعات در وب Platform میشوند. یکی از محبوب ترین

گزارش SQL که به سادگی از یک بانک اطلاعاتی (front-end-scripts) front-end ها اساسا بر اسکریپت های Web Application

شدن گزارش ها hijacking باعث عمل ،web application می گیرند، مبتنی هستند. یکی از موذیانه ترین حملات به یک Query و

و اطلاعات آن استفاده application برای دست یافتن به کنترل front-end scripts ها توسط Query می شود. که این گزارش ها یا

در میان SQL Injection شده اند. یکی از موثرترین مکانیزم ها برای آرشیو کردن آن استفاده از یک تکنیک است که تحت نام

نفوذگران استفاده میشود!

ها قلب یک وب سایت تجاری و بازرگانی هستند . یک حمله بر روی سرورهای بانک های Database بانک های اطلاعاتی یا

می تواند یک ضرر مالی بزرگ برای شرکت به دنبال داشته باشد . سرورهای بانک های اطلاعاتی Database Servers اطلاعاتی یا

هک می شوند و تنها یک حمله بر روی سرور کافی است تا از اعتبار (CC Info) معمولا برای بدست آوردن اطلاعات کردیت کارت

سایت کاسته شده و جمعیت سرازیر به سایت کم شوند همچنین کارمندان سایت خواستار امن و محرمانه شدن اطلاعات کارت های

اسکنرها شاید چنین result نامیده می شود (در MSSQL که Microsoft SQL اعتباری خود میشوند. بسیاری از سایت های دولتی از

هنوز کم و بیش در میان MSSQL . استفاده می کنند (Oracle DB Servers) Oracle نامی دیده باشید) و سرورهای بانک اطلاعاتی

آنلاین دیده می شوند چرا که قیمت آن بسیار پائین است، در صورتی که با قیمت های بالای سرورهای (Market) مراکز فروش

ادعا بر غیرقابل نفوذ بودن سرورهای خود می کرد . اما نف  وذگران به مبارزه Oracle روبرو میشویم !! چند وقت پیش Oracle

های بسیاری در آن یافتند! bug برخواستند (!!) و حفره ها و

Page 3 of 77 ( SQL Injection Tutorial by Dangerous Wolf )

بخش 2: توضیحات، حقه ها و نکات اساسی

تشخیص تزریق ها

به درستی عمل کند، بدیهی است که اولین گام، تشخیص آن است. برای انجام این کار، SQL Injection برای اینکه عملیات

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

هنوز باید توانایی جدا کردن صحیح (یک درخواست صحیح ) را از باطل (یک درخواست غیرمعتبر ) داشته application ، داده نمی شوند

مربوط می باشند یا SQL باشد و نفوذگر به راحتی می آموزد که چطور این آثار را بشناسد، خطاها را پیدا کند و تشخیص دهد آیا آنها به

خیر.

تشخیص خطاها

می تواند خطاها Web Application ابتدا، ما باید انواع خطاهایی که یک نفوذگر می تواند با آن مواجه شود را بشناسیم. یک

در اثر یک مشکل تولید می شود (وجود Web Server را در دو نوع عمده u1578 تولید کند . اولین نوع خطا آن است که به وسیله

'500: Internal Server ها تمامی موارد را مانند هم ثمر می دهند exception اگر دست نخورده باشند، این ! (exception

Error'

ها)، سبب می شوند که quote اشتباه تزریق شوند (براث مثال: نبستن syntax هایی که با SQL معمولا، تزریق

هایی هدایت شوند . یک exception این نوع از خطاها را بازگرداند . اگرچه، دیگر خطاها نیز ممکن است به یک چنین application

ساختگی عوض و HTML های پیش فرض مربوط به این خطا را با یک صفحه text فرآیند ساده برای جلوگ یری از خطا این است که

کنیم . اما با مشاهده کردن خطی که به عنوان جواب برگشت داده شده است خودش این حقیقت را آشکار می سازد که این replace

یک خطا از /در سرور می باشد . در دیگر موارد، تلاش های دیگری برای متوقف کردن خطاها انجام شده است و پاسخ نادرست ممکن

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

نمی دهد.

تولید می شود و معمولا به برنامه نویسی بهتری (application code) application دومین نوع از خطاها به وسیله کدهای

چشم داشت به موارد نامعتبر خاصی دارد و می تواند یک پیام خاص ساختگی را برای آنها ،Application ، اشاره دارد . در این مورد

نمایش دهد . اگرچه معمولا این نوع از خطاها باید به عنوان قسمتی از یک جواب معتبر ( 200 ) بازگشت داده شوند، همچنین ممکن است

شوند. replace هستند، عوض و Internal Server Error ها یا دیگر وسایل اخفا که بسیار شبیه redirect آنها با

یک مثال ساده می تواند فرق بین این دو نوع را بازگو کند:

آنها را از هم جدا ن  گه B و A برای کارهای بازرگانی را پیش خود مجسم کنیم که با نام های application بیایید دو

استفاده می کنند . این صفحه انتظار دارد که یک proddetails.asp ها از یک صفحه با نام application می داریم . هر دوی این

دریافت کند . این صفحه بعد از دریافت این پارامتر، جزئیات محصول را از بانک اطلاعاتی بردا شت می کند، ProdID پارامتر را با نما

را proddetails.asp ، ها application انجام می دهد. هر دوی این ،(returned) سپس، بعضی دستکاری ها را روی رکورد بازگشته

با همین مورد قانع و Application A . باشد valid باید همیشه معتبر و ProdID ، تنها از یک لینک فراخوانی می کنند، بنابراین

برقرار می کند، ProdID متقاعد خواهد بو د و هیچ بررسی اضافی را انجام نخواهد داد . هنگامی که یک نفوذگر کنش و واکنش پنهانی با

خالی برگشت داده می شود . recordset می کند که هیچ ردیفی در جدول بر طبق آن وجود ندارد، در نتیجه آن یک insert را ID یک

Page 4 of 77 ( SQL Injection Tutorial by Dangerous Wolf )

خالی را انتظار نداشته است، هنگامی که تلاش می کند اطلاعات را در رکورد recordset یک Application A ، به دلیل اینکه

500 ' می باشد . اما، : Internal Server Error' محتمل بر وقوع u1582 خواهد بود که شبیه تولید یک exception دستکاری کند، یک

اندازه و ظرفیت آن بیشتر از 0 باشد . اگر این ،recordset بررسی می کند که قبل از هر گونه دستکاری در ،Application B

ظاهر می شود که ادعا دارد چنین محصولی وجود ندارد . یا اگر برنامه 'No such Product' مورد صادق نباشد، یک پیام به صورت

نویس بخواهد خطا را مخفی کند، می تواند کاربر را در صورت پیشامد این خطا، مجددا به همان لیست محصولا ت بازگرداند . یک نفوذگر

چشم بسته را انجام ندهد. بنابراین، نخست سعی می کند چندین درخواست نامعتبر و SQL Injection تلاش می کند که یک عملیات

با خطاها دست و پنجه نرم می کند (!!!) و همچنین از آن هنگامی که یک خطای application تولید کند و بفهمد که چطور invalid

اتفاق می افتد، چه انتظاری دارد. SQL

تعیین محل کردن خطاها

نفوذگر اکنون می تواند به دومین گام از حمله پیش برود، که آن تعیین ،Application با در دست داشتن اطلاعاتی درباره

SQL محل کردن خطاهایی است که نتیجه ورودی های دستکاری شده هستند . به این منظور، آزمایش های عادی تکنیک های

و ... . همچنین OR, AND: ها مثل SQL Keyword یا SQL انجام می شوند، از قبیل : اضافه کردن کلمات کلیدی Injection

ها مثل ; یا ' !! META Character اضافه کردن

هر پارامتر به طور مجزا تست می شود و جواب به دقت برای تعیین کردن اینکه آیا یک خطا اتفاق افتاده است، امتحان می

ها و دیگر خطاهای redirect یا ابزاری از این قبیل، شناختن Intercepting Proxy شود. با استفاده از قطع کردن یک پراکسی یا

مخفی فرضی راحت خواهد بود . هر پارامتر که یک خطا را برمی گرداند، مشکوک خواهد بود . مشکوک بر این که شاید یک آسیب

می باشد، valid باشد. همچنان، همه پارامترها به صورت جدا با فرض اینکه این درخواست معتبر و SQL Injection پذیری برای

تست و آزمایش می شوند . این کار در این مورد بسیار مهم می باشد، چنانکه این فرآیند باید تمامی علل ممکن برای خطاها را متفاوت از

خنثی کند . نتیجه این فرآیند معمولا یک لیست طویل از پارامترهای مشکوک خواهد بود . بعضی از این پارامترها شاید ،injection خود

/ 0 نظر / 34 بازدید