پشتیبانی: 09131253620
ارتباط با ما
تلگرام: 09131253620


یکی دیگر از خدمات ما طراحی وب سایتهای واکنشگرا یا Responsive با کیفیت بالا می باشد. برای طراحی این وب سایتها از تکنولوژیهای روز دنیا استفاده می شود.


       
صفحه اصلی  |  فروشگاه ما  |  نرم افزار مدیریت برنامه غذایی رستوران ها  |  seo تضمینی اصفهان  |  ثبت نام  |  طراحی وب سایت در اصفهان  |  برنامه نویسی اصفهان  |  انجام پروژه های پایگاه داده SQL Server  |  انجام پروژه مهندسی نرم افزار  |  انجام پروژه های مالتی مدیا بیلدر  |  در مورد ما  |  انجام پروژه های اکسس Microsoft access  |  نمونه پروژه ها  |  ارتباط با ما  |  اخبار و مقاله  |  انجمن رفع اشکالات مشتریان
برجسته ترین ها
گروه های مقاله ها
HyperLink


چگونه فروشگاه اینترنتی بسازیم بخش نهم تاریخ درج: ١٣٩۴/٠٨/١٧

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

تزریق SQL یک روش حمله است که هدف آن داده های ساکن در یک پایگاه داده می باشد که از طریق FireWall محافظت می شود. حمله معمولا به علت مدیریت ضعیف در اعتبار سنجی کدها و یا ورودیهای برنامه (وب سایت) اتفاق می افتد. حملات تزریق SQL زمانی اتفاق می افتد که یک مهاجم قادر به قرار دادن یک سری از عبارات SQL در یک Query (پرس و جو) با دستکاری داده های ورودی کاربر در یک برنامه مبتنی بر وب می باشد. البته این مساله نیز مستقیما به نحوه مدیریت کدها و ورودیهای وب سایت رابطه مستقیم دارد.
یک حمله کننده می تواند از نقصهای برنامه نویسی و یا حفره های امنیتی وب سایت و یا نرم افزار به راحتی برای دستیابی به اطلاعات یک پایگاه داده استفاده نماید.
زبان ساخت یافته پروس و جو (SQL) در حقیقت زبانی است که برنامه نویسها از آن برای ارتباط با پایگاه داده استفاده می نمایند. به عنوان مثالی ساده تر می توان SQL را مانند دستورات پیشرفته در نرم افزار Excel در نظر گرفت. پرس و جوی معمول دارای چند بخش مختلف به شرح ذیل می باشد:
1- دستور Select: با استفاده از این دستور ستونهایی که مورد نظرمان است را انتخاب می نمائیم. 
2- From : که مشخص می نماید که ستونهای مورد نظر ما از کدام جدول انتخاب شوند
3- Where: که در آن شروطی را مشخص می نمائیم.
4- و یک سری دستورات و عبارات و متدهای دیگر . . .
حملات تزریق از طریق SQL فقط در بخش شرطی Where اتفاق می افتند. در ادامه توضیح خواهیم داد که این مساله چگونه رخ می دهد.

تزریق SQL به چه صورتی اتفاق می افتد
تزریق اس کیو ال معمولا توسط یک پرس و جوی ساده اتفاق می افتد. این بدان معناست که صفحه وب بایستی از طریق یک فیلد متنی و یا . . . بایستی به پایگاه داده مرتبط باشد. معمولا برنامه های وب  بیس دارای گزینه های بسیار زیادی برای اتصال به پایگاه داده از طریق صفحات و فرمهای وبی می باشند که به راحتی می تواان دستورات را از طریق این صفحات به سمت پایگاه داده ارسال نمود.  
یک پرس و جوی ساده در هنگام ارسال به سمت Server مربوط به دیتابیس بایستی دارای ساختاری به شکل زیر باشد. [10]
String Str_SQLQuery = ("SELECT cola, colb FROM table WHERE cola = 'foo'");
پیاده سازی تزریق برای این پرس و جو از طریق توابع کمی مشکل به نظر می آید. در حال حاضر هیچ راهی برای تزریق SQL در پرس و جوی فوق وجود ندارد.
در مثال بعدی یک نمونه از پرس و جو که امکان تزریق SQL در آن وجود دارد را مورد بررسی قرار می دهیم:
$user_name = $_GET[‘username’];
$password = $_GET[‘password’];
$result = mysql_query(“SELECT * FROM members WHERE user_name=’{$user_name}’ AND password = ‘{$password}’”, $link);
در کدهای فوق نام کاربری و کلمه عبور توسط فیلدهای متنی دریافت شده و با کدهای SQL ترکیب می شوند. در این مرحله نشان می دهیم که چگونه تزریق اس کیو ال از طریق فیلدهای متنی امکان پذیرمی باشد. به متنهایی که با رنگ قرمز و سبز مشخص شده اند کاملا دقت فرمائید. موردی که ما در حالت عادی استنباط می کنیم این است که یک شخص برای Login فیلدهای متنی را پرکرده و Login می نماید. (بر روی کلید Login کلیک می نماید)
فرض می کنیم پس از کلیک بر رو Login عملیات به صورت ذیل انجام شود:
 
