آموزش CEH (هکر کلاه سفید): آشنایی با رایج‌ترین بردارهای حمله به برنامه‌های تحت وب

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

اسکریپت‌نویسی Cross-Site و حملات جعل درخواست از سایت‌های دیگر CSRF

حملات Cross-Site در چند سال گذشته رایج شده‌اند. هر دو حمله Cross-Script و حملات جعل درخواست از سایت‌های دیگر (CSRF)  سرنام cross-site request forgery attacks  به‌طور ویژه‌ای روی ورودی‌هایی که به شکل صحیح ارزیابی نمی‌شوند متمرکز هستند. اکسپلویت‌های XSS که در اصطلاح به آن‌ها Cross-site Scripting گفته می‌شود از اعتماد توسعه‌دهنده به ورودی که کاربر وارد می‌کند سوء استفاده کرده و کدهایی مخرب را به عنوان یک کاربر نهایی برای یک برنامه تحت وب ارسال می‌کنند. XSS از آسیب‌پذیری‌های موجود در صفحات وبی که به شکل پویا تولید می‌شوند نیز استفاده می‌کنند. به عنوان مثال، مهاجم ممکن است سعی کند کاربر را برای کلیک روی پیوند مخرب مخصوصی که ممکن است نام صفحه را تغییر دهد، کوکی‌ها را سرقت کند، کدهای مخرب را اجرا کند و انواع دیگری از کدهای مخرب را اجرا کند فریب دهد. یکی از راه‌های مورد استفاده توسط XSS از طریق فرم‌های HTML است. برنامه‌های وب‌سرور به‌طور معمول ورودی داده‌ای را از طریق فرم‌ها دریافت می‌کنند و محتوای تایید شده را در قالب یک صفحه HTML به کاربر نشان می‌دهند. از دیگر تکنیک‌های به کار گرفته شده در این حمله می‌توان از طریق ایمیل، سرقت کوکی‌های کاربر، ارسال یک درخواست غیرمجاز، هدف قرار دادن یک وبلاگ و حتا قرار دادن حمله در بخش نظرات یک صفحه وب اشاره کرد. به عنوان مثال، اگر هکری متوجه شود هر چیزی که درون کادر جست‌وجو تایپ می‌شود، حالت تکرارشونده دارد به راحتی می‌تواند یک اسکریپت ساده را به سایت تزریق کند. بنابراین، به جای جست‌و‌جو کافی است، عبارت <script> You’re Hacked <script> را در کادر جستجو وارد کرده و کلید اینتر را فشار دهید. پس از انجام این ‌کار، یک پنجره بازشو ظاهر می‌شود که می‌گوید "شما هک شده‌اید". اتفاقی که افتاده این است که مرورگر برچسب <script> را به‌عنوان آغازکننده یک بلوک کد تفسیر کرده و آن‌را پردازش می‌کند. مراحل انجام این حمله به شرح زیر است:

مرحله 1. یک سایت آسیب‌پذیر پیدا کنید که از کوکی‌ها استفاده می‌کند.

مرحله 2. کد حمله را بسازید و تأیید کنید که مطابق آنچه انتظار می‌رود عمل خواهد کرد:

<A HREF=»http://example.com/comment.cgi? mycomment=<SCRIPT> malicious code</SCRIPT>"> Click here</A>

مرحله 3. آدرس اینترنتی خود را بسازید یا کد را در یک ایمیل یا صفحه وب تعبیه کنید.

مرحله 4. کاربر را در اجرای کد فریب دهید.

مرحله 5. حساب را سرقت کنید.

می‌توانید با وصله کردن برنامه‌های آسیب‌پذیر و اعتبارسنجی ورودی یک صفحه وب پویا مانع پیاده‌سازی حملات XSS شوید. همچنین پیشگیری مستلزم این است که کاربران همچنان نسبت به پیوندهای توکار بدبین باشند و به راحتی روی آن‌ها کلیک نکنند. همه ما از گفتن این جمله خسته هستیمف اما لازم است یکبار دیگر تکرار کنیم که روی هر پیوندی نباید کلیک کنید. حملات جعل درخواست از سایت‌های دیگر (CSRF) حمله‌ای است که با هدف تغییر مسیر یک محتوای ایستا انجام شده و هکر با اجرای دستورات غیرمجاز سعی می‌کند کاربر را از سایتی که به آن اعتماد دارد به سایت دیگری انتقال دهد. در این حمله از مرورگر قربانی برای هدایت او به سمت سایت موردنظر کاربر استفاده می‌شود. در این حمله هکر مرورگر قربانی را مجبور می‌کند تا بدون اطلاع او درخواستی را پردازش کند. شکل زیر مثالی از انجام این حمله را نشان می‌دهد:

