نشت اطلاعات / Information leakage

نشت اطلاعات هر زمان که سیستمی که برای بسته بودن دربرابر یک استراق سمع کننده طراحی شده است با این وجود اطلاعاتی را برای طرفهای غیرمجاز فاش میکند اتفاق می افتد. برای مثال، وقتی یک شبکهء پیام رسانی فوری رمزگذاری شده طراحی میشود، یک مهندس شبکه بدون توانایی کرک کردن کدهای رمز شما میتواند مشاهده کند که چه زمانی شما پیامهایی را ارسال میکنید، حتی اگر نتواند آنها را بخواند. در طول جنگ جهانی دوم، ژاپنی ها برای مدتی از کدهای سری همچون PURPLE استفاده میکردند؛ حتی قبل از اینکه چنان کدهایی کرک شوند، مقداری اطلاعات پایه دربارهء محتویات پیام میتوانست با نگاه کردن به اینکه کدام ایستگاههای رله یک پیام را به پیش میراندند استخراج شود.

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

نشت اطلاعات میتواند بصورت ظریف یا بطور کامل امنیت یک سیستمی را که در غیر اینصورت امن میبود تخریب کند.

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

سه راه اصلی برای انجام آن وجود دارند:

- از steganography برای پنهان کردن این واقعیت که شما اصلا درحال ارسال یک پیام هستید استفاده کنید.

- از chaffing برای مبهم ساختن آنکه دارید به چه کسی پیام ارسال میکنید استفاده کنید (اما این روش این واقعیت را که شما درحال ارسال پیام هستید از دیگران پنهان نمیکند).

- برای پراکسی های دوباره ارسال کنندهء شلوغ، همچون یک گرهء Mixmaste: تاخیرهای تصادفی ایجاد کنید و ترتیب بسته های خارج شونده را بهم بریزید – این در مخفی کردن مسیر یک پیام مفروض کمک خواهد کرد، بخصوص اگر چندین گرهء forward کننده متداول، همچون آنهایی که بوسیلهء mixmaster mail forwarding بکار گرفته میشوند، وجود دارند.

=========================

منبع: http://en.wikipedia.org/wiki/Information_leakage

—————————

نشت اطلاعات در وب خیلی زیاد داریم. حالا کوچک و بزرگ داره از نظر اهمیت.

مثلا سیستمهایی که هکر با چند تست ساده و بخصوص با روبات میتونه اطلاعاتی مثل ایمیل های ثبت شده در سایت رو چک کنه، نشت اطلاعاتی دارن.

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

همینطور چک کردن ایجکسی نام کاربری در فرم ثبت نام، خودش ایجاد یا حداقل تشدید و راحت کردن Information leakage است. ولی خب ظاهرا حداقل در این مورد در اکثر سیستمها این یوزرفرندلی مهمتر از نشت اطلاعات محسوب میشه. ولی برنامه های امن احتمالا باید امکان غیرفعال کردن این ویژگی رو هم داشته باشن (بنده در پروژهء خودم این امکان رو گذاشتم دقیقا به همین دلیل). هرچند راههای تست موجودیت نام کاربری متعدد هست و جلوگیری از تمام اونها کار رو پیچیده و دشوار میکنه و کد و کار قابل توجهی میبره. حتی باید Timing ها رو هم بحساب آورد. مثلا در بخش لاگین سایت، معمولا تنها درصورت وجود یک نام کاربری هست که یک هش امنیتی محاسبه و مقایسه میشه، و هش امنیتی هم بخصوص بخاطر Key stretching، زمان قابل توجهی صرف میکنه، که این اختلاف زمان حداقل در چند بار تکرار درخواست و بطور متوسط احتمالا کاملا قابل تشخیص خواهد بود. بنابراین بطور مثال بنده حتی درصورت عدم وجود نام کاربری هم یک هش امنیتی رو محاسبه میکنم. اما تازه بحث اختلاف کوئری های دیتابیس و اینها باقیست. ولی جلوگیری از اینا دیگه اینقدر مشکله و از طرف دیگر چون اختلاف زمانی که ایجاد میکنه کمتر و تشخیص اون مشکل تره (در بعضی موارد عملا غیرممکن)، که شخصا بی خیالش شدم.

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

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

خلاصه این قصه سر دراز دارد…

—————————

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

با همین Timing که یک نوع متداول (و البته دشوار از نظر جلوگیری) از نشت اطلاعات است تونستن کلید خصوصی یک سرور رو استخراج کنن که بدترین نوع هک محسوب میشه، چون با کلید خصوصی که فوق امنیتی هست میشه تقریبا هرکاری و هر جعلی رو انجام داد. البته این حمله بعنوان یک آزمایش آکادمیک و در روی LAN انجام شد (ضمنا فکر میکنم نرم افزار سرورش در زبان جاوا بوده و اونطور که فهمیدم جاوا در این زمینه آسیب پذیرتر بوده)، اما بهرحال این چیز زیادی از اهمیت این یافته ها کم نمیکنه و هشدار مهمی است دربارهء اینکه کوچکترین نشت های اطلاعاتی در ظاهر، میتونن مهم باشن و منجر به خسارت های فاجعه بار بشن.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>