البته این نوع دسترسی بسیار کار غیر معقولی می باشد. با استفاده از متدهای موجود در زبانهای برنامه نویسی می توان به نام کاربری و کلمه عبور موجود در URL فوق دسترسی داشت. بنایر این یک کاربر می تواند بخشی از کد SQL را به این لینک به شکل ذیل در فیلد متنی اضافه نماید:
User Name: peter
Password: ’;DELETE FROM members WHERE user_name <> ‘
و پس از کلیک بر روی کلید Login شکل دستور SQL ماند ذیل به سمت Server ارسال خواهد شد:
$result = mysql_query(“SELECT * FROM members WHERE user_name=’peter’ AND password = ‘’;DELETE FROM members WHERE user_name <> ‘’”, $link);
مساله ناراحت کننده ای پیش می آید و رخ دادن یک حمله به Database خواهد بود.
جلوگیری اولیه از حمله تزریق نوع اول
به عنوان یک برنامه نویس بایستی کاملا به کدهای برنامه مسلط باشید و باید کاملا بدانید که چه نوع داده هایی بایستی در سمت Server دریافت می شوند. بایستی دقیقا بدانیم که داده های ورودی ما دارای چه نوع قالبی می باشند. به این صورت به راحتی می توانیم در مقابل خیلی از حملات ایستادگی نمائیم.

داده های ورودی از نوع عددی
در صورتی که داده های ورودی کاملا به صورتی عددی می باشند ، از فانکشنهای آماده برای تعیین نوع داده استفاده نکنید. معمولا توابع قابل اعتماد نیستند. اگر نوع واقعا نیاز به بررسی داشته باشد ، می توانید از اسکریپتهای بخش Client برای چک نوع عددی(Validator) استفاده نمائید. این روش هم ساده تر بوده هم از نظر امنیتی بهتر می باشد هر چند این روش امنیت کامل را تضمین نمی نماید.

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

بررسی نقاط ضعف در پرس و جو
معمولا اگر پرس و جو ها دارای نقاط ضعف باشند حمله کنندگان به راحتی می توانند از این ضعف استفاده کرده و به اطلاعات سیستم دسترسی داشته باشند. به چند مثال زیر توجه فرمائید:
query = ”SELECT * FROM accounts WHERE name = ’”
+ request.getParameter(”name”)
+ ”’ AND password=’”
+ request.getParameter(”pass”) + ”’”;
در مثال فوق پارامترهای name و pass از متن کدهای برنامه و توسط کاربر وارد شده و دریافت می شوند. پس از ارسال پارامترها در صورتی که کدی تزریق شده باشد شکل پرس و جو به صورت زیر خواهد بود:
SELECT * FROM accounts WHERE name = ’badguy’
AND password = ’’ OR ’a’ = ’a’
و در مثالی دیگر:
query = ”SELECT cardnum FROM accounts”
+ ” WHERE uname=’” + sanitizedName + ”’”
+ ” AND cardtype=” + sanitizedCardType ”;”;
پس ورود پارامتر توسط کاربر پرس و جوی اصلی به شکل زیر در خواهد آمد:
SELECT cardnum FROM accounts
WHERE uname = ’foo’ AND cardtype = 1
OR id = (SELECT id FROM accounts)
اجازه گذر
ساده ترین روش برای تزریق sql ، انواع اشکال ورود به گذرگاه است. کدهای نرم افزاری زیر را بررسی کنید:
 کدهای نرم افزاری 
 
