نوشته‌ها

مدیریت ریسک امنیت اطلاعات

/در , /توسط

فرآیند شناسایی، ارزیابی و کنترل تهدیدات به منظور محافظت از دارایی‌‌ها و درآمد سازمان مدیریت ریسک امنیت اطلاعات نامیده می‌شود.‌ این فرآیند می‌بایست با فرهنگ سازمان و مدیریت مخاطرات‌ سازمان متناسب  و هم‌راستا باشد.

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

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

مدیریت ریسک‌ امنیت اطلاعات همواره بخشی جدانشدنی از تمامی اقدامات مدیریت امنیت اطلاعات می‌باشد و همچنین در پیاده‌سازی و بهره‌‌برداری مداوم سیستم مدیریت امنیت اطلاعات (ISMS) به‌کار می‌رود.

این فرآیند می‌بایست به صورت مستمری باشد به طوریکه زمینه درونی و بیرونی سازمان را در نظر گرفته و بر این اساس، ریسک‌ها را ارزیابی نماید و با استفاده از برنامه اجرای توصیه‌ها و تصمیمات ریسک‌های بالاتر از توان تحمل سازمان را برطرف نماید.

جهت انجام فرآیند مدیریت ریسک استانداردهای متفاوتی وجود دارد که در اینجا برخی از آن‌ها ذکر شده است:

۱  مدیریت ریسک‌ امنیت اطلاعات

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

خروجی حاصل از مرحله ارزیابی ریسک شامل سناریوهای ریسکی هستند که در محدوده‌های متفاوتی نظیر قابل‌قبول و یا غیرقابل قبول برای سازمان دسته‌بندی می‌شوند. برای ریسک‌های غیر قابل‌قبول ۴ رویکرد اصلی که در ادامه به تشریح آن‌ها می‌پردازیم، در پیش‌روی سازمان وجود دارد.

در این مرحله سازمان می بایست استراتژی و برنامه خود برای برخورد و مقابله با ریسک‌های پذیرش نشده را تعیین نماید. مهم‌ترین خروجی این بخش طرح مقابله با ریسک (RTP) می‌باشد که در آن سازمان ضمن اولویت‌بندی ریسک‌ها، هر یک از اقدامات مدنظر خود را به منظور مقابله با آن‌ها تشریح می‌نماید.

مدیریت ریسک امنیت اطلاعات به موارد زیر کمک می‌کند:

  • شناسایی و ارزیابی ریسک
  • درک احتمال ریسک و عواقب آن برای کسب و کار
  • ایجاد دستور اولویت‌دهی برای کاهش ریسک
  • مشارکت ذی‌نفعان در تصمیمات مدیریت ریسک
  • اثربخشی نظارت بر کاهش ریسک
  • آگاهی کارکنان از خطرات و اقدامات انجام شده برای کاهش آن‌ها.

مدیریت ریسک‌ها امنیت اطلاعات، باید شامل موارد زیر باشد:

  • شناسایی ریسک‌ها
  • ارزیابی ریسک‌ها، بر حسب پیامدهای‌شان برای کسب و کار و احتمال وقوع آن‌ها
  • گفتمان و درک در مورد احتمال و پیامدهای ریسک‌ها
  • تعیین اولویت‌ها برای کاهش ریسک
  • تعیین اولویت‌ها برای اقدامات کاهش وقوع ریسک
  • دخیل کردن ذی‌نفعان در اخذ تصمیمات مدیریت ریسک‌ها و آگاهی رساندن به آن‌ها از وضعیت مدیریت ریسک‌ها
  • اثربخشی پایش مقابله با ریسک
  • پایش و بررسی منظم ریسک‌ها و فرآیند مدیریت ریسک‌
  • جمع‌آوری اطلاعات به‌منظور بهبود رویکرد ریسک‌
  • آموزش به مدیران و کارکنان در رابطه با ریسک‌ها و اقدامات کاهش ریسک‌

توجه: فرآیند مدیریت ریسک‌ امنیت اطلاعات را می‌توان به کل سازمان و یا به بخش‌هایی از سازمان تعمیم داد.

۲   بررسی ISO 27005

این استاندارد از زیرمجموعه استاندارد‌‌ها‌ی خانواده ISO 27000  محسوب می‌گردد که  به بررسی و تشریح فرآیند‌ها‌ی مدیریت امنیت اطللاعات می‌پردازد. در واقع چارچوب استاندارد ISO/IEC 27005 مبتنی بر شناسایی دارایی‌‌ها‌، آسیب‌پذیری‌‌ها‌ و تهدیدات جهت ارزیابی و محاسبه ریسک می‌باشد که رفع آن‌ها‌ از طریق مجموعه‌ا‌ی از کنترل‌‌ها‌ی مقابله‌ا‌ی برنامه‌ریزی می‌گردد.

