La cartella degli script è vulnerabile?

Question

Nelle mie applicazioni Web .NET solitamente ho una cartella Script che contiene tutti i miei file JavaScript - jQuery per lo più in questi giorni, con la libreria JavaScript occasionale di qualche tipo o altro.

Sto eseguendo scansioni di vulnerabilità su uno dei miei siti Web tramite uno scanner chiamato Nexpose e mi ha informato che la cartella Scripts è aperta al mondo - il che significa che gli utenti non autenticati possono scaricare i file JavaScript contenuti nella cartella e che questo è una vulnerabilità critica. Secondo Nexpose, la cartella Script dovrebbe essere ristretta per consentire solo agli utenti autenticati di accedervi. Il che mi porta alla mia prima domanda.

Come limitare la cartella Script solo agli utenti autenticati? Ho provato a inserire un file web.config nella cartella Scripts e a negare l'accesso a tutti gli utenti non autenticati in quel modo, ma non ha funzionato. Sono stato in grado di determinarlo da solo, ma andando alla pagina di accesso del mio sito web, ma non effettuando l'accesso, e quindi digitando https://mywebsite/scripts/menubar.js e abbastanza sicuro mi ha permesso di scaricare il file menubar.js.

Seconda domanda - Perché è considerata una vulnerabilità? Ho provato a ragionare attraverso le possibilità qui, ma non sono riuscito a inventare molte cose. È una vulnerabilità semplicemente perché Joe the l33t h4x0r è in grado di capire le varie librerie che sto usando e quindi forse usare exploit noti contro di loro?

Aggiornamento

stragrande maggioranza la risposta sembra essere che in nessun modo dovrebbe esistere una vulnerabilità solo perché un file .js può essere aperto e letto sul browser del client. L'unica vulnerabilità che potrebbe esistere sarebbe se lo sviluppatore stesse usando il file .js in un modo insicuro di qualche tipo (che io non sono).

Answer 1

Logicamente, non si desidera in realtà impedire l'accesso ai file effettivi perché non è possibile utilizzarli nella pagina Web. Il server web non fa alcuna distinzione tra un browser che richiede un file come parte del processo di rendering di una pagina web rispetto a qualcuno semplicemente scaricando manualmente il file.

Come risultato, la risposta alla tua prima domanda è: non puoi e non vorresti. Se non vuoi che gli utenti accedano, esci dalla cartella web. Se è necessario eseguire il rendering del tuo sito, allora lo desidera che sia chiunque possa accedervi in ​​modo che il tuo sito possa essere visualizzato correttamente.

Sul motivo per cui è considerata una vulnerabilità, chi sta dicendo che lo è? Posso andare a usare qualsiasi JavaScript di Facebook adesso. O, più precisamente, potrei andare su Bank of America o sul sito Web di Chase e iniziare a guardare attraverso il loro JavaScript. Se avessi un account, potrei anche dare un'occhiata al JavaScript usato una volta che l'utente ha effettuato il login.

L'unica cosa di cui dovresti preoccuparti è la stessa cosa di cui hai sempre bisogno di preoccuparti: esporre i dettagli quello non dovrebbe essere esposto. Non sono sicuro del motivo per cui lo faresti, ma ovviamente non sarebbe una buona idea inserire la password del tuo database in un file JavaScript, ad esempio. Oltre a cose del genere, non c'è nulla di cui preoccuparsi.

Answer 2

Sì. Si dovrebbe mantenere la maggior parte dell'elaborazione da eseguire lato server, poiché la maggior parte (se non tutti) gli script lato client possono essere modificati, e così via. La maggior parte dei siti usa Javascript, quindi usarlo semplicemente non è pericoloso, devi solo stare attento a quello che fai con esso.

Inoltre, per rispondere alla prima domanda, non proteggerli se anche gli utenti non autenticati ne hanno bisogno.

Answer 3

Suona come una suite di sicurezza con un dito prurito. Gli unici due problemi che potrei vedere è che potresti finire per prestare il tuo server come CDN se qualcuno sceglie di puntare a il tuo jQuery o il tuo - nome della biblioteca di inserzioni qui- O (ora questo è un rischio reale per la sicurezza) se stai anche servendo qualsiasi tipo di file .js dinamici che potrebbero rappresentare una potenziale minaccia. L'unica altra cosa che posso pensare è se hai la tua app "personalizzata" js nel mix con tutte le librerie che qualcuno potrebbe potenzialmente scoprire i tuoi endpoint (servizi web e così via) e prova a vedere se sono sicuri ... ma è tutto! niente di più ... (a meno che tu non abbia fatto qualcosa di veramente stupido come codice duro una password o qualcosa in là ... lol)

Answer 4

Quindi l'attacco non è che le persone possono modificare lo script che l'attacco sta ottenendo il server web scrivere arbitrariamente in una directory. Quello che devi fare è assicurarti che siano file di sola lettura. chmod 400 o windows letti. In termini di difesa in profondità (DiD), si desidera assicurarsi che il server Web sia un utente non privilegiato che non può accedere al sistema. Inoltre, ciò che deve verificarsi è che si sta eseguendo la sanitizzazione dei dati sul server, indipendentemente da ciò che si sta facendo dal lato client, perché non si controlla il lato client. In genere ciò comporta la pulizia di tutti i dati provenienti dal Web e dal database prima che vengano pubblicati.Una delle cose che preferisco fare è inserire il javascript arbitrario nel database e guardarlo fare cose nell'interfaccia utente perché il team di sviluppo ha pensato che tutto sarebbe andato bene visto che lo avevano già pulito una volta.

Sono in grado di fornire maggiori dettagli sulla protezione del sistema se è giustificato.

Answer 5

Nella maggior parte dei casi non è una vulnerabilità. Considera tutti i massicci siti pubblici con traffico anonimo e/o dove è molto facile diventare un utente autenticato (Google, eBay, Amazon, ecc.) Questi siti hanno anche alcuni degli script più elaborati.

La cosa più sottile da tenere d'occhio sono altri file che si desidera proteggere. Ad esempio, se gli utenti devono accedere al tuo sito e acquistare un documento, video, immagine, ecc. Prima di visualizzarlo, certamente non dovrebbe essere in una cartella accessibile al pubblico.