یک راه برای حمله CSRF علی رقم ندانستن token [بایگانی]

mahdavi13

سه شنبه 23 اردیبهشت 1393, 15:13 عصر

مقالات زیادی در مورد حملات 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 را در اختیار دارد و ممکن است بتواند حمله را با موفقیت انجام دهد.

به نظر شما راهکار چیست؟

omidabedi

سه شنبه 23 اردیبهشت 1393, 15:32 عصر

حمله ی csrf بر روی submit فرم از روی همون سایت دلالت داره

مهم session هست که ارسال بشه و در صفحه ی دیگه با hidden box مطابقت داده بشه

اگر شما با فرم دیگه ای کد رو بدست بیارید و بفرستید چگونه میخواید سشن رو انتقال بدید؟
مهم اینه

omidabedi

سه شنبه 23 اردیبهشت 1393, 15:38 عصر

در صورتی که سایت نفوذپذیری file inclusion داشته باشه حالا چه ریموت چه امن نبودن فرم اپلود این کار شدنی هست که اونم باید اسم سشن رو داشته باشی

که اگر اینجوری باگی داشته باشی دیگه اصلا نیاز به باگ csrf نداری در حالت عادی اما در موارد خاص میتونه موثر باشه مثلا کانفیگ سرور درست باشه safe mode روشن باشه دسترسی پوشه ها درست ست شده باشه و جوری باشه که شل کارایی خودش رو از دست بده (همین اپلودر شل یعنی همه چی :لبخند:) میشه از این روش استفاده کرد و از باگ csrf استفاده نمود

اینم بگم که patch کردن این باگ برای فرم های خاص هست مثلا پاک کردن یوزر سطح دسترسی ها تعریف یوزر جدید

اما فرم های معمولی مهم نیست که این باگ رو patch کنیم چون هکر استفاده ی خاصی نمیتونه ازش داشته باشه

mahdavi13

سه شنبه 23 اردیبهشت 1393, 20:08 عصر

حمله ی csrf بر روی submit فرم از روی همون سایت دلالت داره

مهم session هست که ارسال بشه و در صفحه ی دیگه با hidden box مطابقت داده بشه

اگر شما با فرم دیگه ای کد رو بدست بیارید و بفرستید چگونه میخواید سشن رو انتقال بدید؟
مهم اینه

خب این hidden box باید توی صفحه show_form.php باشه دیگه! کافیه ما همین صفحه رو آنالیز کنیم تا مقدار فیلد مخفی رو بدست بیاریم.

omidabedi

سه شنبه 23 اردیبهشت 1393, 23:09 عصر

خب این hidden box باید توی صفحه show_form.php باشه دیگه! کافیه ما همین صفحه رو آنالیز کنیم تا مقدار فیلد مخفی رو بدست بیاریم.

مهم فرستادن سشن هست hidden box رو که میشه کشید بیرون

eshpilen

چهارشنبه 24 اردیبهشت 1393, 10:16 صبح