فراهم‌­سازی دستورالعمل­‌ها‌یی برای مدیریت ریسک امنیت اطلاعات هدف اصلی ISO 27005 می‌­باشد. این استاندارد کلیه مفاهیم بیان‌­شده در استاندارد ISO 27001 را پشتیبانی می‌­نماید و جهت پیاده­‌سازی امنیت اطلاعات براساس رویکرد مدیریت ریسک طراحی شده است.

توصیه‌‌‌ها‌ و راهنمایی‌‌‌ها‌ی ارائه شده در ISO / IEC 27005 برای همه سازمان‌‌‌ها‌، صرف نظر از اندازه و نوع آن قابل اجرا هستند، همچنین مشاوره و راهنمایی در مورد مدیریت ریسک در ISO27005 قابل اجرا است. شناخت مفاهیم، ​​مدل‌‌ها‌، فرآیند‌‌ها‌ و اصطلاحات شرح داده شده در ISO / IEC 27001 و ISO / IEC 27002 برای درک کامل ISO / IEC 27005: 2018 مهم است.

۲-۱   فرآیند مدیریت ریسک ISO 27005

همانطور که در تصویر زیر مشاهده می‌‏شود، فرآیند مدیریت ریسک شامل زیرفرآیندهای زیر است:

اگرچه ISO 27005 هیچ روش خاصی برای مدیریت ریسک مشخص نمی‌کند، اما بر فرآیند پیوسته مدیریت ریسک اطلاعات مبتنی بر اجزاء کلیدی زیر دلالت دارد:

  1. زمینه‌سازی
  2. شناسایی ریسک
  3. تحلیل ریسک
  4. ارزشیابی ریسک
  5. واکنش به ریسک
  6. پذیرش ریسک
  7. ارتباط و مشاوره
  8. نظارت و بازبینی ریسک
  9. زمینه‌سازی: چارچوب مدیریت ریسک معیارهایی را برای نحوه شناسایی ریسک‌ها، مسئولیت مالکیت ریسک، تأثیر ریسک‌ها بر محرمانه بودن، صحت و در دسترس بودن اطلاعات و نحوه محاسبه تأثیر و احتمال ریسک تعیین می‌کند.

در این مرحله زمینه داخلی و خارجی مدیریت ریسک امنیت اطلاعات پایه‌گذاری می‌شود که شامل تنظیم معیارهای بنیادی برای مدیریت ریسک امنیت اطلاعات است. موارد زیر در این مرحله مد نظر قرار می‌گیرد:

  • تعیین رویكرد و روش مدیریت ریسک
  • تعیین معیارهای ارزیابی ریسک
  • تعیین معیارهای پیامد
  • تعیین معیارهای پذیرش ریسک
  • تعریف محدوده و قلمرو مدیریت ریسک امنیت اطلاعات
  • سازماندهی
  • شناسایی ریسک: فرآیند شناسایی ریسک مبتنی بر دارایی را که شامل پنج مرحله کلیدی زیر است، در این مرحله انجام می‌گردد:
  • گردآوری دارایی‌های اطلاعاتی
  • شناسایی تهدیدها و آسیب پذیری‌های قابل اعمال برای هر دارایی
  • تعیین ارزش تاثیر و احتمال بر اساس معیارهای ریسک
  • ارزیابی هر ریسک در برابر سطوح از پیش تعیین شده مقبولیت
  • اولویت‌بندی و ترتیب خطرات احتمالی
  • تحلیل ریسک

تحلیل ریسک با توجه به سطح جزئیات مورد نظر، میزان حیاتی بودن دارایی‌ها، گستره تحلیل ریسک آسیب‌پذیری‌های شناخته شده و نیز رخدادهای دربرگیرنده سازمان انجام می‌شود. روش تحلیل ریسک می‌تواند كمی و یا كیفی و یا تلفیقی از هر دو باشد. این مرحله شامل گام‌های زیر است:

  • ارزیابی پیامدها
  • ارزشیابی احتمال رخداد
  • تعیین سطح ریسک
  • ارزشیابی ریسک

در این زیر فرآیند بر اساس معیارهای استخراج شده در زیر فرآیند تحلیل ریسک، سطح پذیرش ریسک و ریسک‌‏های قابل پذیرش استخراج می‏شوند. به عبارت دیگر فعالیت‌‏های انجام شده در این مرحله عبارتند از:

  • تعیین معیار پذیرش ریسک
  • مقایسه ریسک‌‏های تحلیل شده با معیار پذیرش، اولویت‏‌بندی ریسک‌‏ها و تعیین ریسک‏‌های قابل پذیرش
  • برخورد با ریسک: چهار راه برای برخورد با ریسک وجود دارد، فرآیند برخورد با ریسک در انتخاب اقدامات امنیتی به منظور،كاهش، حفظ، اجتناب و انتقال انجام می‌شود:
  • تغییر (اصلاح) ریسک
  • انتقال (اشتراك) ریسک
  • اجتناب از ریسک
  • حفظ ریسک
  • پذیرش ریسک

