Implicazioni di lasciare l'interfaccia utente di amministrazione accessibile agli utenti non amministratori

Devo dire una domanda autoesplicativa scritta da un uomo che sa esattamente quello che vuole. Hai già delle belle risposte, contribuendo con il mio penny come sotto.

1. È estremamente comune disporre di una base di codice accessibile agli sviluppatori / tester (dipendenti), tuttavia devono essere prese precauzioni come se fossero presenti chiavi di crittografia che non sarebbero parte del codice normale, nessuna password di testo in chiaro nel codice ecc.
2. È una buona pratica lasciare che le persone abbiano accesso solo alle informazioni di cui hanno bisogno per svolgere le funzioni, niente altro, meno altro, può causare perdita di dati / violazione della riservatezza / violazione del principio dei privilegi minimi, ecc.
3. Se un utente malintenzionato può vedere il codice lato client che non si suppone / può utilizzare, sarà in grado di creare un piano di attacco in base ai dati disponibili (nome ex modulo, nome e tipi di dati dei campi, sequenza in cui vengono interrogati, eventuali valori predefiniti, commenti di sviluppo ecc. Credimi se ho tutti questi dettagli, nulla può impedirmi di abbattere il sito con sforzi dedicati)
4. Sì, se questo è il caso attualmente, dovrebbe essere risolto immediatamente.
5. Se si tratta di un software aperto, esistono anche scenari da considerare come I dati sensibili sono presenti nel codice (nome utente-password, chiavi di crittografia, dettagli di comunicazione esterni, ecc.)? Se sì, questo deve essere gestito in un repository che non è accessibile a tutti. Se stai dando un ambiente di sviluppo ai dipendenti, fai dei valori fittizi di questi (lo scrubbing dei dati) e poi spingili per le persone.
6. Si trattava di repository di codice, di dati / applicazioni e ci saranno ruoli, gruppi e permessi per la segregazione dell'accesso che è obbligatorio sia dal punto di vista del DB che del codice, l'impossibilità di farlo porterà al controllo di accesso a livello di funzione mancante (voi non voglio averlo).

Ok ho scritto troppo, per riassumere se mantieni l'applicazione così com'è che stai mantenendo gli attaccanti (insider / outsider) ottimisti per l'applicazione che è vulnerabile a tutti i primi 10 rischi di OWASP.

Soluzioni (non le hai mai chiesto ma non voglio tenere aperto il ciclo)

1. Reperire il codice separato per le configurazioni, utilizzare le configurazioni fittizie nell'ambiente di sviluppo.
2. Non tenere mai nulla di aperto / leggibile nell'ambiente di produzione per le persone che non dovrebbero vederlo.
3. Anche se ora sembra aperto una volta aperto per gli esterni, avrai bisogno di permessi e misure di controllo degli accessi, implementali ora e non dovresti preoccuparti di modificare l'architettura dopo un anno o due quando il codice sarebbe sono cresciuti
4. Non dare lead / commenti / codice sulle pagine di produzione che è una miniera d'oro per gli aggressori.
   5. Segui le migliori 10 linee guida per la gestione dei rischi di OWASP.

Posso aggiungere altro, ma ritengo che questi sarebbero sufficienti per il momento.

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

Potrebbe essere più facile sfruttare vulnerabilità come CSRF o controllo di accesso mancante se un utente malintenzionato ha accesso al codice lato client e quindi alle richieste che possono essere eseguite.

Potrebbe anche essere più facile trovare vulnerabilità come XSS. Alcune vulnerabilità come XSS ora possono essere indirizzate anche agli utenti con privilegi più bassi e agli utenti con privilegi più elevati, in quanto entrambi hanno accesso all'interfaccia utente.

Is having such functionality exposed a really bad practice I should immediately address?

Non proprio. Se non è necessario, non lo esporrò comunque, a causa dei motivi illustrati sopra.

If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

Se è open source, non è nemmeno la sicurezza dell'oscurità, e nasconderlo non è strettamente necessario (anche se non è ancora una cattiva idea, soprattutto a causa della possibilità di sfruttare le vulnerabilità XSS).

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

Anche se l'hacker non è autorizzato / non è in grado di utilizzare il codice che vede, può comunque ottenere il vantaggio di ulteriori informazioni, che utilizzano per attaccare in seguito il tuo sito . Una fonte di informazioni particolarmente preziosa sono le informazioni JavaScript contenute sul lato client. Se un hacker vede come:

1. Come è strutturato il tuo codice
2. L'input è gestito
3. Gli eventi lato client sono gestiti

lui o lei ottiene preziose informazioni per sfruttare il tuo sito web in base a tali informazioni.