Risolto errore di timeout nel recupero del tema rimuovendo la pre-risoluzione DNS

Generale
,
1

Continua la discussione da Recent updates seemed to stop rake task themes:update to use a proxy server:

Non riuscivo a recuperare o aggiornare alcun componente tema a causa di quell’errore di timeout, alla fine ho capito. Rimuovendo le seguenti righe che iniziano con - nel file \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

Questo codice elabora una pre-soluzione DNS quindi forza git a utilizzare gli indirizzi IP che si ottengono dalla pre-soluzione, non so perché fallisca sempre sul mio server, quindi ho rimosso la logica.

In effetti, ho una domanda sulla sua esistenza, git stesso esegue una soluzione DNS, perché abbiamo bisogno di questa logica? Questo non è distinto.

2

SSRF (come menzionato in FinalDestination::SSRFDetector) sta per Server-Side Request Forgery. Si riferisce a un meccanismo mediante il quale un attaccante inganna il tuo server affinché acceda a risorse a cui l’attaccante altrimenti non sarebbe in grado di accedere.

Ad esempio, immagina di eseguire Discourse all’interno di una rete privata con un proxy inverso per consentire l’accesso da Internet. Un attaccante potrebbe creare un argomento con un link che punta a un indirizzo IP all’interno della tua rete privata. Il sistema Onebox di Discourse potrebbe quindi recuperare tale URL e visualizzarne il contenuto in un Onebox.

Per evitare ciò, Discourse non accede a nessun URL fornito dall’utente senza prima verificare che non punti a indirizzi IP privati.

Si potrebbe sostenere che questo sia meno importante per i repository git utilizzati da temi e componenti tema, poiché questi sono specificati dagli amministratori, ma Discourse sta optando per la massima cautela.

1 Mi Piace
3

Grazie per la tua spiegazione. Ho trovato la soluzione definitiva per la mia situazione.

La mia situazione: sto usando WSL (assegnato 192.168.1.2 nella LAN virtuale) per eseguire Discourse, ed è configurato per connettersi a server remoti tramite il proxy in esecuzione su Windows (assegnato 192.168.1.1).

Quando Discourse vuole connettersi a un server remoto tramite un nome host, SSRF tenterà di utilizzare il DNS di sistema impostato in /etc/resolv.conf, tuttavia, per impostazione predefinita, l’indirizzo IP della vLAN di Windows (il mio è 192.168.1.1) è l’unico server DNS di WSL. Ma la sottorete 192.168.0.0/16 è stata inserita nella blacklist da SSRFDetector, quindi non può nemmeno ottenere una risposta DNS. (Ho solo dato un’occhiata al suo codice, quindi non so se l’opinione sopra sia corretta)

Aggiungendo 192.168.1.1 all’elemento di configurazione Allowed internal hosts, tutto continua a funzionare. Umm, forse Discourse non dovrebbe mettere in blacklist i nomi host nelle variabili d’ambiente HTTP_PROXY e HTTPS_PROXY?