I file di risorse JavaScript sono disponibili senza autenticazione: si tratta di un rischio per la sicurezza?

1

Sto testando un'applicazione e ho trovato poche pagine javascript accessibili pubblicamente. Ho anche trovato in precedenza pochi siti Web che consentono l'accesso pubblico alle pagine .js. Quindi per me questo può essere considerato un problema di sicurezza, dal momento che una delle pagine ngapp.js contiene l'intera logica della pagina angularjs. E se vuole proteggere tali pagine postare l'autenticazione, è possibile? Qualcuno può chiarire questo?

    
posta PenGeek 20.10.2016 - 14:01
fonte

2 risposte

5

Quindi immagino che l'unità della tua domanda non sia se i file JavaScript siano offuscati o meno, ma piuttosto se siano pre-autenticazione accessibili?

Se così fosse, direi che non dovrebbe essere un problema dato che il JavaScript viene inviato lato client e quindi nessuna informazione sensibile dovrebbe essere inclusa in essa.

Detto questo, come misura di indurimento in genere raccomando di non fornire alcuna informazione a un utente malintenzionato che non è necessario, quindi limitare l'accesso alla post-autenticazione laddove possibile. Cose come le app Angolari possono rivelare molte informazioni come percorsi di applicazione validi che sono utili agli aggressori nel cercare di trovare altri problemi.

In termini di come raggiungere questo obiettivo, suggerirei di poter separare i modelli del sito, in modo tale che l'app principale Angolare (o simile) sia accessibile solo dopo l'autenticazione.

    
risposta data 20.10.2016 - 15:17
fonte
1

Questo è il design previsto e non un problema, tranne quando gli autori del sito dimenticano che questo è il design previsto.

In un'applicazione web, Javascript deve essere leggibile dal browser, perché è lì che viene analizzato ed eseguito. E tutto ciò che è leggibile dal browser è leggibile da un utente malintenzionato. Pertanto, la sicurezza del sistema non può dipendere dalla segretezza di Javascript.

Forse stai pensando alle regole sugli script CGI. Uno script CGI viene eseguito sul server, non sul client, e quindi non è necessario per essere letto dal client. Inoltre, non è insolito che le informazioni "segrete" (come le stringhe di connessione al database con nomi utente e password) siano incorporate nello script CGI, il che significa che averlo letto al client è molto brutto. E poiché si tratta di un errore di configurazione del server Web in qualche modo comune (per consentire al download dello script di origine CGI dal client), c'è un problema di sicurezza.

Naturalmente, alcuni autori web preferiscono che il loro Javascript non sia facilmente leggibile. Questo è generalmente un problema di proprietà intellettuale piuttosto che di sicurezza, anche se gli autori di malware in particolare useranno varie tecniche di offuscamento ( ecco un esempio ) per rendere difficile per l'attaccante leggere il loro codice. Questa non è una vera misura di sicurezza, ma aumenta il costo per il lettore di determinare cosa sta facendo Javascript.

A volte gli autori dimenticano che il loro Javascript non è segreto. BMC Remedy aveva una "misura di sicurezza" per proteggere le credenziali quando la connessione era su HTTP non criptato. Il codice Javascript "scramble" la password dell'utente prima che fosse inviata in rete dal browser al server. Sfortunatamente, lo "scrambling" era sulla falsariga di "Sostituisci A con Q, sostituisci B con G, ..." ed è stato facilmente annullato da qualsiasi attaccante che leggesse il Javascript e catturasse il traffico non criptato.

    
risposta data 20.10.2016 - 15:06
fonte

Leggi altre domande sui tag