حملات CSRF
تو این مجال می خوام در مورد یک نوع Attack صحبت کنم، که در موردش می تونم با قاطعیت این جمله رو بگم: هر webmaster تو دنیا یا از این حمله آسیب دیده، یا اینکه بهش آسیب پذیر بوده و شانس اورده که بلایی سرش نیومده. کمی غیر قابل باوره، نه؟! اما در ادامه خواهید دید که متاسفانه حقیقت داره…
دلم می خواد به دو شکل این حمله رو تشریح کنم:
-
فنی و گنگ(!): این حمله در واقع ترکیبی از دو نوع حمله است – XSS و Confused Deputy که این دومی نوعی حمله Privilege Escalation هست.
-
ساده و روون: در ادامه این نخ این کارو می کنم…
مراحل زیر رو با دقت متصور شید و دنبال کنید تا ببینید چرا و چطوری این حمله شکل می گیره
-
فرض کنید تو یه سایتی login کردید. اینکه صفحه اون سایت تو مرورگر باز باشه یا نه مهم نیست، مهم اینه تو اون سایت Login کردید، Log Out نکردید و نشستتون هم هنوز منقضی نشده. این که تو این سایت فرضی Login کردید رو بفرستید به بکگراند ذهنتون و به ادامه ماجرا دقت کنید…
-
من به عنوان یک مهاجم(فرضی)، اینو در نظر دارم که کاربر یا کاربرای هدفم به احتمال زیاد روزانه از اون سایتی که شما بهش Login کردید استفاده می کنن. پس به احتمال قابل قبولی ممکنه که هدفم OnLine باشه و نشستش توی اون سایت منقضی نشده باشه. با علم به این موضوع، شروع می کنم به دون پاشی! – به یه روشی ترغیب یا وادارش می کنم که روی لینکی که من می خوام کلیک کنه. یا حتی یه ایمیل براش می فرستم به این امید که اون ایمیل رو فقط باز کنه…! (تو این پست نمی خوام در مورد این روش ها صحبت کنم – بعضیاشون پیشرفته و پیچیده هستن که نخ های دیگری رو می طلبه)
-
اگر شما به دام دون پاشی من بیوفتید و اون سایتی که بهش Login کردید نسبت به CSRF ایمن نباشه، متاسفانه این حمله شکل گرفته و نه تنها مهاجم از [تقریبا] ردی خودش باقی نذاشته، بلکه اگر یه خرابکاری در نتیجه حمله رخ داده باشه و رویدادنگاری انجام گرفته باشه، شما به عنوان عامل این خرابکاری شناخته خواهید شد…!
خب حالا ذهنتون رو یکم خالی کنید و روی گام آخر حمله متمرکز شید تا ببینیم چرا این طور میشه… تو این نخ می خوام بخش “چطور” این حمله رو با یه مثال توضیح بدم چون بخش “چرا”ی این حمله فنیه و دوس دارم به سوالات احتمالی در این مورد تو کامنت ها جواب بدم… حالا می خوایم ببینیم به فرض که گام سوم از حمله هم به وقوع بپیونده، خب مثلا ممکنه چی بشه…
فرض کنید مهاجم می خواد با این حمله، ایمیل شما تو پنل وب سایت رو تغییر بده. خب میشه گفت که این کار به سادگی قابل انجامه، تقریبا راحت ترین کار با استفاده از این حمله است…: وقتی شما می خواید ایمیلتون رو تغییر بدید، ایمیل جدیدتون رو تو یه فیلد می نویسید و روی دکمه یا لینک بروزرسانی کلیک می کنید (فعلا به سوالات و پبهات حاشیه ای توجه نکید و سعی کنید مطلب رو بگیرید). در واقع شما با این کار یه درخواست به سمت Server می فرستید که صرف نظر از GET یا POST بودنش، به راحتی می تونه به صورت خودکار و به صورت نامحسوس انجام بشه و نکته کلیدی در درک این حمله هم همینه! شما گول مهاجم رو خوردید و اقدام به بازدید از محتوای مخربی که اون بهتون پیشنهاد داده بود کردید. اما در پشت صحنه، اون مطلب یه درخواست نامحسوس به سمت Server می فرسته و وااااااااای…! شما تو سایت Login کرده بودید…!!! چون نشستتون تو سایت تموم نشده بود و این درخواست جعلی از طریق مرورگر به سمت Server فرستاده میشه، Server فک می کنه این خود شما هستید که این درخواست رو دادید و مانعش نمیشه…!
شاید فک کنید که خیلی بعیده که این حمله موفق باشه و عنصر شانس نقشی کلیدی در انجام موفقیت آمیز این حمله داره، اما جواب من به شما اینه…: این که شما این طوری فک می کنید، به این دلیله که تفکر نفوذگرانه ندارید!!! ایشالا تو این زمینه پیشرفت می کنید و نه تنها نظرتون عوض میشه، بلکه به یکی از محبوب ترین حملات در نظرتون تبدیل میشه…!
به پایان امد این نخ، حکایت همچنان باقی است (بد طوری هم باقی است…!)
نویسنده امین ساقی
منبع: خودم! (بعد از خوندن سه،چهارتا کتاب در این مورد)
×پا نوشت همراه با توضیحات تکمیلی : بر گرفته از تجارب و خواندن مقالات در وب سایت owasp.org و مقاله attach and defence از وب سایت McAfee
این نوع حمله از طریق جعل درخواست های ارسالی به Server انجام می پذیرد که حتما و تنها راهش استفاده از لاگ بودن کاربران و ادمینها نیست . این نوع حمله را از حملا exploit injection یا تزریق کد هم می توان دسته بندی کرد . این کار مخصوصا در درگاههای بانکی و حسابهای اینترنتی به شدت محبوب بوده و مورد استفاده زیادی دارد و متاسفانه ما در ایران بیشتر از این لحاظ ضربه می خوریم و سو استفاده گران می توانند فی المجلس با جعل درخواست حسابهای بانکی را تخلیه کنند .
البته یک تکته بسیار ظریف در توضیحاتمان جا مانده بود ٰ آن هم اینکه جعل درخواست برای گرفتن ۱اسخ از طریق Server کافی نیست و حمله کننده یا هکر محترم نمی تواند پاسخ Server یا نرم افزار تحت وب را مستقیما خودش دریافت کند ، لذا هکر محترم حتما باید برای گرفتن پاسخ یک request sql تزریق کند تا به نتیجه دلخواهش برسد . البته هکر برای اجرای کد خود باید از طریق دو متد گت و پست با استفاده از جاوا اسکریپت استفاده کند (اگر در فیسبوک فعال باشید می توانید با در اختیار داشتن کدهای جاوای اینچنینی کارهای خارق العاده ای در این محیط انجام دهید و نفوذپذیری این اتبر سایت را به عینه مشاهده کنید و به ریش مارک بخندید – البته این را هم میدانم که گاها این نوع حرکت ها به honypot میخورید و فاتحه اکانتتان را خیلی شیک و مجلسی می خوانند ) . این نوع حمله اکثرا در مورد وب سایتهای .net قابل اجراست . یعنی برنامه نویس از قبل این حفره ها را مد نظر قرار نداده و وب سایت ها در مقابل درخواست های تعیین نشده جوابهای تعیین نشده به کاربر میدهند . در این روش علاوه بر اینکه روشهای مرسوم به نفوذ کلا دور زده می شود هویت اصلی هکر نیز غیر قابل شناخت میباشد – و قربانی همان فردی است که با اکانت وی این دستورات تزریق شده . اصولا وب سایتهایی که در این مورد ضعف دارند می توان به ضعیف بودن در مورد آسیب پذیری از طریق جاوا اسکریپت هم به آنها نمود داشت . البته باید توجه داشته باشیم که این دو روش کلا با هم متفاوت هستند در یکی ٰ هکر تخصص خود را برای بدست آوردن اطلاعات مهم و خصوصی قربانی بکار میگیرد و در دیگری هکر نیازی به داشتن این اطلاعات ندارد و صرفا جل درخواست می کندو به این نتیجه میرسیم که حمله CSRF آسان تر از روش جاوا بوده و عوامل محدود کننده کمتری دارد ولی روش جاوا نقاط ظریفی دارد که با دانش بسیار بالا میتوان به آنها دست یافت . این روش برای صرفا لاگین شدن طراحی شده و برای هکر مهم نیست شما با چه سیستمی وارد شده اید . اندروید – مک – و یا لینوکس ….
برای آشنایی با روش تزریق کدهای sql می توانید از نرم افزار هویج استفاده کنید و وب سایت خود را در باره موضوع تزریق کدهای sql بررسی کنید .
(مقاله حاضر فقط جنبه آمو.زشی و اطلاع رسانی برای وب مستر ها و برنامه نویسان وب سایت را دارد و هرگونه سو برداشت از آن و استفاده های نابجا از آن به عهده کاربر است ).