در این جا چه اتفاقی می افتد وقتی که کاربر ، یک نام کاربری و رمز عبور ارائه کند. پرس و جو ، از طریق فهرست کاربران به جستجوی ردیفی می پردازد که نام کاربری و رمز عبور در آن ، با نام کاربری و رمز عبوری که ارائه کرده است مطابقت داشته باشد. اگر چنین ردیفی را پیدا کرد ، نام کاربری در متغیر strAutheck ، ذخیره می شود ، که نشان دهنده ی این است که کاربر تایید شده است. اگر هیچ ردیفی وجود نداشت که داده ها با آن مطابقت داشته باشند ، strAtuthcheck ، خالی می شود و کاربر تایید نمی شود. اگر نام کاربری و رمز عبور ، شامل هیچ کاراکتری که شما بخواهید نباشند ، شما می توانید ساختار پرس و جوی sql را ، اصلاح کنید ، به این دلیل که یک نام معتبر توسط پرس و جو بازگشت شود ، حتی اگر شما نام کاربری معتبر و یا رمز عبور را نمی دانید. چطور؟ اجازه دهید که به یک کاربر بگوییم که فرم ورودی مثل زیر را پر کند : 
Login : ' oR "='
Password : ' oR "='
پرس و جوی sql زیر ؛ ارائه می شود: 
SELECT username FROM users WHERE username = " OR "=" AND password = " OR "="
به جای مقایسه کردن داده های ارائه شده کاربر با فهرست کاربران ، پرس و جو به مقایسه یک عبارت (هیچ ) با عبارت دیگر (هیچ)  می پردازد. این ، البته ، همیشه درست بازگشت می شود. ( لطفا توجه داشته باشید که هیچ با صفر ، فرق دارد). از آن جا که همه ی شرایط مقدماتی در عبارت where ، در نظر گرفته می شوند ؛ نرم افزار ، نام کاربری را ، از اولین ردیف فهرست یافت شده ، انتخاب می کند. و  نام کاربری را به strAuthchech ، عبور می دهد تا به تایید اعتبار ما بپردازد. همچنین ، ممکن است که با استفاده از روش های چرخشی ، به استفاده از داده های ردیف دیگر ، بپردازیم ، که بعدا در مورد آن بحث خواهیم کرد.
استفاده از دستور select
برای موقعیت های دیگر ، شما باید به مهندسی معکوس بخش های آسیب پذیر نرم افزار پرس و جوی sql ، بپردازید که از پیام های خطا بازگشت می شوند. برای این کار ، شما باید بدانید که چگونه به تفسیر پیام های خطا بپردازید و چگونه با اصلاح کردن رشته تزریق ، به شکست آن ، دست یابید. [12]
اولین خطایی که شما معمولا با آن ، روبرو می شوید ، ساختار نحوی خطاست. یک ساختار نحوی خطا نشان می دهد که یک رشته پرس و جو با ساختار مناسب پرس و جوی sql ، نمی تواند مطابقت داشته باشد. اولین چیزی که برای تعیین شدن نیاز است ، این است که آیا تزریق بدون رهایی یک عبارت نقل شده ، ممکن است. در یک تزریق مستقیم ، هر استدلال و دلیلی که شما ارائه کنید ، بدون هیچ تغییری در ساختار پرس و جوی sql ، استفاده می شود. سعی کنید که پارامتر های قانونی متغیر را ، در نظر بگیرید و یک فضای خالی و یک کلمه OR ، به آن اضافه کنید. اگر ، این موضوع ، ایجاد خطا کرد ، امکان تزریق مستقیم وجود دارد. متغیرهای مستقیم ، می توانند همان متغیرهای عددی باشندکه در عبارت where ، استفاده شد. مانند زیر :
تزریق مستقیم 
 
با استدلال از کلمه کلیدی sql ، مانند فهرست یا نام ستون :
کلمه کلیدی sql 
 
همه ی موارد دیگر به صورت آسیب پذیری های تزریق ، بیان شده اند. در بیان یک تزریق ، هر استدلالی که شما ارائه کنید دارای یک عبارت پیشوند و یک عبارت اضافه شده ، به آن است که توسط نرم افزار انجام می شود ، مانند زیر :
آسیب پذیری های تزریق 
 
