نوشته‌ها

امنیت 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