در این مرحله تصمیم‌گیری در خصوص پذیرش ریسک امنیت اطلاعات صورت می‌گیرد. باید توجه داشت كه تصمیمات مرتبط با پذیرش ریسک و نیز مسئولیت تصمیم‌گیری باید به طور رسمی ثبت گردد.

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

فعالیت‌های ارتباطی با ریسک باید به طور مداوم انجام شود و سازمان‌ها باید برنامه‌های ارتباطی با ریسک را برای عملیات عادی و همچنین شرایط اضطراری تدوین کنند.

  • نظارت و بازبینی ریسک: تهدیدات ثابت نیستند و می‌توانند ناگهان تغییر کنند. به تبع آن ریسک‌ها نیز تغییر نموده و یا ایجاد می‌گردند، بنابراین می‌بایست ریسک‌ها به طور مداوم تحت نظارت قرار گیرند تا تغییرات در کم‌ترین زمان ممکن شناسایی شده و ریسک‌های به وجود آمده بررسی و ارزیابی گردند.

۳   دلایل انتخاب ISO27005

بر خلاف سایر استانداردهای مدیریت ریسک که رویکرد همه جانبه را اتخاذ می‌کنند، ISO 27005 دارای ماهیت انعطاف‌پذیری است و به سازمان‌ها اجازه می‌دهد تا رویکرد خود را برای ارزیابی ریسک بر اساس اهداف تجاری خاص خود انتخاب کنند.

ISO 27005 از یک ساختار ساده و تکرارپذیر پیروی می‌کند و هریک از بندهای اصلی در چهار بخش زیر سازماندهی شده است:

  • ورودی: اطلاعات لازم برای انجام یک عمل
  • اقدام: خود فعالیت
  • راهنمای پیاده‌سازی: هرگونه جزئیات اضافی
  • خروجی: اطلاعاتی که باید توسط فعالیت ایجاد شود

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

ISO 27005 همچنین مطابق با استاندارد ISO 27001 می‌باشد، این استاندارد مشخص می‌کند که هرگونه کنترل که در زمینه ISMS (سیستم مدیریت امنیت اطلاعات) اجرا می‌شود می‌بایست مبتنی بر ریسک باشد. پیاده‌سازی فرآیند مدیریت ریسک امنیت اطلاعات مطابق با استاندارد ISO 27005 می‌تواند این الزام را برآورده سازد.

تدوین: خانم مهندس سعیدی

امنیت JWT بخش سوم – ادامه حملات شناخته شده JWT

/در , /توسط

در بخش دوم دو نمونه از حملات شناخته شده JWT معرفی گردید. در این بخش سایر حملات مطرح در خصوص JWT بحث خواهد شد.

فرضیات نادرست در صحت‌سنجی رمزگذاری/امضای پشته‌ای

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

بسیاری به اشتباه تصور می‌نمایند که رمزگذاری در مقابل دستکاری و تغییر داده نیز محافظت می‌کند. منطق این فرض به این صورت می‌باشد که “اگر داده‌ها قابل خواندن نباشند، چگونه یک مهاجم می‌تواند آنها را به نفع خود تغییر دهد؟”. متأسفانه، این تصور غلط، مهاجمان و همچنین دانش آنها از الگوریتم‌های درگیر در این فرآیند را دست کم می‌گیرد.

برخی از الگوریتم‌های رمزگذاری/رمزگشایی صرف نظر از اعتبار داده‌های ورودی به آنها، خروجی را تولید می‌کنند. به عبارت دیگر، حتی اگر داده‌های رمزگذاری شده تغییر یابند، باز هم الگوریتم رمزگشایی یک رشته‌ای را به عنوان خروجی ایجاد خواهد نمود. تغییر کورکورانه داده‌ها معمولاً خروجی غیر قابل مصرف تولید می‌کند. اما برای یک فرد مهاجم، این امر ممکن است برای دسترسی به سیستم کافی باشد. به عنوان مثال، JWT زیر را در نظر بگیرید:

{
"sub": "joe",
"admin": false
}

همانطور که مشاهده می‌شود، “admin” یک مقدار boolean است. اگر مهاجمان بتوانند به گونه‌ای تغییر در داده‌های رمزگشایی شده ایجاد کنند که منجر به تغییر آن مقدار boolean شود، ممکن است منجر به انجام موفقیت آمیز حمله ارتقای دسترسی گردد. به طور دقیقتر، مهاجمی که دارای زمان کافی می‌باشند، می‌توانند به دفعات داده‌های رمزگذاری شده را دستکاری نمایند تا به نتیجه مطلوب برسند.

