مبحث یکم : مقدمه و تاریخچه
مبحث دوم: مراحل نفوذ کردن / جلوگیری از نفوذ
مبحث سوم: حملات شبکه ای
مبحث چهارم - کار عملی
مبحث پنجم - DHCP
مبحث ششم - وب و حملات مطرح در آن
مبحث هفتم - حملات DoS
مبحث هشتم - سیستم عامل
مبحث نهم - مهندسی اجتماعی
مبحث دهم - Vulnerability (آسیب پذیری)

Advance SQL-Injection

نکات SQL injection Advanced در M.S. SQL Server ! حتماً با ویدئو آن دیده شود. نکات آورده نشده است. بدست آوردن ورژن MS SQL با استفاده از error (شکل 10).

شکل 10

البته @@version بدون select هم در شکل 10 جواب می دهد. در حقیقت این کار error injection است.

در سایت pentestmonkey.com، cheat sheet کامل SQL وجود دارد.

Error شکل 10 می گوید در زمان تبدیل خروجی تابع @@version (که برابر است با مثلاً SQL Server 2008) به نوع int (برای مقایسه با 1)، سیستم با error مواجه شده است. این کاری است که ما از آن برای متوجه شدن ورژن دیتابیس استفاده می کنیم. می توان استفاده های بیشتری هم کرد یعنی به جای version مثلاً اسامی جدول را بیرون کشید.

توجه: مشاهده جدول user (شکل 11) ! select * from users

شکل 11

مثال: استخراج فیلد username با استفاده از query زیر.