به‌طور مثال، تصور کنید که به وب‌سایت بانکی خود به نشانی .com  hackthestack وارد شده‌اید و همزمان به بازدید از یک سایت مخرب پرداخته‌اید. اکنون، کاربر مخرب به‌نام باب برای شما یک ایمیل HTML ارسال می‌کند که شامل برچسب زیر است:

<img src="https://www.hackthestack.com/transfer?amount=1000&amp; destination=bob">

اگر سرویس‌گیرنده ایمیل شما به‌طور خودکار تصاویر را بارگیری کند، درخواست انتقال از طریق مرورگر شما با استفاده از آدرس آی‌پی و کوکی‌های جلسه hackthestack.com انجام می‌شود، دقیقاً مثل اینکه خودتان این درخواست را ارسال کرده‌اید. وب‌سایت بانک با این درخواست به شکل منطقی رفتار کرده و 1000 دلار از حساب شما به حساب Bob ارسال می‌شود.

حملات فیلد پنهان

فیلدهای پنهان یک روش ضعیف در برنامه‌نویسی هستند که در مقطعی از زمان تبلیغات زیادی پیرامون آن‌ها انجام شود هنوز هم استفاده می‌شوند. راهکار فوق به‌کارگیری فیلدهای پنهان HTML به عنوان مکانیزم منفرد برای تعیین قیمت یا مبهم کردن یک مقدار است. گاهی اوقات این آسیب‌پذیری در چرخه خرید الکترونیکی مشاهده می‌شود. بیشتر فروشندگان برنامه‌های خرید الکترونیکی نسبت به‌کارگیری یک چنین سازوکاری در برنامه خود افتخار می‌کنند، اما گاهی اوقات ‌ی توانید فهرستی از کلیه مشتریان آن‌ها را با یک بررسی سریع از سایت به‌دست آورید. مهاجمی که با موفقیت آسیب‌پذیری‌ها را پیدا کند، قادر است فهرست کاملی از قربانیان بالقوه را به دست آورد. برای غلبه بر این مشکل باید کدها به دقت بازبینی شوند. تئوری در پشت به‌کارگیری فیلد فوق به این اصل اشاره دارد که کاربران نهایی نتوانند فیلد فوق را مشاهده کنند، در نتیجه محفوظ از دستکاری است. بسیاری از سایت‌ها از این بخش‌های مخفی استفاده میرکنند تا قیمت کالایی را که به برنامه وب منتقل می‌شود را ذخیره کنند. نمونه‌ای از انجام این عمل توسط یک وب‌سایت به شرح زیر است:

<INPUT TYPE=HIDDEN NAME="name" VALUE="Mens Ring">

<INPUT TYPE=HIDDEN NAME="price" VALUE="$345.50">

<INPUT TYPE=HIDDEN NAME="sh" VALUE="1">

<INPUT TYPE=HIDDEN NAME="return" VALUE="http://www.vulnerable_site.

com/cgi-bin/cart.pl?db=stuff.dat&category=&search=Mens-Rings&method

=&begin=&display=&price=&merchant=">

<INPUT TYPE=HIDDEN NAME="add2" VALUE="1">

<INPUT TYPE=HIDDEN NAME="img"

VALUE="http://www.vulnerable_site.com/images/c-14kring.jpg">

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

مرحله 1. صفحه را به صورت محلی ذخیره کنید و کد منبع را باز کنید.

مرحله 2. مقدار را تغییر دهید و صفحه را ذخیره کنید. به عنوان مثال ، 345.50 دلار را به $ 5.99 تغییر دهید.

<INPUT TYPE=HIDDEN NAME="name" VALUE="Mens Ring">

<INPUT TYPE=HIDDEN NAME="price" VALUE="$5.99">

مرحله 3. صفحه محلی HTML را نوسازی کنید و سپس روی دکمه افزودن به سبد خرید کلیک کنید. اگر عمل فوق موفقیت‌آمیز باشد، به صفحه پرداخت که نشان می‌دهد عمل فوق با موفقیت انجام شده و  خرید بر مبنای $ 5.99 انجام شده را مشاهده خواهید کرد.

