-
یک راه برای حمله CSRF علی رقم ندانستن token
مقالات زیادی در مورد حملات CSRF خواندم تقریبا همه آنها به استفاده از یک رشته تصادفی در فرم برای مقابله با این حملات اشاره کرده اند اما احساس می کنم این ترفند نمی تواند کاملا امن باشد. بعنوان مثال هکر می تواند صفحه زیر را بسازد و کاربر را ترقیب به مشاهده آن کند:
<body onload="document.getElementById('frm1').submit();" >
<script>
function1(request='http://mainsite.com/show_form.php')
{
// codes
}
</script>
<form action="http://mainsite.com/submit_form.php?action=delete" method="post" id="frm1">
<input name="id" value="2" type="hidden" />
<script>document.write('<input name="token" type="hidden" value="' + function1() + '" />");</script>
</form>
function1 در این مثال چیزی شبیه به file_get_contents() در php است با این تفاوت که الگریتمی دارد که می تواند مقدار token فرم را از کد html صفحه سایت اصلی بدست آورد. با این مثال هکر مقدار token را در اختیار دارد و ممکن است بتواند حمله را با موفقیت انجام دهد.
به نظر شما راهکار چیست؟
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
حمله ی csrf بر روی submit فرم از روی همون سایت دلالت داره
مهم session هست که ارسال بشه و در صفحه ی دیگه با hidden box مطابقت داده بشه
اگر شما با فرم دیگه ای کد رو بدست بیارید و بفرستید چگونه میخواید سشن رو انتقال بدید؟
مهم اینه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
در صورتی که سایت نفوذپذیری file inclusion داشته باشه حالا چه ریموت چه امن نبودن فرم اپلود این کار شدنی هست که اونم باید اسم سشن رو داشته باشی
که اگر اینجوری باگی داشته باشی دیگه اصلا نیاز به باگ csrf نداری در حالت عادی اما در موارد خاص میتونه موثر باشه مثلا کانفیگ سرور درست باشه safe mode روشن باشه دسترسی پوشه ها درست ست شده باشه و جوری باشه که شل کارایی خودش رو از دست بده (همین اپلودر شل یعنی همه چی :لبخند:) میشه از این روش استفاده کرد و از باگ csrf استفاده نمود
اینم بگم که patch کردن این باگ برای فرم های خاص هست مثلا پاک کردن یوزر سطح دسترسی ها تعریف یوزر جدید
اما فرم های معمولی مهم نیست که این باگ رو patch کنیم چون هکر استفاده ی خاصی نمیتونه ازش داشته باشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
حمله ی csrf بر روی submit فرم از روی همون سایت دلالت داره
مهم session هست که ارسال بشه و در صفحه ی دیگه با hidden box مطابقت داده بشه
اگر شما با فرم دیگه ای کد رو بدست بیارید و بفرستید چگونه میخواید سشن رو انتقال بدید؟
مهم اینه
خب این hidden box باید توی صفحه show_form.php باشه دیگه! کافیه ما همین صفحه رو آنالیز کنیم تا مقدار فیلد مخفی رو بدست بیاریم.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
mahdavi13
خب این hidden box باید توی صفحه show_form.php باشه دیگه! کافیه ما همین صفحه رو آنالیز کنیم تا مقدار فیلد مخفی رو بدست بیاریم.
مهم فرستادن سشن هست hidden box رو که میشه کشید بیرون
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
mahdavi13
مقالات زیادی در مورد حملات CSRF خواندم تقریبا همه آنها به استفاده از یک رشته تصادفی در فرم برای مقابله با این حملات اشاره کرده اند اما احساس می کنم این ترفند نمی تواند کاملا امن باشد. بعنوان مثال هکر می تواند صفحه زیر را بسازد و کاربر را ترقیب به مشاهده آن کند:
<body onload="document.getElementById('frm1').submit();" >
<script>
function1(request='http://mainsite.com/show_form.php')
{
// codes
}
</script>
<form action="http://mainsite.com/submit_form.php?action=delete" method="post" id="frm1">
<input name="id" value="2" type="hidden" />
<script>document.write('<input name="token" type="hidden" value="' + function1() + '" />");</script>
</form>
function1 در این مثال چیزی شبیه به file_get_contents() در php است با این تفاوت که الگریتمی دارد که می تواند مقدار token فرم را از کد html صفحه سایت اصلی بدست آورد. با این مثال هکر مقدار token را در اختیار دارد و ممکن است بتواند حمله را با موفقیت انجام دهد.
به نظر شما راهکار چیست؟
تند خوندم و 100% مطمئن نیستم منظور شما رو متوجه شده باشم، اما به احتمال زیاد شما یک چیز رو نمیدونستید!
یه مفهومی هست بنام Same origin policy در مرورگرها، که به شما اجازه نمیده محتویات اطلاعاتی رو که از دامین دیگری لود شده در صفحهء خودتون (با جاوااسکریپت) بخونید. بنابراین شما نمیتونید مقدار توکن امنیتی رو به این راحتی ها بدست بیارید :چشمک:
البته همچون دیگر موارد، در این زمینه هم بعضی مرورگرها نقص/باگ/حفره هایی داشته و دارن که اگر بتونید ازشون استفاده کنید اونوقت میتونید این مکانیزم رو دور بزنید.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
بله حق با شماست اینو نمی دونستم ممنون
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
من به شما پیشنهاد میکنم 100% ویدئوهای آموزشی PHP Security Infinite Skills رو ببینید.
هم در زمینه PHP و هم در زمینه ی White Hacking ... .
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
eshpilen
تند خوندم و 100% مطمئن نیستم منظور شما رو متوجه شده باشم، اما به احتمال زیاد شما یک چیز رو نمیدونستید!
یه مفهومی هست بنام
Same origin policy در مرورگرها، که به شما اجازه نمیده محتویات اطلاعاتی رو که از دامین دیگری لود شده در صفحهء خودتون (با جاوااسکریپت) بخونید. بنابراین شما نمیتونید مقدار توکن امنیتی رو به این راحتی ها بدست بیارید :چشمک:
البته همچون دیگر موارد، در این زمینه هم بعضی مرورگرها نقص/باگ/حفره هایی داشته و دارن که اگر بتونید ازشون استفاده کنید اونوقت میتونید این مکانیزم رو دور بزنید.
اقای eshpilen فک نکنم درست متوجه شدید
اقای مهدوی منظورشون اینه که ما میتونیم مقدار توکن رو از hidden box براحتی بدست بیاریم حالا چه دستی چه برنامه بنویسیم چه جاوااسکریپت چه php
مهم ارسال session هست که ایا میشه از بیرون مقدار دهی کرد؟
نام سشن توکن رو چجوری بفهمیم؟حالا میگیم اینو هم حدس زدیم (در cms ها و اسکریپت های معروف میشه نام سشن مورد نیاز رو بدست اورد)
چجوری سشن رو ارسال کنیم که اونطرف مقایسه بشه؟
البته ممکن هست بعد از مراحل بالا در هاست های اشتراکی بشه سشن رو ارسال کردا! میشه؟ نمیشه؟:متفکر:
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
تازه یک کاره دیگه هم میشه انجام داد که یهو به ذهنم رسید اما تست نکردم
میتونیم اون توکن رو مستقیم بعنوان valueه hidden box نزاریم بلکه بیایم معادل $_POSTه hidden box بزاریم که نشه از تو فرم کشیدش بیرون
تست نکردم هنوز اما فک کنم بشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
اقای eshpilen فک نکنم درست متوجه شدید
اقای مهدوی منظورشون اینه که ما میتونیم مقدار توکن رو از hidden box براحتی بدست بیاریم حالا چه دستی چه برنامه بنویسیم چه جاوااسکریپت چه php
مهم ارسال session هست که ایا میشه از بیرون مقدار دهی کرد؟
نام سشن توکن رو چجوری بفهمیم؟حالا میگیم اینو هم حدس زدیم (در cms ها و اسکریپت های معروف میشه نام سشن مورد نیاز رو بدست اورد)
چجوری سشن رو ارسال کنیم که اونطرف مقایسه بشه؟
البته ممکن هست بعد از مراحل بالا در هاست های اشتراکی بشه سشن رو ارسال کردا! میشه؟ نمیشه؟:متفکر:
مهم اینه که مقدار توکن برای کلاینت مورد حمله باشه. وگرنه بله شما میتونید در سمت سرور و از طریق مثلا curl یک درخواست به سایت هدف بفرستید و یک توکن بدست بیارید، ولی این توکن توکن کلاینت مورد نظر نیست و مقدارش فقط برای خودتون معتبره و نمیتونه برای حمله از طریق اکانت کلاینت در سایت هدف استفاده بشه.
یک روش دیگر هست و اون اینکه فرم مورد نظر رو در سمت سرور خودمون نگیریم، بلکه بذاریم در سمت کلاینت لود بشه، که کد و منظور استارتر این بوده. در این روش، توکنی که سایت هدف به کلاینت ارسال میکنه، برای اون کلاینت توکن معتبری هست، چون درخواست از سمت کلاینت به سایت هدف ارسال میشه و تمام کوکی های احراز هویت کلاینت در این جریان به سایت هدف ارسال میشن و بنابراین کلاینت در سایت هدف احراز هویت میشه و یک توکن معتبر برای اون کلاینت خاص برگردونده میشه (البته این توکن ممکنه از قبل در کلاینت ست شده باشه - بهرحال نتیجه فرقی نمیکنه). خب در این حالت درسته که توکن معتبره، ولی شما بعنوان attacker مقدار اون رو نمیدونید و باید مقدارش رو بدست بیارید تا بتونید درخواستهای مورد نظر رو خودتون رو از جانب کلاینت به سایت هدف ارسال کنید، و در اینجاست که هرچی تلاش میکنید با جاوااسکریپت مقدار این توکن رو از پاسخ درخواست به سایت هدف بیرون بکشید، موفق نمیشید، چون Same origin policy در مرورگر به شما اجازهء دسترسی به محتویات صفحاتی رو که از دامین های دیگری لود شدن نمیده! نه میتونید سورس و کدهای HTML اون صفحه رو بخونید و نه میتونید کوکی هاش رو بخونید.
اسم سشن هم این وسط هیچ اهمیتی نداره! اسم سشن معمولا اطلاعات خطرناک و مخفی ای تلقی نمیشه و صرفا با بدست آوردن یا حدس زدن درست اون نمیشه هیچ کاری کرد، چون شما اولا نمیتونید برای یک دامین دیگر کوکی ست کنید، دوما محتویات کوکی سشن (session id) یا محتویات خود سشن در سمت سرور رو نمیتونید بخونید.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
eshpilen
مهم اینه که مقدار توکن برای کلاینت مورد حمله باشه. وگرنه بله شما میتونید در سمت سرور و از طریق مثلا curl یک درخواست به سایت هدف بفرستید و یک توکن بدست بیارید، ولی این توکن توکن کلاینت مورد نظر نیست و مقدارش فقط برای خودتون معتبره و نمیتونه برای حمله از طریق اکانت کلاینت در سایت هدف استفاده بشه.
یک روش دیگر هست و اون اینکه فرم مورد نظر رو در سمت سرور خودمون نگیریم، بلکه بذاریم در سمت کلاینت لود بشه، که کد و منظور استارتر این بوده. در این روش، توکنی که سایت هدف به کلاینت ارسال میکنه، برای اون کلاینت توکن معتبری هست، چون درخواست از سمت کلاینت به سایت هدف ارسال میشه و تمام کوکی های احراز هویت کلاینت در این جریان به سایت هدف ارسال میشن و بنابراین کلاینت در سایت هدف احراز هویت میشه و یک توکن معتبر برای اون کلاینت خاص برگردونده میشه (البته این توکن ممکنه از قبل در کلاینت ست شده باشه - بهرحال نتیجه فرقی نمیکنه). خب در این حالت درسته که توکن معتبره، ولی شما بعنوان attacker مقدار اون رو نمیدونید و باید مقدارش رو بدست بیارید تا بتونید درخواستهای مورد نظر رو خودتون رو از جانب کلاینت به سایت هدف ارسال کنید، و در اینجاست که هرچی تلاش میکنید با جاوااسکریپت مقدار این توکن رو از پاسخ درخواست به سایت هدف بیرون بکشید، موفق نمیشید، چون
Same origin policy در مرورگر به شما اجازهء دسترسی به محتویات صفحاتی رو که از دامین های دیگری لود شدن نمیده! نه میتونید سورس و کدهای HTML اون صفحه رو بخونید و نه میتونید کوکی هاش رو بخونید.
اسم سشن هم این وسط هیچ اهمیتی نداره! اسم سشن معمولا اطلاعات خطرناک و مخفی ای تلقی نمیشه و صرفا با بدست آوردن یا حدس زدن درست اون نمیشه هیچ کاری کرد، چون شما اولا نمیتونید برای یک دامین دیگر کوکی ست کنید، دوما محتویات کوکی سشن (session id) یا محتویات خود سشن در سمت سرور رو نمیتونید بخونید.
حمله ی csrf به روی این تمرکز داره که فرم از روی همون سایت submit بشه خب فرم رو به روش post و get میشه از سرور دیگه فرستاد پس چی میمونه؟session که فقط بر روی همون سرور معتبره و نمیشه از خارج سشن ارسال کرد.
در حمله ی csrf شما میای از رو سرور جای دیگه حالا بصورت لینک یه هرجوری میخوای اطلاعات رو به روش get یا post به سرور سایت قربانی میفرستی
حالا استارتر اومده توی فرمی که طراحی کرده برای دورزدن patch مقدار token رو گرفته که به سرور قربانی ارسال کنه میخواسته ببینه میشه یا نه!
خب اطلاعات که به مقصد ارسال میشه اما وقتی که مقدار hidden box رو یا session چک میکنن میبینن که اشتباهه چرا؟ چونکه سشن ارسال نشده پس یعنی از روی همون سرور ارسال نشده..
این چیزی که شما میگید فکر کنم چیزه دیگه ای باشه و روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه
در CSRF شما به کاربران یک سایت دیگر حمله میکنید، نه به خودتون.
میخواید به کاربران بگید که بیاید و اول این مرورگر قدیمی یا دستکاری شده رو جون من نصب کنید؟ :لبخند:
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
eshpilen
در CSRF شما به کاربران یک سایت دیگر حمله میکنید، نه به خودتون.
میخواید به کاربران بگید که بیاید و اول این مرورگر قدیمی یا دستکاری شده رو جون من نصب کنید؟ :لبخند:
خوشم میاد مثله رسانه ها میاید نصف جمله ی منو پاک میکنیدااا :لبخند::قهقهه:
اصل جمله اینه
نقل قول:
این چیزی که شما میگید فکر کنم چیزه دیگه ای باشه و روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه
روش شمارو من متوجه نشدم چیه اصلا
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
بعدشم اینکه امنیت و روش های امنیتی باید طوری کامل و جامع باشن که برای هر حالتی جواب بدن و بسته به شرایط خاصی نباشه
مثل طراحی وب که میان cross browser میسازن.یعنی برای هر مرورگر برای بعضی قسمت ها کدهای جداگانه مینویسن که در همه حالت سایت قابل مشاهده باشه
اینکه بیایم یه patch برای csrf در نظر بگیریم و بگیم این فقط برای کسایی هست که مرورگرشون استاندارد و بروز هست اصلا منطقی نیست
امنیت نباید به سمت کاربر بسته باشه
کاربر هست قرار نیست برنامه نویس باشه
مهندسی اجتماع رو هم فراموش نکنیم که کاربر رو میشه متقاعد کنیم هرکاری انجام بده واسمون مثل نصب فلان مرورگر!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
خوشم میاد مثله رسانه ها میاید نصف جمله ی منو پاک میکنیدااا :لبخند::قهقهه:
اصل جمله اینه
آخه بقیش نامفهوم بود.
شما یکسری کلی گویی + مبهم گویی کردی تا اینجا. اصلا معلوم نیست چی میگی و چه روشی رو پیش میکشی.
نمونه کد بذار، یه الگوریتم رو قشنگ مشخص کن، که بررسیش کنیم.
نقل قول:
روش شمارو من متوجه نشدم چیه اصلا
چه روشی؟
من روش خاصی برای چیزی ارائه نکردم، فقط روشی رو که استارتر مطرح کرده بود گفتم که چرا شدنی نیست.
حالا روش شما چیه دقیق بگو، تا بهت بگم چرا شدنی هست یا نیست.
اگر روش معقولی برای اجرای CSRF نداری که هیچ! منم میگم نمیشه دیگه. یعنی اونایی که توکن امنیتی دارن رو نمیشه به این راحتی ها دور زد.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
اینکه بیایم یه patch برای csrf در نظر بگیریم و بگیم این فقط برای کسایی هست که مرورگرشون استاندارد و بروز هست اصلا منطقی نیست
کدوم پچ؟!
Same origin policy به گمانم در مرورگرهای باستانی هم وجود داره! چون یه چیز روشن و اساسیه.
نقل قول:
مهندسی اجتماع رو هم فراموش نکنیم که کاربر رو میشه متقاعد کنیم هرکاری انجام بده واسمون مثل نصب فلان مرورگر!
اگر بتونی کاربر رو متقاعد کنی یا گول بزنی که هرچی رو نصب کنه بهرصورت هیچ امنیتی وجود نخواهد داشت. مثلا یه برنامهء هک حسابی روی سیستمش نصب میکنی، دیگه نیازی به نصب و دستکاری مرورگر و استفاده از CSRF و این حرفا نیست، چون دسترسی کامل به سیستم کاربر داری و عملا میتونی هرکاری بکنی. این دیگه گردن برنامه نویس نیست! برنامه نویس اصلا چکار میتونه بکنه در چنین شرایطی؟!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
من بحثم رو تکه کد استارتر هست.
گفته اینجوری میشه فرم هایی رو که در برابر csrf امن هستن رو دور زد.
منم گفتم نمیشه.چرا؟ چونکه سشن اینجوری ارسال نمیشه و وقتی شما token رو میفرستی به صفحه ی چک کننده اصلا سشنی نیست که بخواد باهاش مقایسه کنه.
شما بحث same origin policy رو مطرح کردی که گفتی توی همه ی مرورگر ها قاعده اینه که اطلاعاتی رو که بوسیله ی جاوااسکریپت از سروری دیگر دریافت میکنن رو نمیتوانند بخونن!
من میگم این گفته ی شما متین اما اگرم اینجوری هم نبود و میتونستن اطلاعات رو بخونن بازم نمیشد دورش زد چون اصلا به این ربطی نداره
متاسفانه اصلا پست های قبلی رو نمیخونید همینجوری جواب میدید
منظور از patch یعنی patch کردن باگه !
گفتم وقتی میگن یه باگ patch شده که در همه ی شرایط باگ patch شده باشه و کار به مرورگر و باگ مرورگر طبق گفته ی شما نداشته باشه در غیر این صورت هنوز اسیب پذیری هست!
برای مهندسی اجتماع هم مثال بود نگفتم همینو نقد کن ! عجبا
بعضی وقتا یه تکه کد کوچک هکر بفهمه معماش حل میشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
در ضمن patch باگ csrf اینجوریه که توی صفحه ی فرم کدی generate میشه بنام token که همش داریم روش بحث میکنیم.
از این کد 2جا استفاده میشه
1.توی hidden box
2.session
و سپس جفتش میرن به صفحه ی دیگه برای چک شدن
اونجا این دوتارو مقایسه میکنن اگر برابر بود که معلوم میشه از همون صفحه ی سایت اومدن
اگر نه معلوم میشه از اونجا نیومدن و درخواست از سرور دیگه ای اومده
شاید patch دیگه ای براش باشه اما مورد بحث من این روش هست
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
من بحثم رو تکه کد استارتر هست.
گفته اینجوری میشه فرم هایی رو که در برابر csrf امن هستن رو دور زد.
منم گفتم نمیشه.چرا؟ چونکه سشن اینجوری ارسال نمیشه و وقتی شما token رو میفرستی به صفحه ی چک کننده اصلا سشنی نیست که بخواد باهاش مقایسه کنه.
شما بحث same origin policy رو مطرح کردی که گفتی توی همه ی مرورگر ها قاعده اینه که اطلاعاتی رو که بوسیله ی جاوااسکریپت از سروری دیگر دریافت میکنن رو نمیتوانند بخونن!
من میگم این گفته ی شما متین اما اگرم اینجوری هم نبود و میتونستن اطلاعات رو بخونن بازم نمیشد دورش زد چون اصلا به این ربطی نداره
هان الان توضیح دادی بیشتر روشن شد که مشکل در کجاست!
ببین موقعی که مرورگر درخواستی به سایتی میفرسته، تمام کوکی های مربوط به اون دامین رو هم بصورت خودکار بهش ارسال میکنه؛ منجمله کوکی سشن رو (درصورت وجود - یعنی مثلا اگر کاربر در سایت مورد نظر لاگین باشه).
پس شما بعنوان حمله کننده CSRF نیازی نداری که کار خاصی دیگری بکنی؛ یعنی اگر مقدار توکن امنیتی رو بدست آورده باشی، بقیش توسط مرورگر بصورت خودکار انجام میشه و نیازی نیست هیچ کار دیگری انجام بدی (کافیه پارامترهای فرم/درخواست رو ست و بعد ارسال کنی - البته این کار باید در سمت کلاینت و از طریق مرورگر قربانی صورت بگیره).
با دانستن مقدار توکن امنیتی، کار تمامه!
نقل قول:
منظور از patch یعنی patch کردن باگه !
گفتم وقتی میگن یه باگ patch شده که در همه ی شرایط باگ patch شده باشه و کار به مرورگر و باگ مرورگر طبق گفته ی شما نداشته باشه در غیر این صورت هنوز اسیب پذیری هست!
patch کردن باگهای نرم افزارهای مختلف و سیستم عامل و بطور کلی امنیت زیربنایی کلاینت، وظیفهء برنامه نویس نیست و نمیتونه.
صدها باگ هست در انواع و نسخه های مختلف مرورگرها، سیستم عامل، فلش و بقیهء پلاگین ها و غیره. شما میگی برنامه نویس چه وظیفه ای در این زمینه داره و چطور میتونه بهش عمل کنه؟!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
eshpilen
هان الان توضیح دادی بیشتر روشن شد که مشکل در کجاست!
ببین موقعی که مرورگر درخواستی به سایتی میفرسته، تمام کوکی های مربوط به اون دامین رو هم بصورت خودکار بهش ارسال میکنه؛ منجمله کوکی سشن رو (درصورت وجود - یعنی مثلا اگر کاربر در سایت مورد نظر لاگین باشه).
پس شما بعنوان حمله کننده CSRF نیازی نداری که کار خاصی دیگری بکنی؛ یعنی اگر مقدار توکن امنیتی رو بدست آورده باشی، بقیش توسط مرورگر بصورت خودکار انجام میشه و نیازی نیست هیچ کار دیگری انجام بدی (کافیه پارامترهای فرم/درخواست رو ست و بعد ارسال کنی - البته این کار باید در سمت کلاینت و از طریق مرورگر قربانی صورت بگیره).
با دانستن مقدار توکن امنیتی، کار تمامه!
patch کردن باگهای نرم افزارهای مختلف و سیستم عامل و بطور کلی امنیت زیربنایی کلاینت، وظیفهء برنامه نویس نیست و نمیتونه.
صدها باگ هست در انواع و نسخه های مختلف مرورگرها، سیستم عامل، فلش و بقیهء پلاگین ها و غیره. شما میگی برنامه نویس چه وظیفه ای در این زمینه داره و چطور میتونه بهش عمل کنه؟!
خب برای اینکه هکر نتونه token رو بدست بیاره ما میتونیم token رو برابر به $_POSTه hidden box بزاریم بجای اینکه بیایم بعنوان value بزاریم که هکر بتونه بخونتش اینجوری فکر کنم درست بشه.
برای patch یه باگ هم من میگم باید توی همه ی شرایطی ایمن باشه تا بشه بگی که یک باگ patch شده
وظیفه ی برنامه نویس اینه که شرایط مختلفی رو چک کنه برای اینکه متوجه بشه برنامش ایمن هست و به یک شرایط اکتفا نکنه
شرایط ازمایشگاهی و توعمل شاید خیلی باهم متفاوت باشن
منظورم اینه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
خب برای اینکه هکر نتونه token رو بدست بیاره ما میتونیم token رو برابر به $_POSTه hidden box بزاریم بجای اینکه بیایم بعنوان value بزاریم که هکر بتونه بخونتش اینجوری فکر کنم درست بشه.
متوجه نشدم.
سمت کلاینت چطوری این کار رو بکنیم؟ یعنی با ایجکس فرم رو ارسال کنیم و مقدار توکن رو اون موقع توی پارامترهای درخواست POST ست کنیم؟
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
<?php session_start();$_SESSION['token'] = '$token';if(isset($_POST['submit']){$_POST['hidden_box'] = '$token';}?><form name="login-form" action="check-form.php" method="post"> <input></input> <input></input> <input></input> <input type="hidden_box"></input> <input name="submit" type="submit"></input></form>
ایا الان درست میشه؟
hidden box مقدار نداره وقتی print میشه پس دیگه خونده نمیتونه بشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
<?php
session_start();
$_SESSION['token'] = '$token';
if(isset($_POST['submit']){
$_POST['hidden_box'] = '$token';
}
?>
<form name="login-form" action="check-form.php" method="post">
<input></input> <input></input> <input></input>
<input type="hidden_box"></input>
<input name="submit" type="submit"></input>
</form>
این چینه، من نوفهمم :متفکر:
توکن باید در سمت کلاینت موجود باشه و با بقیهء فرم سابمیت شده باشه، بعد در سمت سرور چک میکنی که با توکن موجود در سشن یکی باشه مقدارش.
شما اومدی چکار کردی سمت سرور و چرا نمیدونم!
این کد الان چطوری از CSRF جلوگیری میکنه؟!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
oops یه تیکشو ننوشتم ببخشید الان درستش میکنم
<?phpsession_start();$_SESSION['token'] = '$token';if(isset($_POST['submit']) && $_POST['auth'] == 1){ $_POST['hidden_box'] = '$token';}?><form name="login-form" action="check-form.php" method="post"><input></input> <input></input> <input></input><input type="hidden_box"></input><input type="hidden" name="auth" value="1"></input><input name="submit" type="submit"></input></form>
الان فکر کنم درست باشه
این syntaxx highlighter php مشکل داره چرا :متفکر:
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
بازم اشتباهه.
توکن هر سری generate میشه برفرض.توو کد شما زمانی که post back میشه توکن مقدار جدید میگیره و با مقدار ارسالی از طرف فرم هیچ وقت برابر نمیشه.
نکته ی دیگه اینکه شما باید مقدار پست شده از فرم رو مقایسه کنید با مقدار سشن token نه اینکه مقدار بهش بدید.مقدار توکن هم باید در تگ hidden وجود داشته باشه و ...
قضیه ی این token$ داخل تک کوت چیه!!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
***BiDaK***
بازم اشتباهه.
توکن هر سری generate میشه برفرض.توو کد شما زمانی که post back میشه توکن مقدار جدید میگیره و با مقدار ارسالی از طرف فرم هیچ وقت برابر نمیشه.
نکته ی دیگه اینکه شما باید مقدار پست شده از فرم رو مقایسه کنید با مقدار سشن token نه اینکه مقدار بهش بدید.مقدار توکن هم باید در تگ hidden وجود داشته باشه و ...
قضیه ی این token$ داخل تک کوت چیه!!
این کد فقط برای ساخت تصور ذهنی هست و حالت ماکت داره
$token هم tokenی هست که generate شده
از اولویت ها در php اطلاعات دقیقی ندارم واسه همین مطمئن نیستم درست باشه گذاشتم بررسی بشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
oops یه تیکشو ننوشتم ببخشید الان درستش میکنم
<?php
session_start();
$_SESSION['token'] = '$token';
if(isset($_POST['submit']) && $_POST['auth'] == 1) {
$_POST['hidden_box'] = '$token';
}
?>
<form name="login-form" action="check-form.php" method="post">
<input></input> <input></input> <input></input>
<input type="hidden_box">
</input>
<input type="hidden" name="auth" value="1">
</input>
<input name="submit" type="submit">
</input>
</form>
الان فکر کنم درست باشه
این syntaxx highlighter php مشکل داره چرا :متفکر:
این کد کاملا بی معنیه. یعنی عملا هیچ کاری برای جلوگیری از CSRF انجام نمیده.
ظاهرا شما اصلا درک نکردید که علت و مکانیزم جلوگیری از این حمله چیه.
وقتی شما در درخواستی که از سمت کلاینت میاد، هیچ اطلاعات محرمانه (رندوم و یکتا به ازای هر کلاینت) ندارید که بتونید بر اساس اون بین درخواستهای عادی و درخواستهای ارسال شده بدون اطلاع کاربر تشخیص بدید، نمیتونید از CSRF جلوگیری کنید.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
eshpilen
این کد کاملا بی معنیه. یعنی عملا هیچ کاری برای جلوگیری از CSRF انجام نمیده.
ظاهرا شما اصلا درک نکردید که علت و مکانیزم جلوگیری از این حمله چیه.
وقتی شما در درخواستی که از سمت کلاینت میاد، هیچ اطلاعات محرمانه (رندوم و یکتا به ازای هر کلاینت) ندارید که بتونید بر اساس اون بین درخواستهای عادی و درخواستهای ارسال شده بدون اطلاع کاربر تشخیص بدید، نمیتونید از CSRF جلوگیری کنید.
اگه منظورتون این هست که کدی generate نشده
کد generate شده همون $token هست که الگوریتمشو ننوشتم چون فک میکردم نیازی نباشه و کد گویا باشه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
شما خودتون میشه یه patch برای این باگ ارائه بدید؟
چون بگفته ی شما راه حل رایج ایمن نیست
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
نقل قول:
نوشته شده توسط
omidabedi
اگه منظورتون این هست که کدی generate نشده
کد generate شده همون $token هست که الگوریتمشو ننوشتم چون فک میکردم نیازی نباشه و کد گویا باشه
دیگه ماست مالی نکن دیگه :لبخند:
کدی که گذاشتی اصلا چیزی رو نشون نمیده، صرفا یکسری کارهای بی معنی سمت سرور کردی که هیچ خاصیتی نداره؛ هیچ ایده و کلیت چیزی هم درش نیامده. یه توکن تولید کردی بعد خودت سمت سرور میریزی توی آرایه post که چی بشه؟!
این یکی از بی معنی ترین و عجیب ترین کدهایی بود که در عرض چند سال دیدم :متعجب:
خودت فهمیدی چیه و چطوری کار میکنه واسه ما هم توضیح بده.
نقل قول:
شما خودتون میشه یه patch برای این باگ ارائه بدید؟
چون بگفته ی شما راه حل رایج ایمن نیست
راه حلش همون توکن امنیتی است که باید در تمام فرمها و لینک ها بذارید.
باگ و ضعفی هم باشه توی مرورگر و بخشهای دیگر سمت کلاینت است که وظیفه و دست برنامه نویس نیست. بیش از این دیگه نمیشه کاری کرد، یا اگر هم بشه بهرصورت صرف نمیکنه. کسی نمیتونه بیاد این همه مرورگر و این همه نسخه رو همه رو بررسی کنه و صدها و هزاران باگ اونا رو پیدا و براشون راهکار پیاده کنه که در خیلی موارد اصلا نمیشه درمان اصولی و قطعی هم کرد (فقط هم CSRF نیست). بجاش توصیه میشه کاربران از بهترین مرورگرهای به روز استفاده کنن. نهایت خیلی وسواس باشی میتونی نوع مرورگر کاربر رو تشخیص بدی و اگر قدیمی باشه (یا مثلا IE باشه!!)، همون اول شوتش کنی بیرون بگی برو مرورگرت رو آپدیت کن.
امنیت اصولی و بالا/حداکثری داریم، ولی 100% و مطلق و تضمین شده خیر.
منم گفتم بدونید که با این وجود ممکنه یوقت یجا از این باگها باشه و از اون طریق این مکانیزم رو دور بزنن. فقط بخاطر اینکه بدونید و روی امنیت مطلق حساب نکنید و دیگه اینکه اگر یجا حملهء موفقیت آمیزی انجام شد زود برداشت های سطحی و ناشیانه دیگری نکنید فکر کنید که این روش ضعف ذاتی داره، و نرید دنبال راه حلهای غیراصولی و پیچوندن های مسخره.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
[QUOTE=eshpilen;2025462]دیگه ماست مالی نکن دیگه :لبخند:
کدی که گذاشتی اصلا چیزی رو نشون نمیده، صرفا یکسری کارهای بی معنی سمت سرور کردی که هیچ خاصیتی نداره؛ هیچ ایده و کلیت چیزی هم درش نیامده. یه توکن تولید کردی بعد خودت سمت سرور میریزی توی آرایه post که چی بشه؟!
این یکی از بی معنی ترین و عجیب ترین کدهایی بود که در عرض چند سال دیدم :متعجب:
خودت فهمیدی چیه و چطوری کار میکنه واسه ما هم توضیح بده.
ماست مالی چیه!
هدف من اینه که کدی از همین صفحه ارسال بشه اما کاربر نتونه بکشتش بیرون!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
خوب که گفتم این کد حالت ماکت داره برای اینکه حرفامو بهتر متوجه بشه خواننده!
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
آقا جان شما سمت سرور هرچی میخوای تولید کن توی هر متغییری که میخوای بریز، خاصیتش چیه آخه؟
توکن امنیتی باید از سمت کلاینت هم ارسال شده باشه و چک کنید با توکنی که قبلا سمت سرور ذخیره شده، تا بتونید درخواستهای واقعی رو از جعلی تشخیص بدید.
الان سیستم شما چطوری تشخیص میده که درخواست چطوری ارسال شده؟ فرقی بین درخواستی که خود کاربر ارسال کرده با درخواستی که توسط یک سایت دیگر ایجاد شده هست و کجاست چطوری سیستم شما تشخیص میده با این کار در سمت سرور؟
میگم شما اصلا متوجه نشدی داستان چیه.
بهرحال مجبوریم توکن رو بفرستیم توی فرم ها و لینک ها، که موقع ارسال درخواستها از سمت کلاینت توکن هم همراهش باشه. غیر از این نمیشه. راه دیگه نداره. یعنی نوع توکنی غیر از این نمیشه. یه راه دیگه بعنوان راه غیر توکنی اینه که referrer رو چک کنی که از دامین خودت باشه، ولی یه مشکلش اینه که هدر referrer در https وجود نداره/ارسال نمیشه.
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
من زیاد نتونستم وارد بحثتون بشم و نخوندم بعضی پستها رو اما میتونید از token رندم استفاده کنید دیگه این مشکل رو ندارید و دقیقتره
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
اقای eshpilen میگن توکن رو توی کوکی اگر ذخیره بشه میشه ازش سوء استفاده کرد داشتیم دنبال راهی برای این میگشتیم
اما خب هیچ برنامه نویسی ندیدم tokenی که برای csrf درنظر گرفته رو هم توی کوکی ذخیره کنه
-
نقل قول: یک راه برای حمله CSRF علی رقم ندانستن token
سوالتون دقیقا چی بود متوجه نشدم!