(select * from users where 1=( select username from users

اما اگر دستور بالا را اجرا کنید، نتیجه ای به شما برنمی گرداند (چون طراحی ما به گونه ای بوده است که هم username و هم 1 که در حال مقایسه شدن هستند از نوع integer هستند). راهی که بتوان error را از سیستم گرفت (error داده شود) این است که دستور بالا را به اضافه یک کاراکتر کنیم.

‘Select * from users where 1=( select username from users)+’a

که می بینیم منجر به دادن یک error می شود. اما مقدار username را که برابر است با 7080، در عبارت مربوط به error بدست می آوریم (شکل 12)

شکل 12

در شکل 13 نمونه ای از error در زمانی که مثلاً در یک سایت (سایتی که به طور مثال ایجاد کرده ایم) مقدار فیلدی را برابر query بالا قرار می دهیم نشان می دهد.

یکی از روش های جلوگیری از SQL-Injection این است که از مقادیر فیلدهای ورودی که کاربر به عنوان (مثلاً) username وارد می کند، کاراکتر فاصله (space) را حذف کنیم (این کار را در برنامه ای که به زبان PHP، C# و یا … نوشته ایم انجام می دهیم). با این کار دستوری مثل select * from تبدیل به select*from می شود که قابل فهم برای DBMS نیست.

راه حل فیلتر بالا این است که در query خود هر جا که space داریم عبارت /**/ را وارد کنیم. چون این عبارت دیگر فضای خالی نیست C# نمی تواند آن را حذف کند. همچنین از نظر DBMS، این عبارت، فضای خالی (space) در نظر گرفته می­شود.

زمانی که select و from فیلتر می شوند (یعنی در برنامه این عبارت ها با هیچی (“ “)، replace خواهند شد). اگر فرضاً در کد عین عبارت select و from را فیلتر کرده شما می توانید برخی از حروف آن را به صورت بزرگ بنویسید تا این فیلتر bypass شود. مثلاً (SelEct from)

اما یک فیلتر قوی تر نسبت به فیلتر بالا این است که ابتدا تمام مقادیر دریافتی را به حروف کوچک تبدیل کند و سپس عبارت select و from را حذف کند.

معمولاً CMSها (سیستم های مدیریت محتوا) یک لیست سیاه دارند که admin می تواند آن را مدیریت کند. یعنی مثلاً کلمه select، from و یک سری پسوندها مثل config. را در آن قرار دهد. اگر محتویات این لیست در URL و یا به طور کلی در ورودی ببینند آن را حذف می کنند و یا خطا برمی گرداند.

توجه: ترتیب فیلتر کردن هم مهم می باشد. برای مثال فرض کنید مقادیری را که از فیلدهای ورودی می گیریم ابتدا عبارت select سپس عبارت from همین طور کاراکتر ‘ را با هیچی (“ “) replace می کنیم. به نظر این کار، کار خیلی خوبی است اما این طور نیست. به راحتی می توان فیلتر بالا را bypass کرد. کافی است تا عبارت زیر را وارد کنیم.

;((sel’ect username fr’om users + select ( char(97

چون در ابتدا فیلتر اول می خواهد کلمات select را حذف کند پس sel’ect حذف نمی شود. فیلتر دوم نیز به همین ترتیب. فیلتر سوم هم single quotation ها را از عبارت حذف می کند.

توجه: ما به جای کاراکتر ‘a’ عبارت char(97) را قرار دادیم که معادل کاراکتر a است.

یک راه فیلتر کردن: زمانی که مقدارها قرار است مقدار int باشند (مثل شماره کارمندی یا …)، در برنامه خود می توانیم هر مقداری که از این فیلد گرفتیم را به نوع int، تبدیل کنیم. این باعث می شود اگر کاراکترهای غیرعددی وارد آن فیلد شده باشد (مثل select) جلوی آن در سطح برنامه کاربردی (و نه DBMS) گرفته شود. اما اگر error آن را نگاه کنید (شکل 13) می بینید که اطلاعات مهمی مثل نام کاربری و کلمه عبور اتصال به DBMS در آن وجود دارد (همچنین موارد دیگری مثل مسیر وجود سایت در کامپیوتر نیز مشخص است).

شکل 13

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

xp command shell یک stored procedure است که داده ای را از کاربری می گیرد و مثل یک command بر روی سیستم اعمال می کند و نتیجه را به ما برمی گرداند. دستور زیر باعث می شود دستور net user که در ویندوز لیست کاربران را بر می گرداند اجرا شود.

‘exec xp-cmdshell ‘net user

(net user را در cmd اجرا کنید می بینید که لیست کاربران را می دهد) خروجی دستور بالا را در شکل 14 می بینید. با استفاده از دستور exec می توان یک stored procedure را اجرا کرد. xp-cmd shell هم یک stored procedure است که در بالا توضیح عملکرد آن داده شد.

شکل 14

موضوع بالا می تواند در injection به کار رود. یکی از اهداف ما در injection این است که user، pass ها را در می آوریم، login می کنیم به سایت و برای حفظ دسترسی ها بر روی سایت یک shell روی سایت می گذاریم که دسترسی مان همیشه به سایت باشد (یک backdoor بر روی سایت قرار می دهیم). این کار امکان اجرای دستور بر روی server را به ما می دهد. مثلاً با همان net user بیاییم و کاربر جدید بسازیم. خوب کسی که xp-cmdshell را بزند اصلاً نیازی نیست که user و passها را پیدا کند، می تواند هر دستوری را اجرا کند.

با استفاده از دستور زیر می توان فایل های موجود در پوشه سایت خود را ببینیم. دقت کنید فرضاً آدرس را از error هایی که در قبل توضیح آن داده شد به دست آورده ایم. (مسیر داده در دستور زیر فرضی است).

“exec xp-cmd shell ‘ “d:\Adv SQLi\” ‘> “d:\Adv SQLi\dir.txt

دستور بالا منجر می شود فایل های موجود در پوشه d:\Adv SQLi با استفاده از دستور dir لیست شوند و با استفاده از دستور > به فایل dir.txt در مسیر d:\Adv SQLi ریخته شود. حالا می توانیم نام این فایل را در URL بزنیم و محتویات را مشاهده کنیم.

فایلی به نام web.config در مسیر سایت در کامپیوتر وجود دارد که مشخصات کاربری (نام کاربری و پسورد) دسترسی به DBMS را دارد. برای اینکه بتوانیم این اطلاعات را از این فایل بخوانیم شاید این راه به ذهن برسد که در URL بعد از اسم سایت بنویسیم .ir/web.config SiteName. www. اما با پیغام خطا مواجه می شویم که “شما اجازه دسترسی به این فایل را ندارید”.

خوب کاری که انجام می دهیم این است که با انجام یک injection با دستور xp-cmdshell فایل web.config را به صورت web.txt کپی می کنیم.

; ‘ “exec xp-cmd shell ‘copy “d:\Adv SQLi\Adv SQLi\web.config”  “d:\Adv SQLi\Adv SQLi\web.txt

حالا پس از اجرای این دستور می توانیم در URL بنویسیم .ir/web.txt SiteName. www که در این صورت محتویات این فایل را می توانیم ببینیم. بعد از استخراج نام کاربری و کلمه عبور با استفاده از SQL management در DBMS خود وصل می شویم به آن پایگاه داده مربوطه و ادامه کار.

فرض کنید هم web server و sql server همه در یک سیستم هستند اما دسترسی از راه دور remote به SQL server بسته است. علی رغم اینکه فایل web.config را داریم با SQL management نمی توانیم به آن وصل شویم (چون remote آن بسته شده است). یک کاری که می توانیم بکنیم اینکه تک تک select کنیم و اطلاعات را بگیریم که کار وقت گیری است. راه دیگر استفاده از دستور bcp است. حمله کننده اگر web.config را دارد یعنی نام کاربری و پسورد را هم دارد. دستور bcp، جدولی را که شما مشخص می کنید مستقیماً بر روی فایلی در هارد می ریزد. دستور زیر تمام اطلاعات پایگاه داده test، جدول users را در مسیر مشخص شده (مسیر سایت) در فایلی به نام table.txt می ریزد. با –S نام سرور و با –U نام کاربری و با –P پسورد (اطلاعاتی که از فایل web.config گرفتیم) را مشخص می کنیم.

;’exec xp-cmdshell ‘bcp “select * from test.users” queryout “D:\Adv SQLi\Adv SQLi\table.txt” –c -Slocalhost –Utest –Ptest

فرض کنید injection را می توانیم انجام دهیم اما web.config را نمی توانیم بخوانیم. با استفاده از دستور زیر یک جدول با نام tst ساخته می شود که یک ستون دارد. حالا فایل web.config را در آن insert می کنیم.

;’create table tst (line varchar(8000)); bulk insert tst from ‘D:\Adv SQLi\Adv SQLi\ web.config

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

;Select top 1 line from tst

یکی از راه های جلوگیری از SQL injection این است که قبل از اینکه داده ها بخواهند در DBMS پردازش شوند حتماً باید در برنامه، یک پردازش اولیه روی آن­ها انجام شود.

ابزار Havij ابزار خوبی در سرعت دادن به کار injection است برای تست نفوذ است.

یکی از کارهایی که برای جلوگیری از حمله SQL- injection انجام می شود چک کردن مقادیر ورودی در برنامه است (کنترل stringهایی مثل select و ….(

نکته خارج از بحث: در حملات cross site scripting یک سری از کدها را سعی می کنیم در وب سرور inject کنیم (code injection). دستور include در زبان های برنامه نویسی (PHP، ASP و …) به برنامه می گوید یک کد یا فایل را از جای دیگر بردار و در اینجا load کن (که این فایل می تواند یک کد مخرب باشد).

نکته خارج از بحث: honey pot چیست؟ تله عسل یا honey pot یک سری سیستم هایی هستند با طراحی های امن و نامناسب که آسیب پذیر و آماده برای نفوذ نفوذگر هستند. علی الخصوص تحت وب مثلاً سرویس هایی مثل گوگل، درون server farm های خود، یک سری سایت های ناامن را به صورت عمدی راه اندازی کرده اند تحت عنوان honey pot. که شما وقتی مثلاً یک حمله وبی را کشف کرده اید و تمایل دارید حمله خود را روی سایت های مختلف تست کنید که ببینید جواب می دهد یا خیر. ممکن است یکی از این سایت هایی که شما می بینید جدای از ظاهر بیرونی خود، پشت آن یک honey pot باشد. بدین ترتیب کل سناریوی حمله شما آنالیز می شود و برای شرکت هایی مثل zdh، info sec و … که در بحث امنیت فعالیت می کنند، فرستاده می شود.

در بحث فیلتر کردن ورودی های کاربر نیز توصیه این است که ورودی کاربر را تغییر ندهیم، بلکه اگر حمله ای شناسایی شد، سپس تصمیم مناسب گرفته شود. مثلاً ارسال شود به سیستم هانی پاتمان و ارزیابی کنیم که حمله کننده چه کارهایی را انجام می دهد تا اگر حمله یا باگ جدیدی است شناسایی کنیم و سیستم را patch کنیم.

می توانیم فیلتری داشته باشیم که اگر در مقدار پسورد عبارت های select، insert و … بود به یک صفحه redirect شود و به کاربر بگوییم پسورد دیگری انتخاب کند (سیاست های پسوردگذاری داشته باشیم).

نکته: تستی که در آن کد را داریم و می توانیم کد را ببینیم و ارزیابی امنیتی (pen test) انجام دهیم، تست white box است. اگر کد را نمی دیدیم تست از نوع black box بود. ابزارهای تست جعبه سفید و جعبه سیاه وجود دارند. اما باید توجه داشته باشیم که خلاقیت بشر هم وجود دارد که می تواند روش های نفوذ جدیدتر و روش های دفاع جدیدتر را ارائه دهد.

سؤال: آیا یک کدی که برخی از فیلترهای مطرح شده مثل حذف کلمات کلیدی و یا حذف “، ‘ و …. جلوی injection را می گیرد؟

یکی از روش های bypass استفاده از یک سری از کاراکترهاست. (نکته: محل اعمال شدن چک ها و بررسی ها مهم است یعتی بلافاصله زمانی که از کاربر اطلاعات را گرفتیم بیاییم و آنالیز کنیم یک ماجرا است. اگر زمانی که در حال ارسال به DB (پایگاه داده) آن را آنالیز کنیم یک ماجرا است. همچنین درون DBMS هم آن accessها و roleها ماجرایی دیگر). با فرض اینکه چیزهایی که user وارد کرده می خواهد بررسی کند که چه چیزهایی وارد کرده. کاربر می تواند در فیلد پسورد خود از توابعی مثل tochar() و … استفاده کند. مثلاً tochar(97) یعنی مثلاً کاراکتر ‘a’. برنامه این مقدار ورودی برای پسورد را بررسی می کند و می گوید کاربر خواسته مقدار پسورد خود را این عبارت tochar(97) قرار دهد و جلوی آن را نمی گیرد. اما زمانی که این query می خواهد ارسال شود وب سرور می بیند که تابع tochar وجود دارد. پس آن را به کاراکتر مربوطه تبدیل می کند و آن را می فرستد. پس نتیجه می گیریم قدرت روش دفاعی ما به چک و بررسی هایی که انجام می گیرد بستگی دارد. حالت دیگر ورود اطلاعاتی مثل se/**/lect است. این عبارت هم معادل select است.

یکی از راه های دفاع که مثال هایی از آن هم مطرح شد input validation است که بحث دیگر تعیین role (نقش) ها و privilegeها در DBMS است. بحث دیگر در زمان ارسال است که ما بیاییم با استفاده از IDS، IPS، اسکریپت هایی میانی قرار دهیم. یعنی بعد از اینکه وب سرور (Application Server) پردازشش را انجام داد حال زمانی که می خواهد آن را به DBMS بفرستد در آنجا پردازش صورت گیرد و بررسی شود چه چیزهایی در حال ارسال به DBMS هستند (چون هر تابعی که قرار بوده توسط وب انجام شود انجام گرفته است). بحث دیگر هم استفاده از Parameterized SQL است. یکی از روش های مؤثر است عملکرد آن هم به طور کلی این گونه است که query کامپایل شده و متغیرهایش را ایجاد می کند.

دقت کنید که در error ی که به کار نمایش داده می شود اطلاعات وجود نداشته باشد.

SQL injection علاوه بر بدست آوردن اطلاعات می تواند برای تغییر پایگاه داده هم استفاده شود. مثلاً با استفاده از دستور insert. همچنین می تواند توابع سیستمی را هم اجرا کند (در آخر جلسه قبل به آن اشاره شد). یکی دیگر از بحث هایی که در برقراری امنیت DB مطرح است این است که توابع خطرناک را حذف و یا فیلتر کنیم. در یکی از سیستم های SQL قبل، به طور پیش فرض توابعی (stored procedure) مثلxp-exec یا xp-shell نصب می شد که در DBMS امکان اجرای دستورات سیستمی به طور پیش فرض بود. پس اگر inject به سیستم انجام می شد آن نفوذگر می توانست از توابع سیستمی استفاده کند و دستوراتی مثل format، shutdown، reboot، netuser و … را اجرا کند. پس حواستان به تنظیمات پیکربندی باشد.

توجه: backtrack خود را اجرا کنید.

در cross site scripting یک سری کد وب در صفحه مان inject می کنیم. پس باید کمی دانش در رابط با کد زدن در وب داشته باشیم. زبان مورد استفاده در صفحات وب هم html است. HTTP پروتکل انتقال اطلاعات در وب است (hyper text transfer protocol). مرورگر از زبان html برای تعامل با user استفاده می کند.

نمونه ای از کد html: کد html با تگ <html> آغاز می شود. کد صفحه هم در تگ <body> قرار داده می شود. این کدها را در فایلی با پسوند html (مثلاً test.html) قرار دهید و آن را با browser باز کنید.

<htm>

<head>

<title> test page </title>

</head>

<body>

        hello, how are you

</body>

</html>

زمانی که آدرس یک صفحه وب را وارد می کنیم، browser با پورت 80 وب سرور ارتباط برقرار می کند و به او می گوید Get /test.html و اطلاعات دیگر فرستاده می شود. وب سرور نیز این Page را برای browser ارسال می کند. Browser نیز Page گرفته شده را نمایش می دهد. زبان html برای قالب بندی صفحات وب ایجاد شد.

توجه: یک آشنایی ابتدایی با html پیدا کنید.

بعدها زبان هایی هم ایجاد شد که بتوانند پردازش هایی را هم انجام دهند. مثلاً PHP یک زبان برنامه نویسی تحت وب است که بر روی سرور اجرا می شود (Server Side). مثالی از کد PHP.

این فایل را با نام test.php ذخیره کنید و در پوشه root وب سرور خود قرار دهید.

php?>

  ;”<print “<html

  ;”<print “<head

  ;”<print “<title>test, PHP </title

  ;”<print “</head

  ;”<print “<body> PHP is working </body

  ;”<print “</html

<?

نکته خارج از بحث: با نصب نرم افزار WAMP بر روی سیستم عامل ویندوزی خود، می توانید هم وب سرور و هم زبان PHP و پایگاه داده My SQL را داشته باشید.

توجه: اگر کد PHP دارای errorهای ساختاری باشد این errorها در log سیستم ثبت می شوند و می توانید آنها را در backtrack مشاهده کنید (/var/log/httpd/error-log)

پس از آنکه فایل PHP بالا را در browser خود مشاهده کردید، روی آن راست کلیک کرده و source آن را ببینید که در آن دیگر دستورات PHP دیده نمی شود. آن دستورات در سمت سرور اعمال شده است. پس نفوذگر نمی تواند با تغییر این کد در سمت client، آن را تغییر دهد. بسته به زبانی که استفاده می کنیم نحوه ی حمله و توابعی که در اختیار نفوذگر قرار می گیرد می تواند متفاوت باشد.

تمرین: یک صفحه ی ساده با PHP در backtrack ایجاد کنید.

ساختار وب سرور لینوکس که Apache (آپاچی) است به این نحو است که فایل ها را در شاخه ی /var/www/html باید قرار دهید تا در دسترس کاربران وب قرار گیرد.

بسته به وب سرور می تواند مسیر بالا متفاوت باشد. در backtrack مستقیماً در زیر پوشه www است. در IIS در زیر پوشه inetpub است.

توجه: باید سرویس وب فعال شود. با دستور

service apache2 start

توجه: در سیستم عامل CentOS به جای عبارت apache2 از httpd (http deamon) استفاده کنید.

توجه: حالا می توان page را در مسیر ذکر شده گذاشت و از طریق مرورگر آن را باز کرد.

حملاتی که انجام می شود تنها بدین گونه نیست که علیه سرور انجام شود. خیلی وقت ها ممکن است شما با دیدن یک سایت بر روی یک سرور، باعث شوید تا سیستمتان دچار مشکل شود.

تمرین: کدی را نویسید (با php یا html) که منجر به redirect شدن صفحه شود.

توجه: اگر کد html باشد در تمام وب سرورها جواب می دهد اما اگر PHP باشد باید PHP در آن وب سرور نصب شده باشد (لینوکسی ها غالباً php دارند).

نکته: logها در لینوکس زیرشاخه /var/log قرار می گیرد. در اینجا به ازای هر سرویس چندین log می تواند باشد. apache، httpd، Error log، Access log که از روی Access logها و error logها می توان حملات را فهمید.

برای redirect شدن در html، از تگ <meta> در قسمت head استفاده می کنیم.

<meta HTTP-EQUIV= “REFRESH”   content= “0; url= آدرس مورد نظر ما “>

که در آن 0 یعنی زمانی که قبل از redirect شدن باید منتظر ماند (به ثانیه). در آدرس، http:// را هم بگذارید و اگرنه در ادامه آدرس سایت خودتان، آن آدرس را اضافه می کند.

با استفاده از Scriptها (مثل javascript) می توانیم در سمت browser نیز عملکردهایی داشته باشیم. البته لازمه ی آن این است که browser آن اسکریپت را پشتیبانی کند.

کد زیر یک پیغام Hi! را نشان می دهد.

<html>

  <head>

  <title>

       test page

  </title>

  </head>

  <body> hello.

  <script> alert (‘Hi!’); </script>

  </body>

  </html>

تمرین: اسکریپتی پیدا کنید که کار redirection را انجام دهد و page را ببندد.

تمرین: چگونه می توان حین redirect کردن، کوکی ها (cookie) را ارسال کرد.

تمرین: چگونه در alert کوکی ها را نمایش دهیم.

در تگ اسکریپت اگر type را مشخص نکنیم، default مرورگر اعمال می شود (و غالباً جواب می دهد).

یادآوری: برای چک کردن کد html نیازی به وب سرور نیست.

ممکن است برخی از رفتار مشکوک به حملات را browserها به عنوان رفتار حمله در نظر بگیرند مثلاً یک پنجره باز شود و سریع بسته شود و ممکن است یک alert به شما دهد و یا جلوی آن را بگیرد.

کد شکل 1 کار redirect و بستن پنجره را انجام می دهد.

شکل 1

نکته: وقتی redirect انجام می شود، بعد از آن هر کدی نوشته باشید اجرا نخواهد شد. پس هر کاری که می خواهیم بکنیم باید قبل از redirect انجام دهیم. پس در کد شکل بالا دستور window.close() کار نخواهد کرد.

می توان یک ویندوی جدید باز کرد (با window.open) و سپس پنجره جدید باز می شود و در انتهای آن پنجره که باز شده است یک کد بسته شدن هم قرار داده شود (که خیلی وقت ها اصلاً کاربر متوجه هم نمی شود که یک پنجره باز شد و بسته شد).

نکته: استفاده از ? (علامت سؤال) برای اینکه مرورگر سایت را از cache بالا نیاورد.

البته ممکن است در حین اجرای دستور close، مرورگر یک پیغام برای تأیید بستن پنجره از کاربر بگیرد مهم نیست و این مهم است که تا این مرحله برسیم (چون عملاً کدهایی که می خواستیم اجرا کنیم، اجرا شده است).

همان طور که گفته شد این طور نیست که حملات تحت وب علیه وب سرورها باشد، ممکن است حملات از طریق وب سرورها علیه clientها انجام شود. نفوذگر ممکن است یک وب سرور آلوده ایجاد کند که به محض اینکه سایتش را بالا می آورید تعداد زیادی پیغام به شما بدهد (با alert ()) که عملاً شما مجبور شوید مرورگر خود را ببندید و نفوذگر با این کار شما به این برسد که شما session خود را terminate کنید (بعد از بستن مرورگر، session live آنها بسته می شود). هر صفحه وبی را نباید ببینیم چون ممکن است خطراتی را برای ما در پی داشته باشد مثلاً ما را به یک صفحه دیگر منتقل کند، یا یک سری داده از سیستم ما fetch (برداشت) کند، می تواند یک سری دیتا را روی سیستم ما set کند. Flash هایی که load می شوند می توانند قابلیت start و stop برای webcam و میکروفون سیستم ما را داشته باشند. یکی از راه های جلوگیری این است که از حالت text mode برای دیدن سایت ها استفاده کنیم (مثل مرورگر lynx) که اسکریپت در آنها غیرفعال است و صرفاً html پایه را دارند.

حالا سؤال اینجاست که این کدها چگونه می توانند مورد استفاده نفوذگر قرار بگیرند. نفوذگر اگر web page داشته باشد خوب می تواند علیه بازدید کننده های web page خود حمله انجام دهد. اما در روشی دیگر نفوذگر از سایت دیگری علیه userهایی که سایت را می بینند استفاده می کند. برای مثال نفوذگر کدی را در سایت www.abccd.com  قرار داده است که زمانی که کاربر سایت www.abccd.com را بازدید می کند آن را سریعاً به سایت جعلی www.abcccd.com (سه تا c دارد که قابل تشخیص با قبلی که 2 تا c دارد نباشد) منتقل می کند. آن سایت را هم به گونه ای درست کرده که مثل سایت اصلی باشد. کاربر اطلاعات خود را وارد می کند، نفوذگر هم از آن طرف آنها را capture می کند. بعد از دریافت اطلاعات، کاربر را به سایت اصلی redirect می کند (یک حمله MitM تحت وب انجام شد).

سؤال: چه جاهایی در کد یک سایت وجود دارد که نفوذگر می تواند کد خود را بگذارد؟ در قسمت جستجو، نظرات.

سؤال: مثلاً در فیلد جستجو هر چه را که برای جستجو تایپ کنم می گوید عبارتی معادل عبارت جستجو شده پیدا نشد. مثلاً ما جستجو می کنیم “abc”، به ما می گوید “abc” وجود ندارد. یعنی دقیقاً همان چیزی که تایپ می کنم را به من نشان می دهد. خوب من می توانم به جای اینکه یک عبارت را جستجو کنم، همین کدهای اسکریپتی را تایپ کنم.

سؤال: کد HTML قرار دهیم یا کد اسکریپت؟ هم اسکریپت، می توان قرار داد و هم html. اما باید دقت کرد که چه کد html را در چه جایی قرار دهیم. مثلاً کد <body> که یک بار قرار داده شده ما دوباره از تگ <body>، <html> و یا …. استفاده نکنیم. برای کد اسکریپت هم می توان از تگ <script> استفاده کرد. به این حملات XSS یا cross site scripting می گویند. حالا با فرض اینکه من یک XSS هم انجام دهم. خوب من page را خودم می بینم. من که قصد ندارم سیستم خودم را مورد نفوذ قرار دهم. پس این روش چه کاربردی دارد؟ توجه دارید که (در همان مثال استفاده از قسمت جستجوی سایت برای قرار دادن کد مورد نظر) بعد از اینکه من کد مورد نظر خود را در قسمت جستجو وارد کنم اگر از متود GET برای ارسال داده استفاده شده باشد، در لینک سایت، اطلاعاتی که وارد قسمت جستجو کرده ام (کد مخرب) می آید (فرض کنید ما در سایت yahoo چنین آسیب پذیری را پیدا کرده ایم) پس لینک ما بعد از کلیک بر روی دکمه جستجو شبیه www.yahoo.com/…. است. حالا می توان این لینک را به یک کاربر مثلاً در محیط چت (chat room) داد. کاربران با دیدن قسمت اول URL که مربوط به یک سایت است بر روی آن کلیک می کنند و مورد حمله قرار می گیرند (عموماً به خاطر وارد شدن کد در لینک (به خاطر متود GET) اندازه لینک بزرگ است و کسی نمی بیند که در آن مثلاً کد اسکریپتی هم وجود دارد که البته می توان از مکانیزم های encoding مثل (tochar(97)) که قبلاً بیان شد نیز استفاده کرد تا کد اسکریپتی هم واضح به نظر نرسد). بعد از اینکه لینک را وارد یک محیط چت کنید جداً بعد از مدت کوتاهی ممکن است تعداد زیادی کاربر روی آن کلیک کنند. حال به واسطه ی اجرا شدن آن اسکریپت، می توان بسته به نوع اسکریپت کاربر را به یک fake page هدایت کرد و یا از مسائل مربوط به کوکی (cookie) استفاده کرد.

کوکی چیست؟ همان طور که قبلاً گفته شد، یک سری از پردازش های سمت سرور به client ها محول شده است و یک سری از storageها (ذخیره سازی) هم به همین ترتیب. کوکی فایل کوچکی که وب سرور بر روی سیستم client توسط browser ایجاد می کند. در این فایل یک سری داده قرار گرفته است. مثلاً شما به یک سایت login کردید و گزینه save password را فعال کردید یک کوکی در سیستم شما ایجاد می کند. آن سایت دفعه بعد که شما می آیید login کنید از روی کوکی که ایجاد کرده است می خواند و شما login می شوید. حالا اگر من کوکی شما را داشته باشم چه استفاده ای می توانم انجام دهم؟ روی سیستم خودم این کوکی را set می کنم و آن سایت را بازدید می کنم. سایت هم کوکی را می خواند و می بیند user و pass در آن وجود دارد و من را به سایت login می کند. به این حمله cookie stealing می گویند.

بسته به نوع مرورگر، می توان کدهایی را نیز inject کرد که یک دستور سیستمی اجرا شود. اما با این اسکریپت های basic نمی شود اما با کمک applet Java، flash، image و … می توان این کارها را انجام داد (مثلاً ممکن است با load شدن یک عکس یک آسیب پذیری وارد سیستم شما شود. چون آن component که مسئول load کردن عکس در مرورگر است خود دچار باگ و آسیب پذیری است).

نکته: خیلی وقت ها code injection ممکن است توسط خود نفوذگر قابل رویت نباشد یعنی نفوذگر در فیلدی کد خود را قرار می دهد که این فیلد توسط کاربر عادی قابل دسترس نیست و فقط زمانی که admin، login می کند این فیلد را می بیند. به واسطه اجرا شدن آن کد برای admin، یک سری دیتا به نفوذگر ارسال می شود.

غالباً از XSS برای اجرای cookie stealing (سرقت کوکی) استفاده می شود که سرقت کوکی منجر می شود به حملات session hijacking (همان دزدیدن کوکی یک نفر و set کردن آن کوکی بر روی سایت خود و استفاده از آن).

در نسخه های قبلی IE (internet explorer) یک آسیب پذیری در ماژول load کردن عکس های آن وجود داشت که نفوذگر می توانست کد مورد نظر خود را در سیستم شما که در حال مشاهده عکس در یک سایت با IE (internet explorer) هستید اجرا کند. در هدر (header) یک image، یک سری اطلاعات وجود دارد که یکی از آنها length است که نشان دهنده ی سایز عکس است. IE در load کردن image چک نمی کرد که آیا سایز image با این مقداری که ادعا شده یکسان است یا خیر. این عکس که در حافظه load می شد (به دلیل آنکه نفوذگر در آن کد مخرب را هم اضافه کرده بود) سایر بایت های اضافه حافظه را خراب می کرد که باعث می شد تا یک کد بر روی سیستم شما اجرا شود. بعد از اینکه سیستم شما آلوده شد حالا می توان از آن به عنوان یک زامبی (zombie) برای انجام حملاتی مثل DDoS استفاده کرد.

از ترکیب حملات می توان یک حمله قدرتمند ایجاد کرد. مثلاً یک بار SQL injection بزنم که در نهایت یک XSS به من بدهد در این XSS کدی را load کنم که از آسیب پذیری client استفاده کند و منجر به باز شدت پورتی روی آن سیستم گردد.

اسکرول به بالا