به همین دلیل، الگوریتم‌های JSON فقط الگوریتم‌های رمزگذاری را که شامل تأیید صحت  داده نیز می‌باشند، تعریف می‌کنند. به عبارت دیگر، تا زمانی که الگوریتم رمزگذاری یکی از الگوریتم‌های تایید شده توسط JWA  باشد، نیازی به قرار دادن یک JWT رمز شده بر روی JWT امضا شده (بصورت پشته‌ای) نمی‌باشد. اما در صورتیکه از یک الگوریتم غیر استاندارد برای رمزگذاری استفاده شود، باید اطمینان حاصل گردد که صحت داده‌ها توسط آن الگوریتم فراهم می‌شود، در غیر اینصورت باید به منظور تضمین صحت داده، از JWT امضا شده به عنوان درونی‌ترین JWT (پشته‌ای) استفاده شود. JWT‌های تو در تو[۱] همچنین ممکن است در زمان ارسال توکن‌ها به یک سیستم طرف ثالث[۲] نیز مورد استفاده قرار گیرد.

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

۱-۳  حمله جایگزینی[۳]

حملات جایگزینی یک کلاس از حملات است که در آن یک مهاجم موفق می‌شود حداقل دو توکن مختلف را دریافت نموده و سپس یک یا هر دو این توکن‌ها را برای اهدافی غیر از آنچه برای آنها در نظر گرفته شده، استفاده کند. حمله جایگزینی به دو نوع مختلف می‌باشد: ۱) گیرنده[۴] یکسان و ۲) گیرنده متفاوت.

۱-۳-۱  گیرنده متفاوت

حملات گیرنده‌های مختلف بدین صورت می‌باشد که توکن در نظر گرفته شده برای یک گیرنده به گیرنده دیگری ارسال می‌گردد. فرض کنید یک سرور Authorization وجود دارد که برای سرویس طرف ثالث، توکن صادر می‌کند. توکن مذکور، یک Jwt امضاء شده به شکل زیر است.

{
"sub": "joe",
"role": "admin"
}

این توکن می‌تواند در APIها برای انجام عملیاتی که نیاز به احراز هویت دارند مورد استفاده قرار گیرد. در این توکن، کاربر joe دارای سطح دسترسی admin می‌باشد. با این وجود، این توکن دارای مشکل می‌باشد. به عبارت دقیقتر، صادر کننده و گیرنده توکن مشخص نیست. در صورتیکه این توکن توسط گیرنده‌ دیگری (غیر از گیرنده اصلی) دریافت شده و تنها به اعتبارسنجی امضا اکتفا نماید، چه اتفاقی خواهد افتاد؟ فرض کنید کاربر joe در پایگاه داده آن سرویس هم به عنوان نام کاربری مجاز وجود داشته باشد. در این شرایط، مهاجم می‌تواند همین توکن را به آن گیرنده (سرویس) دیگر ارسال نموده و دسترسی admin را بدست آورد!

همانطور که در تصویر فوق مشاهده می‌شود، یک توکن توسط سرور Authorization به منظور احراز هویت و مجازشماری در سرور Org.1، ایجاد و به کاربر ارسال شده است. اما به دلیل اینکه گیرنده یا فرستنده در این توکن تعیین نشده است، فرد مهاجم از آن برای سوء استفاده از سرور org.2 استفاده می‌نماید.

برای جلوگیری از این حملات، اعتبارسنجی توکن باید به کلیدها یا Claimهای منحصر به فرد و به ازای هر سرویس متکی باشد. به عنوان مثال، این توکن می‌تواند شامل یک Claim با عنوان aud باشد که مخاطب مورد نظر را مشخص می‌کند. به این ترتیب، حتی اگر امضا معتبر باشد، توکن مذکور را نمی‌توان در سایر سرویس‌ها مورد استفاده قرار داد.

۱-۳-۲  گیرنده یکسان

این حمله مشابه حمله قبلی است با این تفاوت که در این مورد، گیرنده‌ یکسان می‌باشد. آنچه در این حالت تغییر می‌کند این است که مهاجم توکن را به جای سرویس مورد نظر (در همان شرکت یا ارائه دهنده خدمات) به سرویس دیگری می‌فرستد. توکن زیر را در نظر بگیرید.

{
"sub": "joe",
"perms": "write",
"aud": "cool-company/user-database",
"iss": "cool-company"
}

این توکن نسبت به توکن قبلی بسیار امن‌تر به نظر می‌رسداین توکن حاوی Claimهای صادرکننده (iss)، مخاطبان (aud) و مجوز (perms) می‌باشد. APIی که این توکن برای آن صادر شده است، همه این موارد را به همراه امضای توکن بررسی می‌نماید. به این ترتیب، حتی اگر مهاجمان موفق شوند توکنی را که با همان کلید امضا شده به دست آورند، نمی‌توانند از آن برای کار با سرویسی که برای آن در نظر گرفته نشده است، استفاده کنند.

