Modalità debug per un'applicazione ma rimossa in produzione

Question

Modalità debug per un'applicazione ma rimossa in produzione

#1 da (1 voti)
#2 da (0 voti)

2

Un'applicazione usa il debug come booleano per il login di prefill, password per l'autenticazione.

Il codice è qualcosa del genere:

if (ContantsFile.CUSTOM_DEBUG_FLAG) //static final
{
//disable access control ==> admin mode (admin section are now visible for anybody)
}

L'applicazione è codificata in JAVA. E constants.class è un altro consegnato in produzione.

Ho la sensazione (scusami se sono ancora un principiante nel campo) che questo modello è un difetto di sicurezza per il seguente motivo: - Se un utente malintenzionato potrebbe modificare costants.class in produzione, l'intera applicazione sarà vulnerabile

Ovviamente è una cattiva pratica per un punto di vista DEV (io sono uno sviluppatore).

Hai migliori spiegazioni o argomenti? Questi sviluppatori mi risponderanno che se un utente malintenzionato ha accesso al suo file, è già all'interno dell'applicazione e potrebbe cambiare qualsiasi cosa.

Grazie in anticipo

Frenchy

code-review

posta Omar Elfada 28.12.2011 - 15:27

fonte

2 risposte

Leggi altre domande sui tag code-review

Blocco dei certificati in un browser Quanto è sicuro Goodlink per i telefoni cellulari rispetto ad Activesync?

score 1 · Answer 1

Nel codice che hai postato, il nome utente e la password potrebbero essere facilmente estratti dal binario compilato.

Se lo farai in questo modo, usa una direttiva per il preprocessore come #if DEBUG in modo che il codice non sia nemmeno compilato in una build di rilascio.

Questo lascia ancora vulnerabili gli altri ambienti, quindi non codificherò affatto il nome utente e la password e utilizzerò invece un gestore di password per riempirlo automaticamente. Inoltre, un nome utente e una password di sviluppo probabilmente non dovrebbero essere validi in un sistema di produzione.

score 0 · Answer 2

Il linguaggio di programmazione usato in questo codice può essere importante.

Se questo utilizza Java e il campo CONSTANTS.debug è dichiarato con static final , quindi il compilatore Java (che ha trasformato i file .java in .class file) propagava effettivamente la costante booleana nel codice e ottimizzava la sezione del codice; la parte con login e password precompilati è scomparsa e non può essere resuscitata dall'attaccante. Puoi verificarlo cercando il nome di accesso nei file .class (apri .jar - è solo un archivio Zip con un altro nome - e avvia un grep sui file .class : in Java, le stringhe letterali e fino UTF-8 codificato nei file .class , quindi grep li localizzerà).

Con altre lingue, il tuo chilometraggio può variare. Qualsiasi compilatore C decente dovrebbe propagare costanti (almeno quelle definite come macro) e ottimizzare il codice morto (cioè il codice che, dopo la sostituzione della macro, assomiglia a if (0) { ... } ).

Gli sviluppatori hanno ragione nel senso seguente: se gli attaccanti possono modificare a piacimento il codice dell'applicazione, allora hai già problemi più grandi.

Si noti, tuttavia, che l'accesso e la password hardcoded nel codice sorgente significa che un utente malintenzionato che ha accesso in sola lettura a quel codice sorgente potrebbe apprenderli. Quindi devi preoccuparti della sicurezza fisica dei tuoi backup. Come sottolinea @pdubs, le coppie di login + password utilizzate per lo sviluppo non dovrebbero essere valide nel sistema distribuito (che annullerebbe tale problema).