مقالات زیادی در مورد حملات 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 (http://www.hamidreza-mz.tk/?p=903) در مرورگرها، که به شما اجازه نمیده محتویات اطلاعاتی رو که از دامین دیگری لود شده در صفحهء خودتون (با جاوااسکریپت) بخونید. بنابراین شما نمیتونید مقدار توکن امنیتی رو به این راحتی ها بدست بیارید :چشمک:

البته همچون دیگر موارد، در این زمینه هم بعضی مرورگرها نقص/باگ/حفره هایی داشته و دارن که اگر بتونید ازشون استفاده کنید اونوقت میتونید این مکانیزم رو دور بزنید.

mahdavi13

چهارشنبه 24 اردیبهشت 1393, 15:14 عصر

بله حق با شماست اینو نمی دونستم ممنون

metal gear solid 4

پنج شنبه 25 اردیبهشت 1393, 09:36 صبح

من به شما پیشنهاد میکنم 100% ویدئوهای آموزشی PHP Security Infinite Skills رو ببینید.
هم در زمینه PHP و هم در زمینه ی White Hacking ... .

omidabedi

پنج شنبه 25 اردیبهشت 1393, 11:06 صبح

تند خوندم و 100% مطمئن نیستم منظور شما رو متوجه شده باشم، اما به احتمال زیاد شما یک چیز رو نمیدونستید!
یه مفهومی هست بنام Same origin policy (http://www.hamidreza-mz.tk/?p=903) در مرورگرها، که به شما اجازه نمیده محتویات اطلاعاتی رو که از دامین دیگری لود شده در صفحهء خودتون (با جاوااسکریپت) بخونید. بنابراین شما نمیتونید مقدار توکن امنیتی رو به این راحتی ها بدست بیارید :چشمک:

البته همچون دیگر موارد، در این زمینه هم بعضی مرورگرها نقص/باگ/حفره هایی داشته و دارن که اگر بتونید ازشون استفاده کنید اونوقت میتونید این مکانیزم رو دور بزنید.

اقای eshpilen فک نکنم درست متوجه شدید

اقای مهدوی منظورشون اینه که ما میتونیم مقدار توکن رو از hidden box براحتی بدست بیاریم حالا چه دستی چه برنامه بنویسیم چه جاوااسکریپت چه php
مهم ارسال session هست که ایا میشه از بیرون مقدار دهی کرد؟
نام سشن توکن رو چجوری بفهمیم؟حالا میگیم اینو هم حدس زدیم (در cms ها و اسکریپت های معروف میشه نام سشن مورد نیاز رو بدست اورد)
چجوری سشن رو ارسال کنیم که اونطرف مقایسه بشه؟

البته ممکن هست بعد از مراحل بالا در هاست های اشتراکی بشه سشن رو ارسال کردا! میشه؟ نمیشه؟:متفکر:

omidabedi

پنج شنبه 25 اردیبهشت 1393, 11:13 صبح

تازه یک کاره دیگه هم میشه انجام داد که یهو به ذهنم رسید اما تست نکردم

میتونیم اون توکن رو مستقیم بعنوان valueه hidden box نزاریم بلکه بیایم معادل $_POSTه hidden box بزاریم که نشه از تو فرم کشیدش بیرون

تست نکردم هنوز اما فک کنم بشه

eshpilen

جمعه 26 اردیبهشت 1393, 12:22 عصر

اقای eshpilen فک نکنم درست متوجه شدید

اقای مهدوی منظورشون اینه که ما میتونیم مقدار توکن رو از hidden box براحتی بدست بیاریم حالا چه دستی چه برنامه بنویسیم چه جاوااسکریپت چه php
مهم ارسال session هست که ایا میشه از بیرون مقدار دهی کرد؟
نام سشن توکن رو چجوری بفهمیم؟حالا میگیم اینو هم حدس زدیم (در cms ها و اسکریپت های معروف میشه نام سشن مورد نیاز رو بدست اورد)
چجوری سشن رو ارسال کنیم که اونطرف مقایسه بشه؟

البته ممکن هست بعد از مراحل بالا در هاست های اشتراکی بشه سشن رو ارسال کردا! میشه؟ نمیشه؟:متفکر:
مهم اینه که مقدار توکن برای کلاینت مورد حمله باشه. وگرنه بله شما میتونید در سمت سرور و از طریق مثلا curl یک درخواست به سایت هدف بفرستید و یک توکن بدست بیارید، ولی این توکن توکن کلاینت مورد نظر نیست و مقدارش فقط برای خودتون معتبره و نمیتونه برای حمله از طریق اکانت کلاینت در سایت هدف استفاده بشه.
یک روش دیگر هست و اون اینکه فرم مورد نظر رو در سمت سرور خودمون نگیریم، بلکه بذاریم در سمت کلاینت لود بشه، که کد و منظور استارتر این بوده. در این روش، توکنی که سایت هدف به کلاینت ارسال میکنه، برای اون کلاینت توکن معتبری هست، چون درخواست از سمت کلاینت به سایت هدف ارسال میشه و تمام کوکی های احراز هویت کلاینت در این جریان به سایت هدف ارسال میشن و بنابراین کلاینت در سایت هدف احراز هویت میشه و یک توکن معتبر برای اون کلاینت خاص برگردونده میشه (البته این توکن ممکنه از قبل در کلاینت ست شده باشه - بهرحال نتیجه فرقی نمیکنه). خب در این حالت درسته که توکن معتبره، ولی شما بعنوان attacker مقدار اون رو نمیدونید و باید مقدارش رو بدست بیارید تا بتونید درخواستهای مورد نظر رو خودتون رو از جانب کلاینت به سایت هدف ارسال کنید، و در اینجاست که هرچی تلاش میکنید با جاوااسکریپت مقدار این توکن رو از پاسخ درخواست به سایت هدف بیرون بکشید، موفق نمیشید، چون Same origin policy (http://www.hamidreza-mz.tk/?p=903) در مرورگر به شما اجازهء دسترسی به محتویات صفحاتی رو که از دامین های دیگری لود شدن نمیده! نه میتونید سورس و کدهای HTML اون صفحه رو بخونید و نه میتونید کوکی هاش رو بخونید.
اسم سشن هم این وسط هیچ اهمیتی نداره! اسم سشن معمولا اطلاعات خطرناک و مخفی ای تلقی نمیشه و صرفا با بدست آوردن یا حدس زدن درست اون نمیشه هیچ کاری کرد، چون شما اولا نمیتونید برای یک دامین دیگر کوکی ست کنید، دوما محتویات کوکی سشن (session id) یا محتویات خود سشن در سمت سرور رو نمیتونید بخونید.

omidabedi

جمعه 26 اردیبهشت 1393, 12:48 عصر

مهم اینه که مقدار توکن برای کلاینت مورد حمله باشه. وگرنه بله شما میتونید در سمت سرور و از طریق مثلا curl یک درخواست به سایت هدف بفرستید و یک توکن بدست بیارید، ولی این توکن توکن کلاینت مورد نظر نیست و مقدارش فقط برای خودتون معتبره و نمیتونه برای حمله از طریق اکانت کلاینت در سایت هدف استفاده بشه.
یک روش دیگر هست و اون اینکه فرم مورد نظر رو در سمت سرور خودمون نگیریم، بلکه بذاریم در سمت کلاینت لود بشه، که کد و منظور استارتر این بوده. در این روش، توکنی که سایت هدف به کلاینت ارسال میکنه، برای اون کلاینت توکن معتبری هست، چون درخواست از سمت کلاینت به سایت هدف ارسال میشه و تمام کوکی های احراز هویت کلاینت در این جریان به سایت هدف ارسال میشن و بنابراین کلاینت در سایت هدف احراز هویت میشه و یک توکن معتبر برای اون کلاینت خاص برگردونده میشه (البته این توکن ممکنه از قبل در کلاینت ست شده باشه - بهرحال نتیجه فرقی نمیکنه). خب در این حالت درسته که توکن معتبره، ولی شما بعنوان attacker مقدار اون رو نمیدونید و باید مقدارش رو بدست بیارید تا بتونید درخواستهای مورد نظر رو خودتون رو از جانب کلاینت به سایت هدف ارسال کنید، و در اینجاست که هرچی تلاش میکنید با جاوااسکریپت مقدار این توکن رو از پاسخ درخواست به سایت هدف بیرون بکشید، موفق نمیشید، چون Same origin policy (http://www.hamidreza-mz.tk/?p=903) در مرورگر به شما اجازهء دسترسی به محتویات صفحاتی رو که از دامین های دیگری لود شدن نمیده! نه میتونید سورس و کدهای HTML اون صفحه رو بخونید و نه میتونید کوکی هاش رو بخونید.
اسم سشن هم این وسط هیچ اهمیتی نداره! اسم سشن معمولا اطلاعات خطرناک و مخفی ای تلقی نمیشه و صرفا با بدست آوردن یا حدس زدن درست اون نمیشه هیچ کاری کرد، چون شما اولا نمیتونید برای یک دامین دیگر کوکی ست کنید، دوما محتویات کوکی سشن (session id) یا محتویات خود سشن در سمت سرور رو نمیتونید بخونید.

حمله ی csrf به روی این تمرکز داره که فرم از روی همون سایت submit بشه خب فرم رو به روش post و get میشه از سرور دیگه فرستاد پس چی میمونه؟session که فقط بر روی همون سرور معتبره و نمیشه از خارج سشن ارسال کرد.

در حمله ی csrf شما میای از رو سرور جای دیگه حالا بصورت لینک یه هرجوری میخوای اطلاعات رو به روش get یا post به سرور سایت قربانی میفرستی
حالا استارتر اومده توی فرمی که طراحی کرده برای دورزدن patch مقدار token رو گرفته که به سرور قربانی ارسال کنه میخواسته ببینه میشه یا نه!
خب اطلاعات که به مقصد ارسال میشه اما وقتی که مقدار hidden box رو یا session چک میکنن میبینن که اشتباهه چرا؟ چونکه سشن ارسال نشده پس یعنی از روی همون سرور ارسال نشده..

این چیزی که شما میگید فکر کنم چیزه دیگه ای باشه و روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه

eshpilen

شنبه 27 اردیبهشت 1393, 08:11 صبح

روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه
در CSRF شما به کاربران یک سایت دیگر حمله میکنید، نه به خودتون.
میخواید به کاربران بگید که بیاید و اول این مرورگر قدیمی یا دستکاری شده رو جون من نصب کنید؟ :لبخند:

omidabedi

شنبه 27 اردیبهشت 1393, 09:41 صبح

در CSRF شما به کاربران یک سایت دیگر حمله میکنید، نه به خودتون.
میخواید به کاربران بگید که بیاید و اول این مرورگر قدیمی یا دستکاری شده رو جون من نصب کنید؟ :لبخند:

خوشم میاد مثله رسانه ها میاید نصف جمله ی منو پاک میکنیدااا :لبخند::قهقهه:

اصل جمله اینه

این چیزی که شما میگید فکر کنم چیزه دیگه ای باشه و روش دورزدن داره مثل استفاده از مرورگرهای قدیمی یا اصلا ساخت مرورگر اختصاصی یا دستکاری همین مرورگرها
open source هستن دیگه

روش شمارو من متوجه نشدم چیه اصلا

omidabedi

شنبه 27 اردیبهشت 1393, 10:02 صبح

بعدشم اینکه امنیت و روش های امنیتی باید طوری کامل و جامع باشن که برای هر حالتی جواب بدن و بسته به شرایط خاصی نباشه

مثل طراحی وب که میان cross browser میسازن.یعنی برای هر مرورگر برای بعضی قسمت ها کدهای جداگانه مینویسن که در همه حالت سایت قابل مشاهده باشه

اینکه بیایم یه patch برای csrf در نظر بگیریم و بگیم این فقط برای کسایی هست که مرورگرشون استاندارد و بروز هست اصلا منطقی نیست

امنیت نباید به سمت کاربر بسته باشه

کاربر هست قرار نیست برنامه نویس باشه

مهندسی اجتماع رو هم فراموش نکنیم که کاربر رو میشه متقاعد کنیم هرکاری انجام بده واسمون مثل نصب فلان مرورگر!

eshpilen

شنبه 27 اردیبهشت 1393, 10:36 صبح

خوشم میاد مثله رسانه ها میاید نصف جمله ی منو پاک میکنیدااا :لبخند::قهقهه:

اصل جمله اینه
آخه بقیش نامفهوم بود.
شما یکسری کلی گویی + مبهم گویی کردی تا اینجا. اصلا معلوم نیست چی میگی و چه روشی رو پیش میکشی.
نمونه کد بذار، یه الگوریتم رو قشنگ مشخص کن، که بررسیش کنیم.

روش شمارو من متوجه نشدم چیه اصلا
چه روشی؟
من روش خاصی برای چیزی ارائه نکردم، فقط روشی رو که استارتر مطرح کرده بود گفتم که چرا شدنی نیست.
حالا روش شما چیه دقیق بگو، تا بهت بگم چرا شدنی هست یا نیست.
اگر روش معقولی برای اجرای CSRF نداری که هیچ! منم میگم نمیشه دیگه. یعنی اونایی که توکن امنیتی دارن رو نمیشه به این راحتی ها دور زد.

eshpilen

شنبه 27 اردیبهشت 1393, 12:09 عصر

اینکه بیایم یه patch برای csrf در نظر بگیریم و بگیم این فقط برای کسایی هست که مرورگرشون استاندارد و بروز هست اصلا منطقی نیست
کدوم پچ؟!
Same origin policy (http://www.hamidreza-mz.tk/?p=903) به گمانم در مرورگرهای باستانی هم وجود داره! چون یه چیز روشن و اساسیه.

مهندسی اجتماع رو هم فراموش نکنیم که کاربر رو میشه متقاعد کنیم هرکاری انجام بده واسمون مثل نصب فلان مرورگر!
اگر بتونی کاربر رو متقاعد کنی یا گول بزنی که هرچی رو نصب کنه بهرصورت هیچ امنیتی وجود نخواهد داشت. مثلا یه برنامهء هک حسابی روی سیستمش نصب میکنی، دیگه نیازی به نصب و دستکاری مرورگر و استفاده از CSRF و این حرفا نیست، چون دسترسی کامل به سیستم کاربر داری و عملا میتونی هرکاری بکنی. این دیگه گردن برنامه نویس نیست! برنامه نویس اصلا چکار میتونه بکنه در چنین شرایطی؟!

omidabedi

شنبه 27 اردیبهشت 1393, 13:53 عصر

من بحثم رو تکه کد استارتر هست.
گفته اینجوری میشه فرم هایی رو که در برابر csrf امن هستن رو دور زد.
منم گفتم نمیشه.چرا؟ چونکه سشن اینجوری ارسال نمیشه و وقتی شما token رو میفرستی به صفحه ی چک کننده اصلا سشنی نیست که بخواد باهاش مقایسه کنه.

شما بحث same origin policy رو مطرح کردی که گفتی توی همه ی مرورگر ها قاعده اینه که اطلاعاتی رو که بوسیله ی جاوااسکریپت از سروری دیگر دریافت میکنن رو نمیتوانند بخونن!
من میگم این گفته ی شما متین اما اگرم اینجوری هم نبود و میتونستن اطلاعات رو بخونن بازم نمیشد دورش زد چون اصلا به این ربطی نداره

متاسفانه اصلا پست های قبلی رو نمیخونید همینجوری جواب میدید

منظور از patch یعنی patch کردن باگه !
گفتم وقتی میگن یه باگ patch شده که در همه ی شرایط باگ patch شده باشه و کار به مرورگر و باگ مرورگر طبق گفته ی شما نداشته باشه در غیر این صورت هنوز اسیب پذیری هست!

برای مهندسی اجتماع هم مثال بود نگفتم همینو نقد کن ! عجبا
بعضی وقتا یه تکه کد کوچک هکر بفهمه معماش حل میشه

omidabedi

شنبه 27 اردیبهشت 1393, 13:57 عصر

در ضمن patch باگ csrf اینجوریه که توی صفحه ی فرم کدی generate میشه بنام token که همش داریم روش بحث میکنیم.

از این کد 2جا استفاده میشه

1.توی hidden box

2.session

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

شاید patch دیگه ای براش باشه اما مورد بحث من این روش هست

eshpilen

شنبه 27 اردیبهشت 1393, 18:59 عصر

من بحثم رو تکه کد استارتر هست.
گفته اینجوری میشه فرم هایی رو که در برابر csrf امن هستن رو دور زد.
منم گفتم نمیشه.چرا؟ چونکه سشن اینجوری ارسال نمیشه و وقتی شما token رو میفرستی به صفحه ی چک کننده اصلا سشنی نیست که بخواد باهاش مقایسه کنه.

شما بحث same origin policy رو مطرح کردی که گفتی توی همه ی مرورگر ها قاعده اینه که اطلاعاتی رو که بوسیله ی جاوااسکریپت از سروری دیگر دریافت میکنن رو نمیتوانند بخونن!
من میگم این گفته ی شما متین اما اگرم اینجوری هم نبود و میتونستن اطلاعات رو بخونن بازم نمیشد دورش زد چون اصلا به این ربطی نداره

هان الان توضیح دادی بیشتر روشن شد که مشکل در کجاست!
ببین موقعی که مرورگر درخواستی به سایتی میفرسته، تمام کوکی های مربوط به اون دامین رو هم بصورت خودکار بهش ارسال میکنه؛ منجمله کوکی سشن رو (درصورت وجود - یعنی مثلا اگر کاربر در سایت مورد نظر لاگین باشه).
پس شما بعنوان حمله کننده CSRF نیازی نداری که کار خاصی دیگری بکنی؛ یعنی اگر مقدار توکن امنیتی رو بدست آورده باشی، بقیش توسط مرورگر بصورت خودکار انجام میشه و نیازی نیست هیچ کار دیگری انجام بدی (کافیه پارامترهای فرم/درخواست رو ست و بعد ارسال کنی - البته این کار باید در سمت کلاینت و از طریق مرورگر قربانی صورت بگیره).
با دانستن مقدار توکن امنیتی، کار تمامه!

منظور از patch یعنی patch کردن باگه !
گفتم وقتی میگن یه باگ patch شده که در همه ی شرایط باگ patch شده باشه و کار به مرورگر و باگ مرورگر طبق گفته ی شما نداشته باشه در غیر این صورت هنوز اسیب پذیری هست!

patch کردن باگهای نرم افزارهای مختلف و سیستم عامل و بطور کلی امنیت زیربنایی کلاینت، وظیفهء برنامه نویس نیست و نمیتونه.
صدها باگ هست در انواع و نسخه های مختلف مرورگرها، سیستم عامل، فلش و بقیهء پلاگین ها و غیره. شما میگی برنامه نویس چه وظیفه ای در این زمینه داره و چطور میتونه بهش عمل کنه؟!

omidabedi

یک شنبه 28 اردیبهشت 1393, 01:38 صبح

هان الان توضیح دادی بیشتر روشن شد که مشکل در کجاست!
ببین موقعی که مرورگر درخواستی به سایتی میفرسته، تمام کوکی های مربوط به اون دامین رو هم بصورت خودکار بهش ارسال میکنه؛ منجمله کوکی سشن رو (درصورت وجود - یعنی مثلا اگر کاربر در سایت مورد نظر لاگین باشه).
پس شما بعنوان حمله کننده CSRF نیازی نداری که کار خاصی دیگری بکنی؛ یعنی اگر مقدار توکن امنیتی رو بدست آورده باشی، بقیش توسط مرورگر بصورت خودکار انجام میشه و نیازی نیست هیچ کار دیگری انجام بدی (کافیه پارامترهای فرم/درخواست رو ست و بعد ارسال کنی - البته این کار باید در سمت کلاینت و از طریق مرورگر قربانی صورت بگیره).
با دانستن مقدار توکن امنیتی، کار تمامه!

patch کردن باگهای نرم افزارهای مختلف و سیستم عامل و بطور کلی امنیت زیربنایی کلاینت، وظیفهء برنامه نویس نیست و نمیتونه.
صدها باگ هست در انواع و نسخه های مختلف مرورگرها، سیستم عامل، فلش و بقیهء پلاگین ها و غیره. شما میگی برنامه نویس چه وظیفه ای در این زمینه داره و چطور میتونه بهش عمل کنه؟!

خب برای اینکه هکر نتونه token رو بدست بیاره ما میتونیم token رو برابر به $_POSTه hidden box بزاریم بجای اینکه بیایم بعنوان value بزاریم که هکر بتونه بخونتش اینجوری فکر کنم درست بشه.

برای patch یه باگ هم من میگم باید توی همه ی شرایطی ایمن باشه تا بشه بگی که یک باگ patch شده
وظیفه ی برنامه نویس اینه که شرایط مختلفی رو چک کنه برای اینکه متوجه بشه برنامش ایمن هست و به یک شرایط اکتفا نکنه

شرایط ازمایشگاهی و توعمل شاید خیلی باهم متفاوت باشن
منظورم اینه

eshpilen

یک شنبه 28 اردیبهشت 1393, 10:31 صبح

خب برای اینکه هکر نتونه token رو بدست بیاره ما میتونیم token رو برابر به $_POSTه hidden box بزاریم بجای اینکه بیایم بعنوان value بزاریم که هکر بتونه بخونتش اینجوری فکر کنم درست بشه.

متوجه نشدم.
سمت کلاینت چطوری این کار رو بکنیم؟ یعنی با ایجکس فرم رو ارسال کنیم و مقدار توکن رو اون موقع توی پارامترهای درخواست POST ست کنیم؟

omidabedi

یک شنبه 28 اردیبهشت 1393, 13:11 عصر

<?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 میشه پس دیگه خونده نمیتونه بشه

eshpilen

یک شنبه 28 اردیبهشت 1393, 18:32 عصر

<?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 جلوگیری میکنه؟!

omidabedi

یک شنبه 28 اردیبهشت 1393, 19:38 عصر

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 مشکل داره چرا :متفکر:

***BiDaK***

یک شنبه 28 اردیبهشت 1393, 20:34 عصر

بازم اشتباهه.
توکن هر سری generate میشه برفرض.توو کد شما زمانی که post back میشه توکن مقدار جدید میگیره و با مقدار ارسالی از طرف فرم هیچ وقت برابر نمیشه.
نکته ی دیگه اینکه شما باید مقدار پست شده از فرم رو مقایسه کنید با مقدار سشن token نه اینکه مقدار بهش بدید.مقدار توکن هم باید در تگ hidden وجود داشته باشه و ...
قضیه ی این token$ داخل تک کوت چیه!!

omidabedi

یک شنبه 28 اردیبهشت 1393, 21:20 عصر

بازم اشتباهه.
توکن هر سری generate میشه برفرض.توو کد شما زمانی که post back میشه توکن مقدار جدید میگیره و با مقدار ارسالی از طرف فرم هیچ وقت برابر نمیشه.
نکته ی دیگه اینکه شما باید مقدار پست شده از فرم رو مقایسه کنید با مقدار سشن token نه اینکه مقدار بهش بدید.مقدار توکن هم باید در تگ hidden وجود داشته باشه و ...
قضیه ی این token$ داخل تک کوت چیه!!

این کد فقط برای ساخت تصور ذهنی هست و حالت ماکت داره

$token هم tokenی هست که generate شده

از اولویت ها در php اطلاعات دقیقی ندارم واسه همین مطمئن نیستم درست باشه گذاشتم بررسی بشه

eshpilen

دوشنبه 29 اردیبهشت 1393, 08:24 صبح

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 جلوگیری کنید.

SA_Developer

دوشنبه 29 اردیبهشت 1393, 09:37 صبح

دوستان توضیحات کافی رو دادن اما فکر کنم این تاپیک به چند تا لینک هم نیاز داره( صرفا جهت اطلاع! )
http://blog.ircmaxell.com/2013/02/preventing-csrf-attacks.html
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_S heet
http://stackoverflow.com/a/2526579

omidabedi

دوشنبه 29 اردیبهشت 1393, 12:18 عصر

این کد کاملا بی معنیه. یعنی عملا هیچ کاری برای جلوگیری از CSRF انجام نمیده.
ظاهرا شما اصلا درک نکردید که علت و مکانیزم جلوگیری از این حمله چیه.
وقتی شما در درخواستی که از سمت کلاینت میاد، هیچ اطلاعات محرمانه (رندوم و یکتا به ازای هر کلاینت) ندارید که بتونید بر اساس اون بین درخواستهای عادی و درخواستهای ارسال شده بدون اطلاع کاربر تشخیص بدید، نمیتونید از CSRF جلوگیری کنید.

اگه منظورتون این هست که کدی generate نشده
کد generate شده همون $token هست که الگوریتمشو ننوشتم چون فک میکردم نیازی نباشه و کد گویا باشه

omidabedi

دوشنبه 29 اردیبهشت 1393, 12:20 عصر

شما خودتون میشه یه patch برای این باگ ارائه بدید؟
چون بگفته ی شما راه حل رایج ایمن نیست

eshpilen

دوشنبه 29 اردیبهشت 1393, 14:15 عصر

اگه منظورتون این هست که کدی generate نشده
کد generate شده همون $token هست که الگوریتمشو ننوشتم چون فک میکردم نیازی نباشه و کد گویا باشه
دیگه ماست مالی نکن دیگه :لبخند:
کدی که گذاشتی اصلا چیزی رو نشون نمیده، صرفا یکسری کارهای بی معنی سمت سرور کردی که هیچ خاصیتی نداره؛ هیچ ایده و کلیت چیزی هم درش نیامده. یه توکن تولید کردی بعد خودت سمت سرور میریزی توی آرایه post که چی بشه؟!
این یکی از بی معنی ترین و عجیب ترین کدهایی بود که در عرض چند سال دیدم :متعجب:
خودت فهمیدی چیه و چطوری کار میکنه واسه ما هم توضیح بده.

شما خودتون میشه یه patch برای این باگ ارائه بدید؟
چون بگفته ی شما راه حل رایج ایمن نیست
راه حلش همون توکن امنیتی است که باید در تمام فرمها و لینک ها بذارید.
باگ و ضعفی هم باشه توی مرورگر و بخشهای دیگر سمت کلاینت است که وظیفه و دست برنامه نویس نیست. بیش از این دیگه نمیشه کاری کرد، یا اگر هم بشه بهرصورت صرف نمیکنه. کسی نمیتونه بیاد این همه مرورگر و این همه نسخه رو همه رو بررسی کنه و صدها و هزاران باگ اونا رو پیدا و براشون راهکار پیاده کنه که در خیلی موارد اصلا نمیشه درمان اصولی و قطعی هم کرد (فقط هم CSRF نیست). بجاش توصیه میشه کاربران از بهترین مرورگرهای به روز استفاده کنن. نهایت خیلی وسواس باشی میتونی نوع مرورگر کاربر رو تشخیص بدی و اگر قدیمی باشه (یا مثلا IE باشه!!)، همون اول شوتش کنی بیرون بگی برو مرورگرت رو آپدیت کن.
امنیت اصولی و بالا/حداکثری داریم، ولی 100% و مطلق و تضمین شده خیر.
منم گفتم بدونید که با این وجود ممکنه یوقت یجا از این باگها باشه و از اون طریق این مکانیزم رو دور بزنن. فقط بخاطر اینکه بدونید و روی امنیت مطلق حساب نکنید و دیگه اینکه اگر یجا حملهء موفقیت آمیزی انجام شد زود برداشت های سطحی و ناشیانه دیگری نکنید فکر کنید که این روش ضعف ذاتی داره، و نرید دنبال راه حلهای غیراصولی و پیچوندن های مسخره.

omidabedi

دوشنبه 29 اردیبهشت 1393, 14:25 عصر

[QUOTE=eshpilen;2025462]دیگه ماست مالی نکن دیگه :لبخند:
کدی که گذاشتی اصلا چیزی رو نشون نمیده، صرفا یکسری کارهای بی معنی سمت سرور کردی که هیچ خاصیتی نداره؛ هیچ ایده و کلیت چیزی هم درش نیامده. یه توکن تولید کردی بعد خودت سمت سرور میریزی توی آرایه post که چی بشه؟!
این یکی از بی معنی ترین و عجیب ترین کدهایی بود که در عرض چند سال دیدم :متعجب:
خودت فهمیدی چیه و چطوری کار میکنه واسه ما هم توضیح بده.

ماست مالی چیه!
هدف من اینه که کدی از همین صفحه ارسال بشه اما کاربر نتونه بکشتش بیرون!

omidabedi

دوشنبه 29 اردیبهشت 1393, 14:26 عصر

خوب که گفتم این کد حالت ماکت داره برای اینکه حرفامو بهتر متوجه بشه خواننده!

eshpilen

دوشنبه 29 اردیبهشت 1393, 14:32 عصر

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

rezaonline.net

یک شنبه 18 خرداد 1393, 16:42 عصر

من زیاد نتونستم وارد بحثتون بشم و نخوندم بعضی پستها رو اما میتونید از token رندم استفاده کنید دیگه این مشکل رو ندارید و دقیقتره

omidabedi

یک شنبه 18 خرداد 1393, 17:15 عصر

اقای eshpilen میگن توکن رو توی کوکی اگر ذخیره بشه میشه ازش سوء استفاده کرد داشتیم دنبال راهی برای این میگشتیم

اما خب هیچ برنامه نویسی ندیدم tokenی که برای csrf درنظر گرفته رو هم توی کوکی ذخیره کنه

eshpilen

دوشنبه 19 خرداد 1393, 12:33 عصر

سوالتون دقیقا چی بود متوجه نشدم!