تم حل خطأ مهلة جلب السمة عن طريق إزالة الحل المسبق لنظام أسماء النطاقات

عام
,
1

متابعة النقاش من التحديثات الأخيرة توقفت عن مهمة rake لتحديث الثيمات لاستخدام خادم وكيل:

لم أتمكن من جلب أو تحديث أي مكون ثيم بسبب خطأ المهلة هذا، وأخيراً اكتشفت الحل. إزالة الأسطر التالية التي تبدأ بـ - في الملف \u003cDiscourse\u003e/lib/theme_store/git_importer.rb:

  def clone_http!
    uri = redirected_uri

    raise_import_error! if %w[http https].exclude?(@uri.scheme)

-    addresses = FinalDestination::SSRFDetector.lookup_and_filter_ips(uri.host)

-    raise_import_error! if addresses.empty?

    env = { "GIT_TERMINAL_PROMPT" => "0" }

    args =
      clone_args(
        uri.to_s,
-        "http.followRedirects" => "false",
-        "http.curloptResolve" => "#{uri.host}:#{uri.port}:#{addresses.join(\",\")}",
      )

    begin
      Discourse::Utils.execute_command(env, *args, timeout: COMMAND_TIMEOUT_SECONDS)
    rescue RuntimeError
      raise_import_error!
    end
  end

تقوم هذه الشيفرة بمعالجة حل DNS مسبق ثم تجبر git على استخدام عناوين IP التي تم الحصول عليها من الحل المسبق، لا أعرف لماذا فشلت دائماً على الخادم الخاص بي، لذلك قمت بإزالة المنطق.

في الواقع، لدي سؤال حول وجوده، git نفسه سيقوم بحل DNS، لماذا نحتاج إلى هذا المنطق؟ هذا ليس واضحاً.

2

SSRF (كما هو مذكور في FinalDestination::SSRFDetector) يرمز إلى تزوير الطلبات من جانب الخادم (Server-Side Request Forgery). يشير هذا إلى آلية يقوم المهاجم من خلالها بخداع الخادم الخاص بك للوصول إلى موارد قد لا يتمكن المهاجم من الوصول إليها بخلاف ذلك.

على سبيل المثال، تخيل أنك كنت تشغل Discourse داخل شبكة خاصة مع وكيل عكسي (reverse proxy) للسماح بالوصول من الإنترنت. يمكن للمهاجم إنشاء موضوع برابط يشير إلى عنوان IP داخل شبكتك الخاصة. قد يقوم نظام Onebox الخاص بـ Discourse بعد ذلك باسترداد عنوان URL هذا وعرض محتوياته في Onebox.

لمنع حدوث ذلك، لا يصل Discourse إلى أي عناوين URL يوفرها المستخدمون دون التحقق أولاً من أنها لا تشير إلى عناوين IP خاصة.

قد يكون هذا أقل أهمية بالنسبة لمستودعات git المستخدمة بواسطة السمات ومكونات السمات، نظرًا لأن المسؤولين هم من يحددونها، لكن Discourse يفضل توخي الحذر هنا.

إعجاب واحد (1)
3

شكرًا لك على شرحك. لقد وجدت الحل الأمثل لوضعي.

وضعي: أنا أستخدم WSL (مُعيّن له 192.168.1.2 في الشبكة المحلية الافتراضية) لتشغيل Discourse، وهو مُعدّ للاتصال بالخوادم البعيدة عبر الوكيل (proxy) الذي يعمل على نظام التشغيل Windows (مُعيّن له 192.168.1.1).

عندما يريد Discourse الاتصال بخادم بعيد باستخدام اسم مضيف (hostname)، سيحاول SSRF استخدام نظام أسماء النطاقات (DNS) المُعدّ في /etc/resolv.conf، ومع ذلك، بشكل افتراضي، يكون عنوان IP لشبكة vLAN الخاصة بنظام Windows (وهو 192.168.1.1 في حالتي) هو خادم DNS الوحيد لـ WSL. ولكن النطاق الفرعي 192.168.0.0/16 مُدرج في القائمة السوداء بواسطة SSRFDetector، ولا يمكنه حتى الحصول على إجابة DNS. (لقد تصفحت الكود للتو، لذا لا أعرف ما إذا كان الرأي أعلاه صحيحًا).

بإضافة 192.168.1.1 إلى عنصر الإعداد Allowed internal hosts، استمر كل شيء في العمل. همم، ربما لا ينبغي لـ Discourse إدراج أسماء المضيفين في متغيرات البيئة HTTP_PROXY و HTTPS_PROXY؟