برخی از برنامه‌هایی که کدنویسی ضعیفی دارند حتا مقادیر منفی را نیز قبول می‌کنند. قبل از این‌که هیجان‌زده شوید به یاد داشته باشید که بسته به قوانین محلی، تکمیل فرآیند ثبت و سفارش محصولات به این شکل ممکن است مصداق بارز سرقت یا کلاهبرداری تلقی می‌شود. مشکل واقعی این است که یک برنامه هرگز نباید برای تعیین قیمت یک مورد به مرورگر وب تکیه کند. حتا بدون تغییر قیمت، ممکن است یک مهاجم فقط سعی کند مقدار زیادی از داده‌ها را وارد پس‌زمینه محصولات کند تا ببیند چگونه برنامه پاسخ می‌دهد. مقادیر مربوط به فیلدهای مخفی‌، جعبه‌های بررسی، فهرست‌های انتخاب شده و سرآیندهای TTP ممکن است توسط کاربران مخرب دستکاری شده و در صورت عدم استفاده از الگوی اعتبارسنجی مناسب، افراد مختلف به سوء استفاده از برنامه تحت وب بپردازند. اگر فکر می‌کنید سایت‌های کمی آلوده به یک چنین آسیب‌پذیری هستند، بهتر است دوباره در این مورد فکر کنید. کافی است گوگل را باز کرده و به جست‌وجوی واژگانی شبیه به type=hidden name=price بپردازید تا فهرستی از این سایت‌ها را پیدا کنید.

سایر حملات پیرامون برنامه‌ها تحت وب

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

پیش اعتبارسنجی در سمت کلاینت انجام شود، اما امکان گذر از آن با استفاده از پراکسی‌ها و سایر تکنیک‌های تزریق وجود دارد. مکانیزم پس اعتبارسنجی با این هدف انجام می‌شود که اطمینان حاصل کرد خروجی برنامه صحیح است. یکی از مشکلات رایجی که سال‌ها است دردسرهای فراوانی را به وجود آورده، سرريز بافر با اشکال مختلف است. سرريز بافر به دو نوع پشته و heap تقسيم‌بندي مي‌شود. heap یک فضای حافظه است که به صورت پویا اختصاص داده می‌شود. بافر یک ناحیه ذخیره‌سازی داده موقت است که در مدت زمان اجرا برنامه ایجاد می‌شود یا توسط سیستم‌عامل تعریف می‌شود. سرریزهای بافر مبتنی بر Heap با سرریزهای بافر مبتنی بر پشته متفاوت هستند، زیرا سرریز بافر مبتنی بر پشته به سرریز بافر با طول ثابت بستگی دارد. سرریز heap نوعی سرریز بافر است که در ناحیه داده‌های پشته رخ می‌دهد و سعی در بازنویسی ساختارهای داخلی مانند نشانگر فهرست پیوندی دارد.

بافرها دارای فضای محدودی برای انجام یک کار مشخص هستند. به‌طور مثال، اگر به یک بافر 24 کاراکتر اختصاص دهید و سعی کنید 32 کاراکتر را درون آن قرار دهید، یک مشکل واقعی پیش خواهید آمد. در حالت ایده‌آل برنامه‌ها باید این مسئله را بررسی کنند که امکان قرار دادن 32 کاراکتر درون یک بافر 24 کاراکتری امکان‌پذیر نباشد. با این حال‌، این نوع بررسی خطا همیشه انجام نمی‌شود. بررسی خطا چیزی فراتر از این موضوع نیست که اطمینان حاصل کنید نوع داده‌ای درستی به بافر اختصاص داده شده و اندازه کاراکترها از مقادر تعیین شده فراتر نرود. ساده‌ترین راه برای جلوگیری از بروز مشکل سرریز بافر، متوقف کردن دریافت داده‌ها زمانی است که بافر پر شده است. این‌کار را می‌توان با اضافه کردن کرانه‌های مرزی محافظت شده انجام داد. برنامه‌های C در مقایسه با نمونه‌های دیگر بیشتر در معرض مشکل سرریز بافر و حملات پیرامون آن قرار دارند، زیرا C دارای توابع بسیاری است که به درستی کرانه‌ها را بررسی نمی‌کنند.

