ورود

View Full Version : حرفه ای: جلوگیری از ارسال اطلاعات از منابع غیر مجاز



فؤاد
یک شنبه 13 دی 1388, 21:11 عصر
فرض کنیم کاربر در صفحه (A) اطلاعات فرم را تکمیل و پس از کلیک روی کلید ثبت، اطلاعات به صفحه (B) پست میشود - صفحه (B) هم اطلاعات را مورد پردازش قرار میدهد.

اگر شخصی صفحه ای مشابه صفحه (A) بر روی دستگاه (Local) و یا سرور (Host) خود ایجاد کند و مقدار را به صفحه (B) سایت ما بفرستد اطلاعات ارسالی علی القاعده مورد پردازش قرار میگیرد.

در نظر بگیرید که در فرم موجود در صفحه اول (A) ما محدودیتهایی را از نظر دامنه انتخاب برای کاربر در نظر گرفته بودیم. بر فرض مثال یک Combo box با مقادیر الف، ب و ج .
اگر این شخص در صفحه ای که ساخته تعداد گزینه های Combo box را بیشتر از آن چیزی که باید وجود میداشته (الف، ب و ج) تعیین کند صفحه B میتواند دچار خطا شود و ....

برای جلوگیری از ارسال اطلاعات از منابع غیر مجاز راه های زیادی نظیر چک کردن HTTP_Referer وجود دارد
جدای از اینکه میتوان در صفحه B اطلاعات ارسال شده از صفحه قبل را چک کرد
شما چه راه هایی را پیشنهاد میکنید.

با تشکر

