نوشته‌شده در

احراز هویت – چه نوع oauth نوع اعطا باید پس از ورود به سیستم اجتماعی استفاده کنید

من یک برنامه کاربردی دارم که دارای سرویس میکروسکوپ مخصوص خود است تا علامت های دسترسی را صادر کند. برای کاربران ثبت نام با استفاده از ایمیل و رمز عبور من از grant_type = 'password' استفاده می کنم. وقتی که یک کاربر در استفاده از رسانه های اجتماعی اقدام به ثبت نام می کند چه می شود؟

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

نوشته‌شده در

احراز هویت یک برنامه کاربردی و ISO 27001

من یک برنامه صفحه جاوا اسکریپت یک صفحه دارم که با یک API .NET در حال اجرا در IIS ارتباط برقرار می کند. تأییدیه پس از بارگذاری ظاهر برنامه، با استفاده از یک نشانه OAuth از دفتر 365، به دست آمده با استفاده از ADAL.js و توسط WindowsAzureActiveDirectoryBearerAvhentication middleware از کتابخانه مایکروسافت OWIN تأیید شده است، همانند این برنامه نمونه.

دیروز کسی به من گفت که این رفتار ( داشتن یک برنامه JS به طور آشکار در اینترنت فقط با API ایمن در دسترس است) مطابق با استاندارد ISO 27001 نیست و کد منبع آن از یک مهاجم فقط در صورت موفقیت آمیز بودن با یک حساب تأیید شده در دسترس است. از آنجایی که من هرگز از ISO 27001 قبل از آن نشنیده بودم و من نیز به آن استاندارد دسترسی ندارم، شاید کسی بتواند به من بگوید این درست است یا خیر، و چه وضعیت فعلی در هنر است.

نوشته‌شده در

چرا سرور auth_code بیش از URI هدایتگر است تا در یک صفحه وب در OAuth 2.0؟

در هر استاندارد OAuth سه پایه، auth_code به عنوان پارامتر URL عمل می کند، در حالی که URL redirect_uri در هنگام ثبت نام مشتری مشخص شده است. من حدس می زنم این یک پاسخ HTTP 302 است که توسط سرور OAuth فرستاده می شود که مرورگر را مرور می کند. من تعجب می کنم که چرا auth_code در بدن یک وب سایت تولید شده توسط سرور OAuth خدمت نمی کند؛ بنابراین HTTP 200 پاسخ به طور منظم ارسال می شود. آیا به جای ارائه خدمت در داخل صفحه وب، یک پیغام امنیتی مرتبط با خدمت auth_code بیش از redirect_uri مرتبط است؟

نوشته‌شده در

اجتناب از حمله نیروهای شدید به سرور مجوز oAuth

من در حال حاضر به چارچوب مجوز OAuth 2 نگاه می کنم. دیروز شروع به تعجب کردم که چگونه برای جلوگیری از حمله نیروهای بیرحمانه در جریان اعتبار مجوز کد (https://tools.ietf.org/html/rfc6749#section-4.1). برای روشن شدن، جریان به صورت زیر عمل می کند:

  1. مرورگر درخواست هایی را برای یک منبع محافظت شده در یک مشتری oAuth 2 ( client.example.com ) می فرستد.

  2. مرورگر به نقطه پایانی مجوز هدایت می شود سرور مجوز:

    GET / authorize؟ response_type = کد & client_id = s6BhdRkqt3 & state = xyz
        & redirect_uri = https٪ 3A٪ 2F٪ 2Fclient٪ 2Eexample٪ 2Ecom٪ 2Fcb

با حالت خاصی از رشته تصادفی تولید شده توسط مشتری oAuth 2

  1. ورود به سیستم مرورگر در سرور مجوز

  2. هنگامی که به درستی وارد سیستم شوید، مرورگر با پارامترهای پرس و جو redirect-uri با برخی از پارامترهای پرس و جو

    https://client.example.com/cb؟code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

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

  1. مشتری تایید می کند که آیا پارامتر حالت متعلق به جلسه عامل کاربر (برای جلوگیری از XSRF) و درخواست توالی دسترسی از سرور مجوز با استفاده از کد پارامتر پرس و پایه احراز هویت با اعتبار مشتری:

    POST / token HTTP / 1.1
    میزبان: server.example.com
    مجوز: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    Content-Type : application / x-www-form-urlencoded [19659012] grant_type = authorization_code & code = SplxlOBeZQQYbYS6WxSbIA و redirect_uri = https٪ 3A٪ 2F٪ 2Fclient٪ 2Eexample٪ 2Ecom٪ 2Fcb

ممکن است یک مهاجم یک بار دیگر تکرار مراحل 2 و 4 را انجام دهد، بدون اینکه وارد سرور مجاز شوید :

  1. برو به یک منبع محدود در client.example.com .
  2. تجزیه پارامتر درخواست در مسیر هدایت (و ذخیره کوکی / شناسه جلسه) [19659018] با رفتن به https://client.example.com/cb؟code=value1&state=xyz (با کوکی / شناسه جلسه دریافت شده در 1) سعی کنید یک نشانه برای value1 دریافت کنید.

دوباره این کار را انجام دهید و دوباره برای کد = ارزش 2 ، کد = ارزش 3 ، …

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

با این حال، احتمالا یک پنجره کوچک برای مهاجم برای انجام atta ck، از آنجا که کد فقط در سرور بین مراحل 4 و 5 در جریان معتبر است (به جز اگر مشتری در جایی بین 4 و 5 سقوط می کند.)

دیگر

  • دارای یک کد بزرگ تولید شده توسط سرور مجوز [19659018] کدهای موجود فقط برای یک مدت زمان محدود

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

نوشته‌شده در

چرا سرور مشتری نمی تواند مستقیما به یک ارائه کننده هویت مانند فیس بوک در oauth 2.0 صحبت کند

OAuth 2.0 برای احراز هویت توسط Google مورد استفاده قرار می گیرد، زیرا سرور و سرویس گیرنده هر دو به گوگل اعتماد دارند، اما نه یکدیگر. همانطور که می دانم، کد مجوز به عنوان یک پارامتر URL به سرور (در سمت سمت سرور) منتقل می شود. برای جلوگیری از مسائل امنیتی مانند معاون اشتباه، کد مجوز یک بار استفاده است و سرور می تواند از کد مجوز برای به دست آوردن یک نشانه دسترسی و نوشتن نشانه استفاده کند. سوال من این است که چرا این فرایند ساده نیست اگر گوگل (یک موجود اعتماد) مستقیما رکوردهای دسترسی به سرور (و نه از طریق مشتری) را ارسال کند؟ این نیاز به یک کد مجوز را از بین می برد. گوگل می تواند مطمئن باشد که این رمز عبور را به مکان مناسب ارسال می کند زیرا مشتری قبلا redirect_uri را با Google ثبت کرده است. به نظر می رسد یک الگوی کلی است که این پروتکل ها ارائه دهنده هویت تنها از طریق مشتری به سرور می فرستد.