سی تنها زبانی نیست که در ارتباط با این مشکل آسیب‌پذیر است. زبان‌های برنامه‌نویسی سطح بالا مانند پرل نیز در برابر مشکل سرریزبافر آسیب‌پذیر هستند، هرچند آسیب‌پذیری آن‌ها در برابر مشکل سرریز بافر کمتر است. زبان C مکانیزم‌های دفاعی کمی برای پیشگیری از بروز این مشکل دارد. زبان اسمبلی نیز سطح حفاظتی کمی در این زمینه دارد. حتا برنامه خود را به زبان برنامه‌نویسی دیگری بنویسید، بخش عمده‌ای از کتابخانه‌هایی که ممکن است در برنامه خود از آن‌ها استفاده کنید به زبان سی یا سی‌پلاس‌پلاس نوشته شده است، بنابراین ممکن است بر خلاف تصور، برنامه شما در برابر مشکلات سرریزبافر ایمن نباشد.

نکته: بافرهای آسیب‌پذیر در برابر سرریز بافر تنها محدود به برنامه‌های کاربردی مخصوص تلفن‌های هوشمند و کامپیوترهای شخصی نمی‌شوند. این مشکل در سیستم‌های اسکادا (SCADA) نیز وجود دارد. وجود یک چنین مشکلی در برنامه‌های فوق نگران‌کننده است، زیرا در بیشتر موارد این سامانه‌ها وصله نمی‌شوند و در عین حال در زیرساخت‌های مهم استفاده می‌شوند.

از جمله مشکلات امنیتی دیگری که بواسطه فقدان اعتبارسنجی ورودی‌ها اتفاق می‌افتند به موارد زیر می‌توان اشاره کرد:

■ DoS: هر تکنیکی که اصل دسترس‌پذیری را به هرگونه حالتی هدف قرار دهد حمله انکار سرویس است. به عنوان مثال، ممکن است مهاجم برنامه‌ای را برای عدم ارسال فرم‌های ثبت نام ایجاد کند تا وقتی که تمامی منابع موجود از دست بروند.

■ Session fixation: مهاجم ممکن است هکر را برای دسترسی به یک وب‌سرور با استفاده از مقدار شناسه یک نشست غیر واقعی فریب دهد. این‌کار می‌تواند از طریق یک اسکریپت سمت کلاینت، پاسخ سرآیند HTTP یا برچسب <META> انجام شود. نمونه‌ای از آدرس اینترنتی ارسال شده به قربانی به شرح زیر است، دقت کنید که چگونه sessionid ارسال می‌شود:

<META> tag. An example of the URL sent to the victim would appear as follows; notice how the sessionid is passed:

http://knowthetrade.com/<meta http-equiv=Set-Cookie

content="sessionid=abc123">

■ Direct OS commands: اجرای غیرمجاز دستورات سیستم‌عامل.

■ SOAP injection: مهاجم برای دور زدن تأیید اعتبار سرویس‌های وب، رشته‌های پرس‌وجو مخرب را در فیلد‌های ورودی کاربر تزریق می‌کند.

■ Path traversal: تکنیکی است که به یک هکر اجازه می‌دهد از یک پوشه به پوشه دیگری برود.

■ Unicode encoding: برای گذر از فیلترهای امنیتی استفاده می‌شود. یک مثال مشهور در این زمینه به‌کارگیری رشته یونی‌کد زیر است:

%c0%af..%c0%af..

■ URL encoding: به هکر اجازه می‌دهد یک درخواست کاربردی غیر معتبر را از طریق درخواست HTTP استفاده کند. مثال زیر نحوه انجام این‌کار را نشان می‌دهد:

www.knowthetrade.com%2fmalicious.js%22%3e%3c%2fscript%3e

■ Hex encoding: توسط یک هکر برای مبهم کردن یک آدرس اینترنتی استفاده می‌شود. به‌طور مثال، آدرس www.knowthetrade.com به مقدار زیر تبدیل می‌شود.

 %77%77%77%2E%6B%6E%6F%77% 74%68%65%74%72%61%64%65%2E%63%6F%6D

‌در شماره آینده مبحث فوق را ادامه می‌دهیم.

برای مطالعه رایگان تمام بخش‌های دوره CEH  روی لینک زیر کلیک کنید:

آموزش رایگان دوره CEH