فرض کنید شرکت cool-company سرویس‌های عمومی دیگری نیز دارد. یکی از این سرویس‌ها، سرویس cool-company/item-database می‌باشد که اخیرا به گونه‌ای تنظیم شده است که امضای توکن و Claimها بررسی نماید. با این حال، تیم مسئول به‌روزرسانی اشتباهی مرتکب شده و aud را به درستی اعتبارسنجی نمی‌نمایند. به عبارت دیگر، به جای بررسی کامل و دقیق مقدار aud، تنها به وجود عبارت cool-company اکتفا شده است. در این شرایط، توکنی که برای سرویس دیگر شرکت (cool-company/user-database) ایجاد و منتشر شده است، می‌تواند در اعتبارسنجی سرویس cool-company/item-database نیز با موفقیت مورد استفاده قرار گیرد. به عبارت دیگر، مهاجمان می‌توانند از توکن در نظر گرفته شده برای سرویس user-database به منظور احراز هویت و مجازشماری برای سرویس item-database نیز استفاده کنند.

[۱] Nested

[۲] ۳rd Party

[۳] Substitution

[۴] Repicient

تدوین: امیر حسین بابایی

امنیت JWT بخش دوم: حملات شناخته شده JWT

/در , /توسط

JSON Web Token (JWT) یک راهکار امن و فشرده به منظور انتقال اطلاعات در قالب JSON Object تعریف می‌نماید. قبل از شروع  معرفی حملات شناخته شده در JWT باید این نکته را در نظر داشت که این حملات عموما وابسته به نوع پیاده سازی JWT بوده و ارتباطی به ساختار اصلی آن ندارند. در این متن، به معرفی دو نمونه از رایجترین حملات JWTها پرداخته خواهد شد.

۱ حملات شناخته شده JWT

قبل از شروع  معرفی حملات شناخته شده در JWT باید این نکته را در نظر داشت که این حملات عموما وابسته به نوع پیاده سازی JWT بوده و ارتباطی به ساختار اصلی آن ندارند. برای درک بهتر این حملات  باید یک دید کلی راجع به JWS (json web signatures) یا همان امضاهای دیجیتال استفاده شده در این مکانیزم داشته باشیم.

هدف اصلی JWS کسب اطمینان از صحت اطلاعات ارسالی در یک فرمت Serializable و قابل درک برای سیستم‌های رایانه‌ای می‌باشد. منظور از صحت اطلاعات‌، عدم تغییر داده‌های ارسالی بعد از امضاء دیجیتال می‌باشد.

همانطور که در بخش اول (مقدمه‌ای بر JWT) ذکر گردید، یک توکن JWT دارای دو بخش اصلی Header و Payload می‌باشد که با استفاده از الگوریتم Base64 کدگذاری شده و با کاراکتر (.) به هم الحاق می‌شوند.

  • بخش Header حاوی اطلاعاتی مربوط به خود JWT از قبیل نوع امضاء و الگوریتم می‌باشد.
  • بخش Payload شامل تمامی اطلاعات مربوط به توکن از قبیل sub، iat و یا هر Claim دیگر می‌باشد.

به عنوان نمونه؛

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.XbPfbIHMI6arZ3Y922BhjWgQzWXcXNrz0ogtVhfEd2

۱-۱  حمله “alg: none”

همانطور که پیش اشاره کردیم ، JWT ها دارای دو شی JSON با اطلاعات مهم، به نام‌های Header و Payload می‌باشند. در JWTهای امضا شده، هر دو بخش header و payload می‌گردد. اما در JWTهای رمز شده، تنها بخش Payload رمز شده و بخش Header بایستی به صورت متن واضح باقی بماند.

در توکن‌های امضا شده، علیرغم اینکه بخش امضا از دستکاری بخش‌های Header و Payload محافظت به عمل می‌آورد، اما امکان بازنویسی این بخش‌ها بدون نیاز به امضا و همچنین اعمال تغییرات در محتوای آن وجود دارد.

برای مثال به نمونه JWT زیر قبل از Serialize شدن توجه کنید:

header: {
  alg: “HS256”,
  typ: “JWT”
},
payload: {
  sub: “joe”
  role: “user”
}

فرض کنید پس از افزودن بخش امضا (با استفاده یک کلید Secret) و کدگذاری Base64 بخش‌های مختلف، رشته JWT به صورت زیر خواهد بود.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJqb2UiLCJyb2xlIjoidXNlciJ9.vqf3WzGLAxHW-X7UP-co3bU_lSUdVjF2MKtLtSU1kzU

