È sicuro creare un'app Web accessibile al pubblico con URL generati da un hash?

Naviga le tue risposte
1

Se conosci un titolo migliore, non esitare a modificare il titolo.

Sto creando una semplice web app di Google in modo che i colleghi sul mio posto di lavoro possano visualizzare i dettagli su un QA che hanno ricevuto. Il problema è che alcune persone hanno account Google Apps, quindi l'app Web non può essere limitata agli utenti del nostro dominio.

Stavo pensando di generare un numero casuale per ogni risposta QA, quindi utilizzando i dettagli del QA e quel numero per generare un hash che è essenzialmente un URL univoco. cioè https://script.google.com/a/macros/MyDomain/MyApp/?code=UniqueCode . visitando quell'URL con il codice univoco mostrerai i dettagli sul QA.

Il codice univoco verrebbe recuperato tramite GET.

Questo è sicuro? Questo può essere facilmente risolto per visualizzare informazioni di base sui dipendenti?

    
posta Douglas Gaskell 23.11.2015 - 01:12
fonte

1 risposta

2

Il tuo schema è moderatamente sicuro a condizione che il valore casuale sia sufficientemente lungo e abbastanza casuale, tuttavia presenta un numero di difetti:

  • Il passaggio del token di autenticazione nell'URL significa che sarà nei log del server HTTP, nella cronologia del browser, ecc. I dati in questi luoghi non vengono generalmente memorizzati in modo particolarmente sicuro.
  • Non hai modo di revocare l'accesso (ad esempio se un dipendente lascia o se il tuo sistema è in qualche modo compromesso)
  • Non esiste un limite di tempo per la validità dei token

Idealmente avresti un qualche tipo di metodo globale per autenticare tutti gli utenti (ad esempio tutti registrano un account sul tuo sistema), ma se non hai nient'altro che indirizzi email per autenticarti con allora suggerire quanto segue:

  1. Il link inviato via email all'utente è un collegamento a una pagina di autenticazione con il contenuto / ID QA e l'email dell'utente come parametri.
  2. La pagina di autenticazione genera un hash / firma contenente il contenuto / QA ID, l'email dell'utente, un timestamp di scadenza (scadente in 30 minuti) e un ID univoco che può essere accettato solo una volta (ad esempio nonce) e invia un nuovo collegamento con l'hash / firma all'utente
  3. L'utente segue il secondo link nella nuova email contenente l'hash / firma e i parametri (scadenza, contenuto / QA ID, nonce e email) e la pagina controlla la validità dei parametri prima di visualizzare il contenuto.

Il dover attendere una e-mail contenente un secondo link ogni volta potrebbe essere un po 'fastidioso, ma presenta i seguenti vantaggi rispetto al tuo schema:

  • Gli URL nei log del server / nella cronologia del browser non costituiranno un problema di sicurezza perché possono essere utilizzati una sola volta grazie al nonce.
  • Quando qualcuno lascia la società, la loro email può essere invalidata, quindi i loro URL non saranno più accettati
  • Il timestamp di scadenza assicurerà che i vecchi link non utilizzati saranno benigni

Suggerisco anche di utilizzare token web JSON anziché attivare lo schema di firma / hashing.

    
risposta data 23.11.2015 - 02:28
fonte

Leggi altre domande sui tag

Se il mio antivirus ha rilevato file .exe sospetti trasferiti da un Mac al mio PC, sono al sicuro da loro? Lo stesso browser è ugualmente sicuro su un SO diverso?