برای شکست عبارت بیان شده و دستکاری کردن پرس و جو ، در صورتی که بخواهیم ساختار معتبر نحوی ، حفظ شود ، باید ، قبل از این که از کلمات کلیدی sql  ، و یا از عبارت where  در پایان، استفاده کنید ، از عبارتی که به آن اضافه شده است استفاده کنید. و اکنون مساله " تقلب " را مورد توجه قرار دهید. سرور sql ، می تواند هر چیزی را بعد از یک ".—" نادیده بگیرد ، اما تنها سروری است که می تواند این کار را انجام دهد . بهتر است که شما این " مسیر دشوار  "را یاد بگیرید به این دلیل که بدانید چطور یک اوراکل DB/2 ، MYSQL ، یا هر نوع دیگر از سرور پایگاه داده ، اداره و کنترل می شود.

حملات با استفاده از پرس و جوی ناقص (Malformed Queries)
در حملات نوع قبل که مورد بررسی قرار گرفتند ، حمله کنندگان می بایستی با استفاده از روشهای موجود شماتیکی از جداول و فیلدهای پایگاه داده بدست می آوردند و سپس نسبت به تزریق و حمله اقدام می نمودند. در این روش یعنی روش استفاده از پرس و جوهای معیوب ، دیگر نیازی به دانستن ساختار فیلدها و پایگاه داده نمی باشد. 
با استفاده از پرس و جوهای ناهنجار ، حمله کننده Server را مجبور به تولید پیغامهای خطا می نماید. پیغامهای خطای تولید شده از سمت Server معمولا بیش از حد توصیفی می باشند و در بیشتر اوقات شماتیکی از فیلدهای جدول و یا نام جدول نیز در پیغام خطا نمایش داده می شود. به این صورت حمله کننده به راحتی می تواند به اطلاعات بسیار مفیدی از پایگاه داده موجود در Server دست پیدا کند.
نمونه ای از خطای رخ داده از طریق این گونه حمله که منجر به نمایش اطلاعات ساختاری دیتابیس می شود در ذیل ارائه شده است:
8potentially exploitable vulnerabilities
ERROR: ./editnews.php:@main: _POST#g["newsid"]
----------------------------------------------
This error occurs at lines 24-25 in editnews.php. User input
_POST["newsid"] may directly flow into the SQL query below, resulting
in a potentially exploitable SQL injection vulnerability.
ERROR: ./faq.php:@main: _GET#g["catid"]
---------------------------------------
This error occurs at lines 61-62 in faq.php. We believe user input
_GET["catid"] is improperly checked in the following line: the regular
expression seem to only check the existence of a number. It is
probably missing "^" and "$" that ensures "catid" _is_ a number.
ERROR: ./faq.php:@main: _GET#g["question"]
------------------------------------------
Lines 107-108 in faq.php. Similar as above.
ERROR: ./postnews.php:@main: _POST#g["poster"]
----------------------------------------------
Line 28: $newsposter is not validated before being passed into the
query string at line 42.

ERROR: ./templates.php:@main: _POST#g["tempid"]
-----------------------------------------------
Line 33: $tempid is not validated before being passed into the query
string at line 40.
$user defined at line 46, and used in query string at line 50.
ERROR: ./del.php:@main: _GET#g["post_id"]
-----------------------------------------
Def: line 35; Use: line 44

ERROR: ./delcat.php:@main: _GET#g["cat_id"]
-------------------------------------------
Def: line 44; Use: line 52

ERROR: ./delcomment.php:@main: HTTP_GET_VARS#g["comment_id"]
------------------------------------------------------------
Line 35: inappropriate validation with "intval"

ERROR: ./deluser.php:@main: _GET#g["id"]
----------------------------------------
Def: line 45; Use: line 53
همانگونه که مشاهده می شود اطلاعاتی در مورد عنوان فیلدها در خطای فوق ارائه شده است.

تگها: E-stores   Malformed Queries   تزریق SQL   تزریق کدهای مخرب   حمله به فروشگاه الکترونیکی   فروشگاه های الکترونیکی   مزاياي فروشگاههای اينترنتي   
 

HyperLink

ارسال نظر در مورد این مطلب
نام :  
آدرس ایمیل :  
متن پیام :  
کد امنیتی :  
   
   
نظری برای نمایش وجود ندارد
 
این مطلب را به اشتراک بگذارید: