حتى قبل أن بدأت في فهم علم أمن المعلومات المعقد ، بدا لي أن مصادقة 2FA هي وسيلة مضمونة لحماية حسابك ولا يمكن لـ "هؤلاء المتسللين لديك" ، على سبيل المثال ، سحب عملتي الداخلية لشراء ملابس لشخصيات على حساب اللعبة. ولكن بمرور الوقت ، ثبت تجريبياً أن نظام المصادقة ثنائي العوامل يمكن أن يحتوي على عدد كبير من الثغرات الأمنية.
بمعنى بسيط ، المصادقة ثنائية العوامل هي تأكيد للعمل عن طريق إدخال الكود الذي تم إنشاؤه لزيادة الأمن ورمي العصي في عجلات المتسللين الشرطيين أثناء الحركة أو قبل أن تبدأ.
نظام تأكيد الشفرة واسع الانتشار ، ويستخدم في كل مكان في مواقع مختلفة ويمكن توصيله لكل من عمليات تسجيل الدخول الأساسية والثانوية. لكن التطبيق لا يقتصر على ذلك - يعلق المطورون تأكيدًا على وظيفة استرداد كلمة المرور ، وتأكيد التسجيل / الاشتراك ، وتأكيد إضافي للمعاملات المالية ، وتغيير كلمة المرور ، وتغيير البيانات الشخصية. أيضًا ، من وقت لآخر ، يتم استخدام 2FA كجدار بعد تسجيل الخروج للتوقيت ، وليس كلمة مرور أو وسيلة أخرى للتأكيد.
في هذه المقالة ، جمعت طرقًا لاختبار 2FA بحثًا عن نقاط الضعف واستغلالها ، فضلاً عن الخيارات الممكنة للتحايل على الحماية الحالية ضد أنواع معينة من الهجمات. دعونا نلقي نظرة على قائمة اختبارات الضعف التي تنطبق على 2FA:
1. عدم وجود حد للسعر
تُستخدم خوارزمية حد السعر لاختبار ما إذا كانت جلسة المستخدم (أو عنوان IP) يمكن أن تكون محدودة في المحاولات أو السرعة ، وتحت أي ظروف يحدث هذا. إذا كان المستخدم قد أتم الكثير من الطلبات في غضون فترة زمنية معينة ، فيمكن أن يستجيب تطبيق الويب برمز 429 (العديد من الطلبات) أو يطبق حد السعر دون إظهار الأخطاء. يعني عدم وجود حد للسعر أنه خلال التعداد العادي لا توجد قيود على عدد المحاولات و / أو السرعة - يُسمح بالتكرار على الرموز أي عدد من المرات (في أي سرعة) خلال فترة صلاحية الجلسة / الرمز المميز.
غالبًا ما يتعين عليك التعامل مع الحد الأقصى "بلا ضوضاء" ، إذا رأيت أنه لا توجد أخطاء وأن كود / نص HTTP لا يتغير في الطلبات اللاحقة ، يجب أن تكون سعيدًا في وقت مبكر جدًا ، وتحتاج أولاً إلى التحقق من النتيجة النهائية للهجوم باستخدام رمز صالح.
2. يوجد حد للسعر ، ولكن يمكن التحايل عليه
الحالات التي كان علي أن أقابلها من قبل:
1) الحد من سرعة التدفقات مع عدم وجود انسداد بعد الوصول إلى سرعة معينة
في كثير من الأحيان ، يحاول باحثو الأمن التقاط الكود باستخدام 5 أو أكثر من الخيوط لجعل الهجوم أسرع (في Burp Intruder ، العدد الافتراضي للخيوط هو 5 دون تأخير). لكن في بعض الأحيان ، لا يمكن لنظام الأمان من التكسير أو تحميل موازن التحميل العادي الاستجابة لهذا العامل الوحيد. إذا كنت تحاول إجبار القوة باستخدام 5 سلاسل ، فيجب عليك تقليل العدد إلى 1 ثم إلى 1 مع تأخير لمدة ثانية واحدة. في وقت سابق ، كنت محظوظًا بمراقبة مثل هذا السلوك ، وقد ساعد الاختيار الناجح للرمز ، مما أدى إلى الاستيلاء على الحساب ، وذلك بمساعدة مثل هذه المعالجات. إذا لم يكن للشفرة 2FA تاريخ انتهاء محدد ، عندها لدينا الكثير من الوقت للفرز. في حالة وجود فترة الصلاحية ، يتم تقليل نجاح الهجوم ، لكن خطر التعرض المحتمل لا يزال موجودًا ، حيث لا تزال هناك فرصة للدخول إلى الشفرة المطلوبة.
2) رمز OTP ولدت لا يتغير
لا ينطبق هذا على الرموز المتغيرة باستمرار كما هو الحال في Google Authenticator ، ولكن فقط الرموز الثابتة التي تأتي في رسائل نصية قصيرة أو بريد إلكتروني أو شخصيًا عبر برنامج messenger.
جوهر هذا الالتفافية هو أن نفس رمز OTP يتم إرساله باستمرار أو لبعض الوقت ، على سبيل المثال ، 5 دقائق ، وهو صالح خلال كل هذا الوقت. يجدر أيضًا التأكد من عدم وجود حد صامت للمعدل.
مثال على ذلك:
hackerone.com/reports/420163لنفترض أن التطبيق ينشئ رمزًا عشوائيًا من 001 إلى 999 ويرسله إلى الهاتف ، في غضون 10 دقائق عند تمكين وظيفة "الإرسال مرة أخرى" ، نحصل على نفس الرمز. لكن الحد الأقصى للسعر مرتبط بالطلب ، مما يحد من عدد المحاولات لكل رمز طلب. يمكننا دائمًا طلب رمز جديد ، وإنشاء رمز طلب جديد ، وتطبيقه على طلب لاحق (باستخدام grep-match في مجموعة تجشؤ أو باستخدام البرنامج النصي الخاص بنا) وتنفيذ bruteforce لمجموعة من الأرقام من 001 إلى 999. وبالتالي ، استخدم باستمرار رمز طلب جديد سنختار الرمز الصحيح بنجاح ، لأنه لا يتغير وهو ثابت لفترة زمنية معينة. حدود هذا الهجوم هي عدد طويل أو خلط الحروف مع الأرقام كرمز تأكيد.
لا ينبغي تشجيع هذا الموقف ، يجب أن تحاول فرز جزء على الأقل من قائمتنا ، لأن هناك احتمال أن تكون الشفرة التي تم إنشاؤها في هذا الجزء من القائمة ، حيث يتم إنشاؤها بشكل عشوائي. عند المحاولة ، تحتاج إلى الاعتماد على عشوائي ، ولكن لا تزال هناك فرصة للانضمام إلى المجموعة الصحيحة ، مما يثبت وجود ثغرة تحتاج بالتأكيد إلى إصلاح.
3) إعادة تعيين معدل الحد عند تحديث الرمز.
في طلب التحقق من الكود ، يوجد حد السعر ، ولكن بعد تنشيط وظيفة إعادة إرسال الرمز ، تتم إعادة تعيينه ويسمح لك بمتابعة كود القوة الغاشمة.
أمثلة من التقارير:
https://hackerone.com/reports/149598 ، - theory؛
hackerone.com/reports/205000 ، استغلال عملي يستند إلى تقرير سابق.
4) تجاوز الحد الأقصى للسعر عن طريق تغيير عنوان IP
تعتمد العديد من الأقفال على تقييد تلقي الطلبات من IP ، والتي وصلت إلى عتبة عدد معين من المحاولات عند تنفيذ الطلب. إذا تم تغيير عنوان IP ، فهناك فرصة للتحايل على هذا القيد. للتحقق من هذه الطريقة ، قم ببساطة بتغيير IP الخاص بك باستخدام خادم Proxy / VPN ومعرفة ما إذا كان الحظر يعتمد على IP.
طرق تغيير IP:
- يمكن استخدام الوكلاء في الهجوم باستخدام الوظيفة الإضافية IP Rotator لـ Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension . في رأيي ، هذا هو الخيار الأفضل ، لأنه يوفر لنا ~ محاولات القوة الغاشمة غير المحدودة وعناوين IP التي تسمح لك بتنفيذ هجوم القوة الغاشمة دون أخطاء 42x وانقطاع.
- قد يكون الخيار الجيد هو برنامج نصي بيثون يحتوي على وحدة طلبات الوكيل ، ولكن عليك أولاً الحصول على عدد كبير من الوكلاء الصالحين في مكان ما.
نظرًا لأن أداة تدوير IP ترسل طلبات باستخدام عناوين IP AWS ، فسيتم حظر جميع الطلبات إذا كان تطبيق الويب وراء جدار الحماية CloudFlare.
في هذه الحالة ، تحتاج إلى اكتشاف IP الخاص بخادم الويب الأصلي أو البحث عن طريقة لا تخص عناوين IP AWS.
5) يتضمن الموقع دعمًا لـ X-Forwarded-For
يمكن استخدام رأس X-Forwarded-For المدمج لتغيير IP. إذا كان التطبيق يحتوي على معالجة مضمّنة لهذا الرأس ، فما عليك سوى إرسال X-Forwarded-For: desire_IP لاستبدال IP لتجاوز التقييد دون استخدام بروكسيات إضافية. في كل مرة يتم إرسال طلب من X-Forwarded-For ، سيرى خادم الويب أن عنوان IP الخاص بنا يطابق القيمة التي يتم إرسالها عبر الرأس.
المواد المتعلقة بهذا الموضوع:
hackerone.com/reports/225897medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf341573. تجاوز 2fa باستبدال جزء من الطلب من جلسة حساب آخر
إذا تم إرسال معلمة ذات قيمة محددة للتحقق من الرمز في الطلب ، فحاول إرسال القيمة من الطلب إلى حساب آخر.
على سبيل المثال ، عند إرسال رمز OTP ، يتم التحقق من معرف النموذج أو معرف المستخدم أو ملف تعريف الارتباط المقترن بإرسال الرمز. إذا قمنا بتطبيق البيانات من معلمات الحساب الذي تريد تجاوز التحقق من الرمز (الحساب 1) على جلسة حساب مختلف تمامًا (الحساب 2) ، فسنحصل على الكود وأدخله في الحساب الثاني ، ثم يمكننا تجاوز الحماية على الحساب الأول. بعد إعادة تحميل الصفحة يجب أن تختفي 2FA.
4. تجاوز 2FA باستخدام "وظيفة تحفيظ"
تحتوي العديد من المواقع التي تدعم ترخيص 2FA على وظيفة "تذكرني". يكون ذلك مفيدًا عندما لا يرغب المستخدم في إدخال رمز 2FA عند تسجيلات الدخول اللاحقة. من المهم تحديد الطريقة التي يتم بها "تذكر 2FA". يمكن أن يكون هذا ملف تعريف ارتباط أو قيمة في الجلسة / التخزين المحلي أو مجرد إرفاق 2FA بعنوان IP.
1) إذا تم إرفاق 2FA باستخدام ملف تعريف ارتباط ، يجب أن تكون قيمة ملف تعريف الارتباط غير قابلة للتخمين
أي إذا كان ملف تعريف الارتباط يتكون من مجموعة من الأرقام تزداد لكل حساب ، فمن الممكن تمامًا تطبيق هجوم القوة الغاشمة على قيمة ملف تعريف الارتباط وتجاوز 2FA. يجب على المطورين توفير ملف تعريف الارتباط (إلى جانب ملف تعريف الارتباط للجلسة الرئيسية ورمز CSRF) مع سمة HttpOnly بحيث لا يمكن سرقتها باستخدام XSS واستخدامها لتجاوز 2FA.
2) إذا تم إرفاق 2FA بعنوان IP ، فيمكنك محاولة استبداله
لتحديد هذه الطريقة ، قم بتسجيل الدخول إلى حسابك باستخدام وظيفة تخزين 2FA ، ثم انتقل إلى متصفح آخر أو وضع التصفح المتخفي للمستعرض الحالي وحاول تسجيل الدخول مرة أخرى. إذا لم يتم طلب 2FA على الإطلاق ، فقد تم إرفاق 2FA إلى عنوان IP.
لاستبدال عنوان IP ، يمكنك استخدام رأس X-Forwarded-For في مرحلة إدخال تسجيل الدخول وكلمة المرور ، إذا كان تطبيق الويب يدعمه.
باستخدام هذا العنوان ، يمكنك أيضًا تجاوز وظيفة القائمة البيضاء لعنوان IP ، إذا كان أحدها موجودًا في إعدادات الحساب. يمكن استخدامه بالاقتران مع 2FA كحماية إضافية للحساب أو قد لا يتم طلب 2FA حتى إذا كان عنوان IP يطابق القائمة البيضاء (بموافقة المستخدم). وبالتالي ، حتى بدون إرفاق 2FA إلى عنوان IP ، في بعض الحالات ، يمكن التحايل على 2FA من خلال التحايل على أساليب الحماية المرتبطة.
بشكل عام ، إن ربط 2FA بعنوان IP ليس طريقة آمنة تمامًا للحماية ، لأنه عندما تكون موجودًا على نفس الشبكة ، عند الاتصال بموفر خدمة VPN / الإنترنت نفسه بعنوان IP ثابت ، يمكن تجاوز 2FA.
الطريقة الأكثر أمانًا لحماية نفسك هي عدم تذكر 2FA على الإطلاق على حساب سهولة الاستخدام.
5. غير صحيح علة التحكم في الوصول على صفحة إدخال 2FA
في بعض الأحيان يتم تقديم صفحة حوار لإدخال 2FA كعنوان URL مع معلمات. الوصول إلى مثل هذه الصفحة مع معلمات في URL مع ملفات تعريف الارتباط التي لا تتطابق مع تلك المستخدمة لإنشاء الصفحة أو بدون ملفات تعريف الارتباط على الإطلاق ليست آمنة. ولكن إذا قرر المطورون قبول المخاطر ، فأنت بحاجة إلى استعراض العديد من النقاط المهمة:
- هل تنتهي صلاحية الرابط لإدخال 2FA؟
- ما إذا كان يتم فهرسة الارتباط في محركات البحث.
إذا كان للعمر عمر طويل و / أو احتوت محركات البحث على روابط عمل لإدخال / روابط 2FA يمكن فهرستها (لا توجد قواعد في علامات ملف robots.txt / meta) ، فهناك إمكانية استخدام آلية تجاوز 2FA على صفحة إدخال 2FA ، تجاوز بالكامل تسجيل الدخول وكلمة المرور ، والوصول إلى حساب شخص آخر.
6. عدم كفاية الرقابة على البيانات الشخصية على الصفحة 2FA
عند إرسال رمز OTP على الصفحة ، يتم استخدام الرقابة لحماية البيانات الشخصية مثل البريد الإلكتروني ورقم الهاتف واللقب ، إلخ. ولكن يمكن الكشف عن هذه البيانات بالكامل في نقاط النهاية لواجهة برمجة التطبيقات والطلبات الأخرى التي لدينا حقوق كافية لها في مرحلة 2FA. إذا كانت هذه البيانات في البداية غير معروفة ، على سبيل المثال ، أدخلنا فقط تسجيل الدخول دون معرفة رقم الهاتف ، ثم يعتبر هذا هو ضعف الكشف عن المعلومات. يمكن استخدام معرفة رقم الهاتف / البريد الإلكتروني لهجمات لاحقة والقوة الغاشمة.
مثال على استغلال ثغرة أمنية باستخدام بيانات الاعتماد Stuffing. دعنا نقول أن هناك قاعدة بيانات في المجال العام مع تسجيلات وكلمات مرور للموقع أ. يمكن للمهاجمين استخدام البيانات من قاعدة البيانات هذه على الموقع ب:
- أولاً ، يتم التحقق مما إذا كان المستخدم موجودًا في قاعدة بيانات الموقع B باستخدام خطأ "حساب التعداد" في تسجيل / استرداد كلمة المرور. عادةً ، لا تعتبر العديد من المواقع هذه نقطة ضعف وتتحمل المخاطر. تكمن "الضعف" في وجود خطأ حول حقيقة تسجيل المستخدم على الموقع. من الناحية المثالية ، تكون الرسالة الآمنة على صفحة استعادة كلمة المرور كما يلي:
- بعد الحصول على قاعدة بيانات المستخدمين الحاليين ، يطبق المهاجمون كلمات المرور على هذه الحسابات.
- إذا واجهوا 2FA ، ثم تتعثر. لكن في حالة عدم كفاية الرقابة على بيانات المستخدم ، فيمكنهم استكمال قاعدة البيانات الخاصة بهم ببياناتهم الشخصية (إذا لم تكن موجودة في قاعدة البيانات الأصلية).
7. تجاهل 2FA في ظروف معينة
عند تنفيذ بعض الإجراءات التي تؤدي إلى تسجيل الدخول التلقائي إلى حسابك ، قد لا يتم طلب 2FA.
1) تجاهل 2FA عند استعادة كلمة المرور
تقوم العديد من الخدمات بتسجيل الدخول تلقائيًا إلى حسابك بعد الانتهاء من إجراءات استرداد كلمة المرور. نظرًا لأن الوصول إلى الحساب يتم توفيره على الفور ، عند تسجيل الدخول إلى حساب 2FA الخاص بك ، يمكن تجاهله وتجاهله تمامًا.
تأثير تقرير متطابق مشابه أرسلته مؤخرًا:
إذا تمكن المهاجم من الوصول إلى البريد الإلكتروني للضحية (يمكنه اختراق الحساب باستخدام التصيد الاحتيجي ، وهجمات القوة الغاشمة ، وحشو بيانات الاعتماد ، وما إلى ذلك) ، فيمكنه تجاوز 2FA ، على الرغم من أنه في هذه الحالة ، يجب على 2FA حماية الحساب. في الوقت الحالي ، بالنسبة إلى 2FA ، هناك تحقق من رمز Google Authenticator أو رمز النسخ الاحتياطي ، ولكن ليس الرمز من البريد الإلكتروني ، لذلك فإن Bypass هذا منطقي.
2) تجاهل 2FA عند تسجيل الدخول عبر شبكة اجتماعية
يمكنك إرفاق شبكة اجتماعية بحساب المستخدم الخاص بك لتسجيل الدخول بسرعة إلى حسابك وفي الوقت نفسه إعداد 2FA. عند تسجيل الدخول إلى حسابك عبر الشبكات الاجتماعية ، يمكن تجاهل 2FA. إذا تم اختراق البريد الإلكتروني للضحية ، فسيكون من الممكن استرداد كلمة المرور لحساب الشبكة الاجتماعية (إذا سمحت بذلك) ودخول الخدمة دون إدخال 2FA.
تأثير أحد التقارير:
- مجموعة من الثغرات الأمنية الأخرى ، مثل أخطاء تكوين OAuth المرسلة مسبقًا # 577468 ، لالتقاط الحساب بالكامل ، وكسر 2FA.
- إذا قام أحد المهاجمين باختراق البريد الإلكتروني للمستخدم ، فيمكنه محاولة استعادة الوصول إلى حساب الشبكة الاجتماعية وتسجيل الدخول إلى الحساب دون التحقق الإضافي.
- إذا قام أحد المهاجمين باختراق حساب الضحية مرة واحدة ، فيمكنه ربط شبكة اجتماعية بالحساب وتسجيل الدخول إلى الحساب في المستقبل ، متجاهلاً تمامًا 2FA وإدخال تسجيل الدخول / كلمة المرور.
3) تجاهل 2FA في إصدار أقدم من التطبيق
غالبًا ما يضيف المطورون إصدارات مرحلية من تطبيق ويب إلى المجالات / المجالات الفرعية لاختبار وظائف معينة. ومن المثير للاهتمام ، إذا قمت بتسجيل الدخول باستخدام اسم المستخدم وكلمة المرور الخاصة بك ، فلن يتم طلب 2FA. ربما يستخدم المطورون إصدارًا أقدم من التطبيق ، حيث لا توجد حماية لـ 2FA ، أو 2FA نفسه معطل أو تم تعطيله عن قصد للاختبار.
أيضًا ، يمكنك التحقق من نقاط الضعف الأخرى في نفس الوقت ، - يمكن أن يؤدي تسجيل مستخدم جديد على خادم مرحلي موجود في قاعدة بيانات إصدار الإنتاج إلى تزويدنا ببيانات شخصية من الإنتاج ؛ عدم وجود حد للسعر في وظائف مهمة ، على سبيل المثال ، استعادة كلمة المرور. مثال على مشكلة عدم الحصانة الأخيرة ، هو وجود خطأ في Facebook بمبلغ 15000 دولار ، مما سمح باختراق حساب باستخدام رمز استعادة كلمة مرور bruteforce على العنوان beta.facebook.com
www.freecodecamp.org/news/responsible-disclosure-how-i-could-have-hack-all- facebook-accounts-f47c0252ae4d .
4) تجاهل 2FA في حالة وجود منصة مشتركة
قد تختلف تطبيقات 2FA في إصدار الهاتف المحمول أو سطح المكتب عن إصدار الويب للتطبيق. قد تكون 2FA أضعف مما كانت عليه في إصدار الويب أو غائبة تمامًا.
7. عند تعطيل 2FA ، لا يُطلب الرمز الحالي.
إذا ، عند تعطيل 2FA ، لم يتم طلب تأكيد إضافي ، مثل الرمز الحالي من تطبيق مصادقة google ، الرمز من البريد الإلكتروني / الهاتف ، ثم في هذه الحالة هناك بعض المخاطر. مع طلب نظيف ، هناك فرصة لهجوم CSRF. إذا تم العثور على ناقل تجاوز لحماية CSRF (إن وجد) ، فيمكن عندئذٍ تعطيل 2FA. يمكن أيضًا استخدام مشكلة عدم حصانة clickjacking - بعد بضع نقرات من مستخدم غير ملتمس ، سيتم قطع اتصال 2FA. سيضيف التحقق من صحة الرمز السابق حماية إضافية 2FA ، بالنظر إلى هجمات CSRF / XSS / Clickjacking المحتملة ، بالإضافة إلى أخطاء CORS الخاطئة.
سأعطيك مثالًا على hackerone.com ، - عندما تقوم بإيقاف تشغيل 2FA في نموذج واحد ، ستحتاج إلى إدخال متغيرين في نفس الوقت ، - الرمز الحالي مع تطبيق مصادقة google وكلمة المرور. هذا هو أفضل وأوصى الحماية.
8. تظل الجلسات التي تم إنشاؤها سابقًا صالحة بعد تفعيل 2FA
عند تمكين 2FA ، من المستحسن أن يتم عرض الجلسات المتوازية في نفس الحساب وعرض مربع حوار إدخال 2FA ، مع تغيير كلمة المرور. إذا تم اختراق الحساب وكان رد فعل الضحية الأول هو تضمين 2FA ، فسيتم تعطيل جلسة المهاجم وستتطلب تسجيل الدخول وكلمة المرور التالية 2FA. الكل في الكل ، هذه هي أفضل ممارسة يجب اتباعها. ألاحظ غالبًا كيف تضيف عمليات تبادل العملة المشفرة حماية مماثلة. مثال تقرير HackerOne ، -
https://hackerone.com/reports/534450.
9. عدم وجود حد للسعر في حسابك
2FA يمكن تنفيذها في وظائف مختلفة لحساب المستخدم الشخصي لمزيد من الأمن. يمكن أن يكون هذا تغييرًا في عنوان البريد الإلكتروني وكلمة المرور وتأكيد تغيير الرمز للمعاملات المالية ، إلخ. قد يختلف وجود حد سعر الفائدة في حسابك عن وجود حد السعر الأقصى في 2FA عند إدخال حسابك. غالبًا ما صادفت حالات مماثلة عندما كان من الممكن تحديد رمز 2FA بحرية في حسابي ، بينما تم تعيين حد "صارم" للسعر عند المدخل.
إذا كان المطورون قد أضافوا في البداية حماية ضد تغييرات البيانات غير المصرح بها ، فيجب دعم هذه الحماية وتصحيحها بواسطة جميع الطرق الجانبية الممكنة. إذا تم العثور على تجاوز ، فسيتم اعتبار ذلك مشكلة عدم حصانة تجاوز ميزة أمان تم تنفيذها بواسطة المطورين.
10. إصدار API
إذا رأيت شيئًا مثل / v * / في طلب تطبيق الويب ، حيث * هو رقم ، فمن المحتمل أنه يمكنك التبديل إلى إصدار قديم من API. API . , API production/staging .
, /endpoint/api/v4/login , . 2FA , /endpoint/api/v4/2fa_check, . API 2FA, , , . /endpoint/api/v3/login /endpoint/v3/login_successful?code=RANDOM, 2fa_check , API, 2FA .
, — /endpoint/api/v4/2fa_check rate-limit, /endpoint/api/v3/2fa_check - .
11. Improper Access Control
2FA . ( ). CORS /XSS , «» , 2FA, .
, 2 , , , 2FA web , — . , 2FA ( Salesforce, Valve) 2FA. 2FA , 2FA bypass-.
, , bug bounty , , . Stay safe!