حال، از آنجایی که این یک توکن امضا شده است، می‌توانیم آن را خوانده و همچنین یک توکن مشابه با آن (با تغییرات مورد نظر در دادهای آن) ایجاد نماییم. شایان ذکر است تا زمانی که کلید امضا (Secret) را نداشته باشیم، نمی‌توانیم آن را امضا نماییم. سوال اینست که مهاجمین علیرغم نداشتن کلید Secret، چگونه می‌توانند توکن را دستکاری نمایند.

پاسخ ساده است. مهاجمان می‌توانند از توکن بدون امضا استفاده کنند!

مثال :

header: {
  alg: “none”,
  typ: “JWT”
},
payload: {
  sub: “joe”
  role: “admin”
}

که مقدار Serialize شده آن به صورت زیر خواهد بود.

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJqb2UiLCJyb2xlIjoiYWRtaW4ifQ.

در مثال فوق، بخش Signature یا امضاء توکن به صورت کامل حذف شده است و  مقدار “alg”  به “none”  و همچنین مقدار “role” از “user” به “admin”  تغییر داده شده است. حال در صورت آسیب پذیر بودنJWT، فرد مهاجم قادر است به عنوان یک مدیر (با دسترسی بیشتر) به سامانه وارد شود. در ادامه توضیح خواهیم داد که دلیل امکان پذیر بودن این حمله چه چیزی می‌تواند باشد.

بدین منظور بایستی نگاهی به چگونگی کارکرد برخی از کتابخانه های فرضی JWT بیندازیم. فرض کنید یک تابع رمزگشایی همانند ذیل را داریم.

function jwtDecode(token, secretOrPublicKey) {
  // (...)
}

بدین صورت که این تابع، یک توکن رمزگذاری شده به همراه کلید Secret را دریافت نموده و پس از تایید توکن، محتوای رمزگشایی شده آن را باز می‌گرداند. همچنین در زمانی که توکن تایید نشود، یک خطا نمایش می‌دهد. حال در صورتی که این تابع برای انتخاب الگوریتم مناسب برای تایید توکن، از پارامتر “alg” در بخش Header استفاده نماید، باعث به وجود آمدن آسیب‌پذیری ذکر شده می‌گردد. زمانی که فرد مهاجم مقدار پارامتر را با “None” جایگزین می‌کند، در واقع بدین معنی است که هیچ الگوریتمی برای صحت‌سنجی توکن وجود ندارد. در نتیجه تابع از مرحله تایید گذشته و فرد مهاجم به راحتی به عنوان “admin” وارد سامانه می‌شود.

همانطور که مشاهده می کنید ، این یک نمونه کلاسیک از حملات JWT  است که به ابهام خاصی از API یک کتابخانه خاص متکی است، و نه یک آسیب‌پذیری در خود JWT.  با این حال، این یک حمله واقعی است که در چندین اجرای مختلف در گذشته امکان پذیر بود. از اینرو، امروزه بسیاری از کتابخانه ها، مقدار “none” را برای پارامتر “alg” نامعتبر قلمداد می‌نمایند.

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

۱-۲ کلید های HMAC ضعیف

الگوریتم‌های “HMAC” به منظور تولید و اعتبارسنجی امضاها، به یک کلید مشترک متکی می‌باشند. کلیدهای مشترک مشابه کلمات عبور می‌باشند. این کلیدها بایستی دارای طول نسبتا زیادی بوده تا در مقابل حملات Brute force مقاوم باشند. از سوی دیگر، تعداد کاراکترهای خیلی زیاد کلید Secret می‌تواند سرعت پردازش‌های انجام شده را تحت تاثیر قرار دهد. از اینرو بایستی طول کلید به وصرت معقول و منطقی انتخاب شود. در واقع، طول کلید از نظر تعداد بیت حداقل بایستی هم اندازه تعداد بیت‌های خروجی تابع درهم‌سازی باشد (برای مثال ۲۵۶ بیت در الگوریتم “HS256”). به عبارت دیگر، بسیاری از کلمه‌های عبور که می‌توانند در هرجایی استفاده شوند، برای کلیدهای مشترک در JWTهای امضا شده توسط HMAC مناسب نیستند.

گزینه خوب دیگر، استفاده از الگوریتم “RS256” یا الگوریتم‌های Public-Key دیگر است که بسیار مقاوم و انعطاف پذیر می‌باشند. شایان ذکر است که این فقط یک حمله فرضی نیست. به عبارت دیگر، در صورتیکه طول کلید Secret کوتاه باشد، حملات “Brute Force” برای “HS256” به اندازه کافی ساده می‌باشد.

تدوین: امیر حسین بابایی

امنیت JWT بخش سوم – ادامه حملات شناخته شده JWT

کنترل های امنیتی CIS نسخه ۸

/در , /توسط

CIS Controls version 8

