Qual è una buona valutazione del rischio per diversi tipi di riferimenti di file online?

Question

Qual è una buona valutazione del rischio per diversi tipi di riferimenti di file online?

#1 da (1 voti)

0

Personalmente sono un grande fan di hosting di tutto me stesso, solo per l'aspetto della privacy. Per questo motivo cerco di utilizzare file esterni il meno possibile. Tuttavia, mi chiedo se sia un rischio per la sicurezza di collegarsi a file diversi dai file JavaScript.

Il rischio di hotlinking su un file JavaScript esterno mi sembra abbastanza chiaro. Dal momento che quell'altro dominio sarà in grado di eseguire qualsiasi cosa nel browser dei client, sul tuo dominio. Quindi non riguarda i file JavaScript . Sto solo parlando di file come immagini, fogli di stile a cascata e per esempio file PDF, office o MP3.

D'altra parte, cosa succede se lo scenario è esattamente altro ? Quali rischi si possono potenzialmente affrontare quando le persone si collegano rapidamente ai file o alle immagini? Conosco alcuni metodi anti hotlinking, alcuni usano un approccio mod_rewrite, basato su un referente che può essere facilmente falsificato .

Quindi ho tre domande:

Il collegamento in hotlink a un file esterno (come descritto sopra) è pericoloso o può rappresentare un potenziale rischio per i visitatori del tuo sito Web o del tuo sito web?
Puoi rischiare da solo quando le persone si collegano con hotlink a file self-hosted, oltre a un rischio di disponibilità?
Quando la domanda numero 2 è un rischio: quali sono le migliori pratiche per proteggere i tuoi file dall'essere hotlinked da altri?

websites risk web-application risk-management risk-analysis

posta Bob Ortiz 02.06.2015 - 17:54

fonte

1 risposta

Leggi altre domande sui tag websites risk web-application risk-management risk-analysis

protezione da crittografia contro password persa Vecchio telefono come dispositivo di archiviazione di credenziali sicuro

score 1 · Accepted Answer

Is hotlinking to external file (like described above) dangerous or can it be a potential risk to your website or website visitors?

Se qualcuno dei tuoi utenti è privo di patch e stai includendo contenuti da un dominio collegato esternamente, sarebbe possibile che il dominio esterno cambi il contenuto in un immagine , file Flash o < a href="https://www.exploit-db.com/moaub11-microsoft-office-word-sprmcmajority-buffer-overflow/"> documento Word .

Can you face a risk yourself when people are hotlinking to self-hosted files, other then a availability risk?

Sì, principalmente solo un rischio di disponibilità, anche se mentre stanno facendo una richiesta interdominio al tuo server, potrebbero sfruttare vulnerabilità CSRF o vulnerabilità di iniezione e utilizzare i loro utenti finali per farlo. Questo argomento tuttavia è debole, in quanto queste vulnerabilità sono stesse vulnerabilità e possono essere attenuate in modo isolato.

When question number 2 is a risk: What are the best practices to protect your files from being hotlinked by others?

Un'opzione dovrebbe controllare referer intestazione, sebbene questo possa avere i suoi problemi. Alcuni utenti disattivano referer per aumentare la privacy e alcuni controlli dei referenti soffrono di bug logici (ad esempio http://example.com/example.org può passare il controllo di riferimento per example.org se non è codificato correttamente). Un'altra opzione potrebbe essere quella di verificare che l'utente abbia una sessione valida sul tuo sito. Questo sarebbe facilmente aggirato da un sito che richiede una pagina HTTP di dominio incrociato per impostare la sessione. Potrebbe essere necessario convalidarli tramite un controllo CAPTCHA prima di mostrare loro il contenuto del sito. Non è una buona esperienza utente.

Un'altra idea sarebbe quella di randomizzare gli URL. Pertanto image.jpg verrebbe visualizzato solo se alla stringa di query ?validationCheck=123321 è stato aggiunto. Il tuo sito web genererebbe dinamicamente il codice:

<img src="/image.jpg?validationCheck=123321" />

e il gestore per il tipo di file jpg controlla che il valore validationCheck sia corretto. Questo valore potrebbe cambiare ogni pochi minuti. Potrebbero implementare un bot per controllarlo, tuttavia sarebbe più lavoro e potrebbero anche copiare e salvare l'immagine sul proprio server (anche se sarebbe soggetta a violazione del copyright). Inoltre, questo approccio non si adatta bene alla memorizzazione nella cache.