Download di un file da un server con un segreto: in testo o binario?

Non c'è davvero una differenza.

Se utilizzi la corretta crittografia TLS, nessuno dei due può essere letto da un utente nel mezzo e se il server autentica correttamente le richieste, nessuno a cui non è consentito potrà scaricare il file.

Se non utilizzi TLS appropriato o non autentichi correttamente gli utenti, un utente malintenzionato potrebbe leggere il file in entrambi i casi.

Sicuramente non dovresti usare lo zipping non protetto da password come misura di sicurezza.

No ,

Se viene specificato il tipo di file, non vi è alcuna sicurezza aggiunta. Ad esempio, la decompressione di un file è così semplice che non aggiunge alcuna sicurezza.

Se chiedi se è più sicuro condividere un segreto tramite un file con un tipo sconosciuto, questo è solo sicurezza dall'oscurità . La sicurezza sicura dall'oscurità scoraggia alcune persone ma non è ancora sicura.

Il formato del file è irrilevante per la sicurezza del trasporto dei dati. È possibile inviare testo in chiaro e formati binari arbitrari in modo sicuro attraverso un tunnel TLS crittografato. Senza la sicurezza del trasporto, i dati possono essere catturati in entrambi i modi e protetti solo tramite crittografia nel formato stesso.

Per quanto riguarda la sicurezza sul livello dell'applicazione, i dati sensibili zippati hanno storicamente stato una misura popolare contro una classe di attacchi di applicazioni Web correlate allo sniffing dei contenuti. Ad esempio, a seconda del formato dei dati segreti e della prevedibilità del percorso di download, è possibile introdurre un inclusione di script tra siti (XSSI, non XSS) offrendo download di testo in chiaro senza adeguate misure di sicurezza. Ecco uno scenario immaginario per spiegare l'attacco:

Supponiamo che qualsiasi utente autenticato sulla tua piattaforma possa scaricare un file di configurazione sensibile specifico per l'utente da questo URL:

https://yourservice.example/download/myconfig

Il file di configurazione ha il seguente formato:

user_id = 314159
secret_token = "719fe66f5159f86e798eabf930b8c9c2"

Ora un utente malintenzionato potrebbe semplicemente inviarti un collegamento a un sito Web preparato con il seguente contenuto:

<script src="https://magicservice.example/download/myconfig"></script>
<script>
    alert(secret_token);
</script>

Ciò che accade qui è che il tuo browser interpreta la risposta dal link di download come codice JS esterno e in tal modo perde i valori di user_id e secret_token nella pagina controllata da attaccante incorporante come variabili JS globali. Zippare o riformattare i dati in qualche modo avrebbe prevenuto questo attacco perché un file ZIP non può produrre codice JS valido. Sebbene questo caso specifico possa sembrare inverosimile, in passato ci sono state molte altre vulnerabilità correlate al sniffing.

Si noti che il modo corretto e moderno per mitigare questo scenario XSSI non è zippare il file ma inviare un'intestazione X-Content-Type-Options: nosniff che costringe i browser ad accettare solo JS con un tipo MIME corretto e a inviare un'intestazione Content-Disposition: attachment che istruisce i browser per non visualizzare il download in linea.

Non importa se è su HTTPS. Puoi leggere il file binario con la stessa facilità del file di testo.

Sì, ma non abbastanza da meritare di essere preoccupato, tranne che nelle impostazioni più attente alla sicurezza.

Il testo è grande, voluminoso e consiste in un set di caratteri limitato, generalmente noto, mentre un formato binario compresso come zip è compatto e tenta di utilizzare l'intera gamma di valori possibili per i suoi byte in modo da richiedere il numero più piccolo possibile di byte per rappresentare il contenuto. Inoltre rimuoverà almeno i modelli ciclici più significativi.

Tutto ciò rende più difficile la crittografia del livello di trasporto che si sta utilizzando per proteggere il download. (Quindi, perché programmi come GPG di default comprimono i messaggi prima di crittografarli.) Ma poi, se hai impostato correttamente il tuo TLS, craccarlo dovrebbe essere già così difficile che non devi preoccuparti di nessuno che non sia i governi principali e anche loro avrebbero avuto un tempo abbastanza duro da poter essere semplicemente mostrati a casa tua e picchiarti finché non hai dato loro il file.

Se non stai usando TLS, allora non fa differenza se non riesci a scegliere un formato binario così arcano che l'avversario non è in grado di identificarlo ... Nel qual caso il tuo utente probabilmente non sarà in grado di ... Quindi potresti anche dare loro dei len ($ FILE) byte da / dev / urandom da scaricare e poi masterizzare il file reale su disco e inviarlo a loro nel post.

Questo in realtà dipende un po '. Ovviamente, come tutti hanno sottolineato, la codifica come tale non impedisce alcuna sfida aggiuntiva per un utente malintenzionato, ma c'è qualcos'altro da considerare.

Ci sono un paio di cose che di solito non riesci a proteggere quando trasferisci dati criptati, fonte e destinazione sono una, la lunghezza è un'altra. Si scopre che la lunghezza è un canale laterale sorprendentemente potente, controlla link per un esempio di analisi del traffico di google maps .

Il punto che sto cercando di fare è che in alcuni rari casi la codifica può avere un effetto sulla sicurezza dell'intero sistema. Questo è particolarmente vero quando c'è un piccolo numero di stati trasmessi accettabili. Se si sceglie solo tra "No, non voglio l'offerta di lavoro". e "Sì, si prega di inviare i contratti lungo. (contratto aggiunto)", quindi sarà necessario il riempimento per la risposta negativa per rendere le informazioni uguali.

Questa è solo una versione specifica dell'entropia bassa nel problema dei dati che a volte si vede nell'hashing di identificatori e simili. Se ci sono solo un paio di milioni di input accettabili, il loro hash sarà facilmente invertibile.