kashaneh
دوشنبه 14 دی 1388, 08:20 صبح
دوست عزیز براحتی می توانید از CAPTCHA مخفف "Completely Automated Public Turing test to tell Computers and Humans Apart" یا به عبارتی دیگر کدهای تصویری که به صورت رندوم تولید می شوند و شما قبل از ارسال فرم باید آنها را عینا وارد کنید استفاده کنید... مثل یاهو و جیمیل هنگام ساختن اکانت جدید یا ثبت نام در انجمن هایی مثل همینجا و خیلی جاهای دیگر...
البته فراموش نکنید که سیستم های تولید CAPTCHA متنوع بوده و هر کدام دارای درجه اطمینان خاصی هستند... نمونه های ASP هم برای این منظور فراوان یافت می شود مثل سایت WebWiz (http://www.webwizguide.com/webwizcaptcha/features.asp) که می توانید هم اطلاعات بیشتری کسب کنید و هم اینکه طریقه استفاده آن را یاد بگیرید... موفق باشی

فؤاد
دوشنبه 14 دی 1388, 12:34 عصر
سلام

راه حلی که شما پیشنهاد کرده اید عملا غیر قابل استفاده هست ؟

چرا ؟ چون:

1 - در تمامی صفحات یک سایت داینامیک که ممکن است تعداد صفحاتش کم هم نباشد، نمیتوان از Captcha استفاده کرد. در صورتی که از این راه استفاده کنیم کاربر بخت برگشته را درگیر خواندن و نوشتن Captchaها کرده ایم و این چندان خوشایند و (به نظر بنده) علمی نیست. استفاده از این روش برای تمام صفحات یک سایت داینامیک عملا ممکن نیست.

2 - مقادیر ارسالی میتواند هم از طریق QueryString و هم از طریق Form ارسال شده باشند. با این روش پیشنهادی شما برای ارسال اطلاعات از طریق QueryString چه خواهید کرد ؟

با تشکر

mehdi.mousavi
دوشنبه 14 دی 1388, 13:54 عصر
برای جلوگیری از ارسال اطلاعات از منابع غیر مجاز راه های زیادی نظیر چک کردن HTTP_Referer وجود دارد. جدای از اینکه میتوان در صفحه B اطلاعات ارسال شده از صفحه قبل را چک کرد شما چه راه هایی را پیشنهاد میکنید. با تشکر

سلام.
شما که خودتون پاسخ خودتون رو دادید. در صفحه B شما باید حتما اطلاعات ارسال شده رو چک کنید و ببینید آیا با خواسته های شما سمت سرور مطابقت داره یا خیر. این کار رو شما باید حتما انجام بدید، بدون توجه به اینکه منبع اطلاعات چی بوده، صفحه A یا نسخه دستکاری و Cache شده ای از صفحه A.

به این نکته دقت کنید! خیلی از برنامه نویسها میرن دنبال اینکه اطلاعات غیر مجاز ورودی چی هستن و هر چیزی غیر اونو مجاز میدونن. این کار کاملا اشتباه و خطرناکه! شما باید داده های مجاز رو ابتدا جدا کنید و هر چیزی غیر از اون رو غیر مجاز تلقی کنید.

موفق باشید.

فؤاد
دوشنبه 14 دی 1388, 15:36 عصر
سلام و تشکر از پاسخ شما

اگه دقت میکردید من تاکید کرده بود که

" جدای از اینکه میتوان در صفحه B اطلاعات ارسال شده از صفحه قبل را چک کرد"

یعنی فرض میکنیم این کار را نمیخواهم کنم ( چون این روش همیشه مفید واقع نمیشه) - بی خیال این روش


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

استفاده از متغیر سرور HTTP_Referer تا اندازه ای میتواند ( در بعضی حالات ) مفید واقع شود. ولی من دنبال روشی هستم که بشود بصورت دقیق منبع ارسال اطلاعات را مشخص کرد.

بیاد داشته باشید چهار حالت برای ارسال اطلاعات به صفحه (B) وجود دارد.

1 - مستقیما در مرورگر آدرس سایت و صفحه را وارد کنیم
2 - روی یکی از لینکهای سایت خودمان یا کلید Submit کلیک کنیم. ( جهت انتقال به صفحه B)ـ
3 - کاربر غیر مجاز اطلاعات را از طریق صفحه شبیه سازی شده از روی دستگاه لوکال خود به صفحه B سایت ما ارسال کند.
4 - کاربر غیر مجاز اطلاعات را از طریق صفحه شبیه سازی شده از روی سرور (IIS) خود به صفحه B سایت ما ارسال کند.

در موارد فوق تنها مورد 2 هست که از نظر ما مجاز میباشد. سه حالت دیگر غیر مجاز هستند.


راه حل فعلی من :
(همونطور که گفتم دنبال این هستم که ببینم راه های بهتری هم هست یا خیر )

اگر مقدار متغیر سرور Http_Reffer را چک کنیم و اگر تهی بود یا مربوط به آدرسی غیر از آدرس سایت ما بود برنامه اجرا نشود. خب این براحتی کار میکند و نیاز به چک کردن متغیر ها در صفحه (B) و Captcha نیست.

این روش تنها یک ایراد کوچک دارد:
اگر صفحه (A) و صفحه (B) یکی باشد روش فوق کار نخواهد کرد - چون اگر کاربر مستقیم آدرس سایت و صفحه را وارد کند مقدار Http_Reffer مساوی با تهی خواهد بود و صفحه اجرا نخواهد شد.

با تشکر

mehdi.mousavi
دوشنبه 14 دی 1388, 17:09 عصر
اگر مقدار متغیر سرور Http_Reffer را چک کنیم و اگر تهی بود یا مربوط به آدرسی غیر از آدرس سایت ما بود برنامه اجرا نشود. خب این براحتی کار میکند

سلام.
خیلی از برنامه نویسهای وب اطلاع ندارن که HTTP_REFERER کی و کجا set میشه، و ظاهرا شما هم جزء اون عده هستید که اینقدر مطمئن در موردش حرف میزنید! spoof کردن HTTP_REFERER چند لحظه بیشتر طول نمیکشه، یعنی مهاجم میتونه ظرف چند لحظه HTPP_REFERER رو توی Header درخواست عوض کنه و همون نسخه Cache شده Local اش رو با HTTP_REFERER دلخواه شما Submit کنه. البته چک کردنش سمت سرور میتونه جلوی 4 تا Code Junkies رو بگیره، اما برای کاربردهای حقیقی، مطلقا نمیشه روش حساب باز کرد.

موفق باشید.

پاورقی 1: اگر از چیزی اطلاع ندارید، بیخودی پاسخها رو "غیر مفید" مارک نکنید. اولین قانون امنیتی میگه که ورودیهای کاربر، شامل Query String، Form Data، Cookies و هر آنچیزی که کاربر می تونه تعیین کنه، اطلاعات "غیر قابل اعتماد" هستن. اونها رو باید، تکرار میکنم، باید اعتبار سنجی کرد. اعتبار سنجی نیز باید به این گونه باشه که ابتدا اطلاعات قابل اعتماد جدا بشه، هر آنچه که باقی موند، غیر قابل اعتماد تلقی بشه.

پاورقی 2: شما میتونید از Disposable URL ها استفاده کنید. بدین معنی که برای URL ها بازه زمانی در نظر بگیرید. مثلا، فلان URL فقط برای 3 دقیقه، معتبر هستش. بعد 3 دقیقه، اون URL وجود نخواهد داشت و هر کسی بخواد از اون URL استفاده کنه، سرش به سنگ میخوره. این روش البته با زیبایی و کارایی وب در وهله اول، در تضاد هستش. وب بدون Hyperlink مثل ویندوز بدون آیکون میمونه! (اینم یه جمله قصار دیگه :چشمک:). برای آشنایی با این روش، میتونید به مقالات اخیر مجله MSDN مراجعه کنید. اونجا، این مطلب به صراحت و دقت توضیح داده شده.

فؤاد
سه شنبه 15 دی 1388, 12:42 عصر
با سلام و تشکر از جناب موسوی

بله بنده هم جزء همون دسته بودم که بی اطلاع بودم / از راهنماییتون هم ممنونم

با این حال مشکل من پا برجاست: من دنبال شناسایی منبع (حقیقی) ارسال اطلاعات به فایل B هستم.

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