CIS Controls (که پیش تر با نام Critical Security Controls شناخته می شد) مجموعه ایی از اقدامات و کنترل های پیشنهادی برای دفاع سایبری و امن سازی می باشد که روش های خاص و قابل اجرا به منظور جلوگیری از وقوع گسترده ترین و خطرناک ترین حملات ارائه می نماید.

نسخه ۸ از CIS Controls در ۱۸ مه ۲۰۲۱ (۲۸ اردیبهشت ۱۴۰۰) ارائه گردید که تغییرات آن نسبت به نسخه قبل در شکل زیر نشان داده شده است.

 در ادامه به تشریح ۴ کنترل نخست از نسخه ۸ کنترل های CIS پرداخته شده است:

  • کنترل شماره ۱ – فهرست موجودی و کنترل دارایی های سازمانی

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

همچنین به منظور پیشگیری از نفوذ مهاجمین، لازم و ضروری است پیکربندی تجهیزات شبکه و سیستم های رایانه ای به درستی انجام گیرد. درهمین راستا بایستی سیستم مدیریت رخداد و حوادث و همچنین سامانه ثبت لاگ در سازمان فعال و به روز باشند.

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

  1. فهرست اموال دقیق، کامل و به روزی از دارایی های سازمان ایجاد و از آن نگهداری گردد.
  2. فرآیند و روالی برای بررسی و رسیدگی به دارایی های غیر مجاز در سازمان به صورت دوره ای در نظر گرفته شود. بر اساس این روال ممکن است سازمان در مواجهه با دارایی غیرمجاز اقدام به حذف آن از شبکه سازمان، جلوگیری از اتصال راه دور آن به شبکه یا قرنطینه آن نماید.
  3. از ابزارهای پویشگر فعال (Active)  برای کشف و شناسایی دارایی های متصل به شبکه سازمانی استفاده گردد. این ابزارها باید به نوعی پیکربندی شود که به صورت روزانه یا در فاصله های زمانی کمتر اجرا گردد.
  4. برای به روز رسانی لیست دارایی های سازمان، از رویدادنگاری DHCP بر روی تمامی سرورهای DHCP یا ابزارهای مدیریت آدرس IP به صورت هفتگی یا به طور مکرر استفاده نمایید.
  5. از ابزارهای پویشگر غیرفعال (Passive) برای کشف و شناسایی دارایی های متصل به شبکه سازمان استفاده نمایید.

کنترل شماره ۲ – فهرست موجودی و کنترل دارایی های نرم افزاری

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

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

راه حل این موضوع کنترل و نظارت بر روی دارایی‌های نرم افزاری و به روزرسانی نرم افزارها و اعمال وصله های امنیتی مربوط به آنها می باشد. برای رعایت این کنترل امنیتی بایستی موارد زیر پیاده سازی شوند:

  1. فهرست اموال دقیق، کامل و به روزی از دارایی های نرم افزاری سازمان ایجاد و از آن نگهداری گردد.
  2. اطمینان حاصل گردد که نرم افزارهای مورد استفاده در سازمان، مجاز و قابل پشتیبانی هستند.
  3. به دارایی های نرم افزاری غیر مجاز که می توانند خطر ساز باشند، بررسی و رسیدگی شود. اطمینان حاصل گردد که نرم افزار غیرمجاز یا از دارایی های شرکت حذف شده یا در صورت نیاز به استفاده، یک مجوز استثنای مکتوب داشته باشد.
  4. در صورت امکان از ابزارهای خودکار برای کشف و مستندسازی نرم افزارهای نصب شده در سازمان استفاده شود.
  5. فهرستی از نرم افزارهای مجاز که قابل استفاده و اجرا برای کاربران در سازمان می باشند، ایجاد گردد.
  6. فهرستی از کتابخانه ها و فایل های مجاز که قابل استفاده و اجرا برای کاربران در سازمان می باشند، ایجاد گردد.
  7. فهرستی از script های مجاز که قابل استفاده و اجرا برای کاربران در سازمان می باشند، ایجاد گردد.

کنترل شماره ۳ – حفاظت از داده های سازمان

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

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

  1. فرآیند و روالی برای مدیریت و حفاظت از داده ها در سازمان پیاده سازی و اجرا گردد.
  2. فهرست اموال دقیق، کامل و به روزی از داده های سازمان را ایجاد و از آن ها نگهداری کنید.
  3. پیکربندی کنترل دسترسی و لیست دسترسی افراد به داده ها براساس نیاز میزان نیاز هر کاربر به اطلاعات صورت پذیرد.
  4. مدیریت و حفاظت از داده ها می بایست براساس روال مدیریت داده های سازمان انجام پذیرد.
  5. استفاده از راهکار امن برای امحا داده ها و اطلاعات تا نشت اطلاعاتی صورت نگیرد.
  6. می بایست داده های حساس بر روی دستگاه کاربر نهایی رمزنگاری گردد.
  7. یک رویه و قالب طبقه بندی داده برای سازمان خود ایجاد و نگهداری کنید. سازمان ها ممکن است از برچسب هایی نظیر “حساس” ، “محرمانه” و “عمومی” برای طبقه بندی داده های خود استفاده کنند.
  8. جریان داده در سازمان را مستند نمایید. مستندات جریان داده شامل جریان های داده ارائه دهنده خدمات بوده و  می بایست مبتنی بر فرآیند مدیریت داده های سازمان باشد.
  9. کلیه اطلاعات موجود بر روی تجهیزات قابل حمل به مانند USB می بایست رمزگذاری گردد.
  10. در هنگام انتقال اطلاعات حساس می بایست کلیه اطلاعات با استفاده از پروتکل های امن به مانند SSL/TLS وSSH رمزگذاری گردد.
  11. داده ها بایستی در حالت بلا استفاده یا استراحت نیز بر روی سرورها، برنامه ها و پایگاه های داده به صورت رمزگذاری شده باشند.
  12. پردازش و ذخیره سازی داده ها را براساس حساسیت داده ها تقسیم بندی نموده و داده های حساس سازمان را بر روی دارایی های با حساسیت پایین تر سازمان پردازش و ذخیره سازی ننمایید.
  13. از راهکارهای خودکار پیشگیری از دست دادن داده ها (DLP) برای شناسایی کلیه داده های حساس ذخیره شده، پردازش شده یا منتقل شده از طرق دارایی های سازمان استفاده نمایید.
  14. لاگ های مربوط به دسترسی و تغییرات در داده های حساس سازمان را ثبت و پایش نمایید.

کنترل شماره۴ – پیکربندی امن دارایی های سازمانی و نرم افزار ها

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

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

از این قبیل مشکلات در سازمان ها و سازمان های خدمات دهنده سرویس نیز رخ می دهد برای مثال بسیاری از شرکت های ارائه دهنده خدمات ابری ممکن است در ارائه خدمات خود اشتباهاتی به مانند حساب یا گذر واژه پیش فرض، دسترسی نامحدود و سرویس هایی با پیکربندی پیش فرض در ارائه خدمات انجام دهند که مخاطراتی برای سازمان های دریافت کننده خدمات به همراه دارد.

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

  1. فرآیند و روالی برای پیکربندی امن و صحیح دارایی ها در سازمان پیاده سازی و اجرا گردد.
  2. فرآیند و روالی برای پیکربندی امن و صحیح برای زیرساخت شبکه در سازمان پیاده سازی و اجرا گردد.
  3. برای کلیه دارایی های سازمان خط مشی قفل خودکار و انقضای نشست کاربران در صورت عدم فعالیت آن ها در مدت زمانی مشخص به مانند بیش از ۱۰ الی ۱۵ دقیقه فعال گردد.
  4. فایروال را بر روی سرورها (در صورت پشتیبانی) پیاده سازی، پیکربندی و مدیریت نمایید.
  5. فایروال را بر روی تجهیزات کاربران نهایی پیاده سازی، پیکربندی و مدیریت نمایید.
  6. از پروتکل های امن شبکه به مانند HTTPS و SSH برای مدیریت از راه دور دارایی‌ها استفاده نمایید.
  7. کلیه حساب های کاربری پیش فرض مدیریت (برای مثال حذف و یا غیرفعال کردن حساب ها) گردد.
  8. سرویس ها و نرم افزارهای بلا استفاده در سازمان و شبکه را حذف و غیرفعال نمایید.
  9. سرورهای  DNSمورد اعتماد و معتبر را بر روی دارایی های سازمان پیکربندی نمایید.
  10. خط مشی قفل خودکار را بر روی تجهیزات قابل حمل کاربران نهایی (به مانند USB) اعمال نمایید.
  11. قابلیت حذف از راه دور اطلاعات را بر روی تجهیزات قابل حمل کاربران نهایی (به مانند گوشی های موبایل) را فعال نمایید تا در صورت سرقت این تجهیزات امکان امحا از راه دور اطلاعات سازمانی موجود بر روی این تجهیزات میسر باشد.
  12. فضای کاری و حساب کاربری مجزایی برای دسترسی به اطلاعات سازمانی بر روی تلفن همراه کاربران (در صورت پشتیبانی) ایجاد نمایید. برای این منظور می توان از Apple® Configuration Profile  یا  Android™ Work Profileبرای جداسازی برنامه ها و داده های سازمانی از برنامه ها و داده های شخصی استفاده کرد.

تدوین: مهندس امین اسفندیاری

در بخش های آتی موارد باقی مانده از کنترل های امنیتی CIS بررسی خواهد شد.