Boicotta i globali!

Sto rubando al commento di Steffen Ullrich, ma il problema principale con le variabili globali è che rendono difficile mantenere il codice ben organizzato e manutenibile. Il suo link va bene, ma non avrai problemi a trovare innumerevoli articoli sui problemi con le variabili globali online.

Quando usi le variabili globali, diventa facile perdere traccia di dove nel tuo programma la variabile viene modificata, specialmente se non hai un flusso lineare semplice. Di conseguenza le variabili globali possono funzionare perfettamente in piccoli script, ma possono causare enormi mal di testa quando un'applicazione inizia a scalare.

Il motivo principale per cui eviterei le globali è perché rendono il test automatico di unità / integrazione un incubo. Le piccole applicazioni possono sopravvivere senza test, ma cercare di gestire un'applicazione più grande senza buoni test è solo un incubo (credimi, ci ho provato nei miei giorni giovani e sciocchi).

Questo potrebbe lasciarti con il l'impressione che le variabili globali vadano bene in applicazioni molto piccole, ma poiché le applicazioni di solito crescono solo nel tempo e le cose che iniziano temporaneamente diventano permanenti, è davvero solo una cattiva idea usarle. Perché iniziare con il piede sbagliato, quando è così facile usare variabili con scope appropriato?

Sicurezza

L'uso di variabili globali non ha implicazioni dirette per la sicurezza, ma rendono più facile ritrovarsi con problemi di sicurezza:

Se un programmatore modifica una funzione nel file A ma non sa o dimentica che il valore per una certa variabile in quella funzione proviene dall'input dell'utente nel file B , potrebbe finire per fare cose insicure sull'input dell'utente senza adeguate guardie di sicurezza.

Variabili globali == morte

Non sono a conoscenza di violazioni avvenute specificatamente a causa di variabili globali, ma è facile sostenere che l'uso di variabili globali ha letteralmente ucciso persone, quindi penso sia ragionevole non usarli mai.

In alcuni ambienti di programmazione, non puoi fidarti dell'ambito globale poiché altre fonti potrebbero leggere / fare confusione con esso.

Ciò ha già portato ad alcune vulnerabilità critiche nella sicurezza prodotti sensibili, come un'esecuzione di codice in modalità remota nell'estensione del browser LastPass .

Possono fornire alle iniezioni di codice un accesso più facile a tutto

In PHP c'è il superglobale $ GLOBALS ; in Python c'è la funzione globals () , e in Javascript c'è l'oggetto window (o in Node, process ). Tutto ciò rende banale enumerare tutte le variabili globali.

Una volta fatto ciò, puoi sia aspirare le informazioni che contengono e modificarle in modo dannoso. Ad esempio, se i dati sensibili sono archiviati in un globale, un utente malintenzionato potrebbe facilmente estrarli. Se, ad esempio, l'URL di una connessione al database è archiviato in un globale, un utente malintenzionato potrebbe indirizzare l'URL per fare riferimento al server dell'attaccante, quindi la vittima tenterebbe di connettersi a quel server e inviare le credenziali.

Inoltre, se hai molti oggetti globali puoi chiamare i loro metodi con facilità.

Essi violano il "principio del privilegio minimo"

Questo principio dell'ingegneria della sicurezza fondamentalmente dice "non dare a qualcuno più accesso di quello di cui ha bisogno per svolgere il proprio lavoro". Ogni funzione e metodo può leggere e scrivere variabili globali anche se sono totalmente irrilevanti per il suo lavoro, il che significa che se quel pezzo di codice viene dirottato anche in qualche modo limitato, aprirà una superficie di attacco maggiore.

(Ovviamente, la maggior parte dei linguaggi di scripting ha regole di incapsulamento deboli che è anche una violazione di POLP, ma se gli oggetti sono fuori campo, è molto più difficile fargli qualcosa.)

un terreno fertile per codice difettoso

Per ragioni tra cui:

• il programmatore dimentica che una delle variabili in una funzione è globale e quindi le vengono apportate modifiche persisterà quando la funzione termina,
• la non ovvia sensibilità del programma all'ordine in cui vengono chiamate le funzioni
• la facilità con cui possono verificarsi errori a cascata ( ad esempio, quando una funzione imposta un globale su null e successivamente un'altra va in crash)
• le interazioni altamente complesse che possono verificarsi facilmente e su cui è difficile ragionare

Sono semplicemente disordinate

Se pensi a un'attività in cui ci sono documenti sparsi dappertutto, le cose non sono organizzate e archiviate in modo ordinato ma solo in giro, chi noterà se manca qualcosa? Se un dipendente commette una frode, nessuno individuerà la discrepanza perché le discrepanze sono ovunque. Se un paio di chiavi scompare, qualcuno presumerà che siano sepolti sotto qualcosa o che qualcuno abbia dovuto prenderle in prestito.

Ora potresti dire che è un'esagerazione, ma in tal caso dubito che tu abbia mai ha lavorato con un grande progetto software. I globali vanno bene se il tuo sito web è abbastanza piccolo da poter essere costruito in un paio di giorni (e sai cosa stai facendo). Possono risparmiare tempo per far funzionare qualcosa.

Ma non scalano.

Confronta le seguenti parti di codice:

1)

  /file.php: $ newconn = new PDO ('mysql : host = localhost; charset = utf8mb4; ',' username ',' password ');  

2)

  ../secrets.php: $ mysqlusername = 'nome utente'; $ mysqlpassword = 'password'; / file.php: require_once ('../ secrets.php'); $ newconn = new PDO ('mysql: host = localhost; charset = utf8mb4;', $ mysqlusername, $ mysqlpassword);  

3

  ../secrets.php: function pdoconn (i) {$ mysqlusername = ['username1', 'username2']; $ mysqlpassword = ["password1", "password2"]; $ conn = new PDO ('mysql: host = localhost; charset = utf8mb4;', $ mysqlusername [i], $ mysqlpassword [i]); return $ conn; } /file.php: require_once ('../ secrets.php'); $ newconn = pdoconn (0);  

L'esempio 1 è fuori discussione: una configurazione errata sui server di produzione potrebbe finire per mostrare parametri sensibili a parti non intenzionali.

Esempio 2 è migliore, ma quelle variabili sono disponibili in tutta l'applicazione e modificabili, il che potrebbe causare errori.

L'esempio 3 mantiene le cose molto organizzate e trasferibili.
Può essere modificato per usare le globali se ../ secrets.php invece era:

  ../secrets.php:$mysqlusername = 'username'; $ mysqlpassword = 'password'; function pdoconn () {$ conn = newPDO ('mysql: host = localhost; charset = utf8mb4;', $ GLOBALS ['mysqlusername'], $ GLOBALS ['mysqlpassword']); return $ conn;}  

E penso che questo dimostri perché un globale non ha senso il più delle volte in modo abbastanza succinto.

Riepilogo:

Per quanto riguarda le violazioni della sicurezza che utilizzano variabili globali (e perché ho scritto questi esempi in PHP), c'era (all'epoca) un cambiamento controverso in PHP 4.2.0 in cui register_globals era attivato spento. Non riesco a trovare alcun articolo ora, poiché questa modifica è stata apportata nel 2002, ma mi sembra di ricordare che all'epoca fosse responsabile di alcune violazioni. Copiando direttamente dal manuale, c'è un esempio molto chiaro di codice vulnerabile:

  <? Php // define $ authorized = true solo se l'utente è authenticatedif (authenticated_user ()) {$ authorized = true;} // Dato che non abbiamo prima inizializzato $ autorizzato come falso, questo potrebbe essere // definito tramite register_globals, come da GET auth.php? authorized = 1 // Quindi, chiunque può essere visto come autenticato! if ($ autorizzato) {include "/highly/sensitive/data.php";}?>  

Perché l'uso di variabili globali ti dà un sacco di problemi e non ha alcun vantaggio.

I valori globali rendono il tuo codice difficile da testare

Sebbene non direttamente correlato alla sicurezza, i test unitari sono vitali per lo sviluppo. E per eseguire correttamente un test unitario di qualcosa, è necessario essere in grado di controllare il contesto esatto in cui viene eseguito il codice. Guarda le due parti di codice:

With Globals

  public Money CalculateExpenses (int departmentId) {Department department = (from d in global_db .Departments dove d.Id = departmentId seleziona d) .Single (); return (da ex in department.Expenses selezionare ex) .Sum ();}  

Senza globali

  public Money CalculateExpenses (int departmentId, database database) {Department department = (da d in database.Departments dove d.Id = departmentId selezionare d) .Single (); return (da ex in department.Expenses seleziona ex) .Sum ();}  

Si potrebbe dire che il codice sembra quasi identico, tranne per la provenienza dei dati. Potresti anche pensare che il codice con Globals sia "più pulito", perché non devi passare il database ogni volta.

Fino a quando non dovrai scrivere uno unit test. Perché allora dovrai inserire una logica per non connetterti al database di produzione, ma piuttosto un database locale, magari specifico del test. Ora il codice non globale ha un aspetto molto migliore, perché puoi semplicemente passare il database che desideri utilizzare al codice.

In sintesi: il codice senza globali è più facile da testare .

Globali cambia comportamento se non cambi il codice

Se il tuo codice ha circa 200 righe di codice, l'uso di Globali non sembra poi così male. In effetti, potrebbe sembrare una cosa perfettamente valida da fare se riutilizzi lo stesso pezzo di codice ovunque (ad esempio qualche fonte di dati casuale, registrazione, ecc.)

Tuttavia, una volta che la base di codice cresce a sufficienza, l'introduzione delle variabili globali può essere assolutamente mortale. Perdi semplicemente il controllo sulla provenienza dei tuoi dati e su chi può accedervi.

Usiamo un esempio nella lingua preferita di tutti: PHP 5. Esempio di Eevee.

  @fopen ('http://example.com/not-existing-file', 'r');  

Cosa fa questo codice? Non lo sai, perché dipende dal comportamento globale. Se PHP è stato compilato con --disable-url-fopen-wrapper , non funzionerà. Lo stesso per la configurazione globale allow_url_fopen . Non sappiamo cosa farà.

@ all'inizio disabiliterà i messaggi di errore, a meno che scream.enabled non sia impostato nel campo globale Configurazione PHP. Inoltre non verrà stampato se il livello error_reporting globale non è impostato. La posizione esatta in cui verrà stampata, se viene stampata, dipenderà dal display_errors globale.

Quindi, come hai visto, il comportamento di una riga innocua dipende da 5 diverse variabili globali . Ora immagina questo scenario in una base di codice con un milione di righe e 100 programmatori diversi, tutti in team diversi, e vedrai rapidamente perché l'uso di Globals è abominevole e porta a tutti i tipi di problemi.

Immagina di andare a lavorare un giorno e il tuo codice si rompe improvvisamente, anche se non l'hai toccato. Questa è la magia di Globals.

Ci sono altri esempi del perché l'uso di Globals è cattivo, che può essere trovato nelle altre risposte.

Attacchi di overflow del buffer

Anche se abbastanza specifici per il linguaggio (vengono in mente C / C ++) e difficili da eseguire, sono un potenziale attacco.

Computerphile ha un ottimo video al riguardo, che consiglio vivamente, ma ecco una breve versione dei meccanismi di questi attacchi e di come interagisce con le variabili globali.

Si verifica un overflow del buffer quando i dati scritti in un buffer corrompono anche i valori dei dati negli indirizzi di memoria adiacenti al buffer di destinazione a causa di un controllo dei limiti insufficiente. Ciò può verificarsi quando si copiano i dati da un buffer a un altro senza prima verificare che i dati si adattino al buffer di destinazione. ( Wikipedia)

Nel caso delle variabili globali, il layout di memoria del tuo programma è abbastanza statico poiché (nella maggior parte delle lingue) avranno il loro segmento di memoria assegnato al programma inizio. Questo dà consistenza all'attaccante: è molto più facile prendere di mira la zona di memoria di un'area diversa quando si spara sempre dallo stesso punto (in caso di globali) rispetto a quando si è sempre in movimento tra i colpi.

Questo non è specifico per le variabili globali, ma contenere informazioni significative in tali strutture facilita (da non confondere con l'abilitazione!) questo tipo di attacchi.

Attenzione!

Sebbene le variabili globali potenzialmente presentino un leggero rischio per la sicurezza, se temi attacchi di buffer overflow, il tuo meccanismo di difesa di riferimento dovrebbe controllare la dimensione dell'input, non refactoring del codice per sbarazzarsi delle variabili globali.

Non ho mai avuto problemi con le variabili globali in Bash o JavaScript, molto probabilmente perché ho scritto solo piccoli script per uso personale su ambienti minimalisti.

Perché molti programmatori evitano di usare variabili globali e ci sono esempi di violazioni della sicurezza causate dall'uso di variabili globali?

In piccoli progetti le variabili globali vanno benissimo. La maggior parte dei loro problemi non si presentano. E la personalizzazione dell'ambiente Bash di cui sopra è davvero minuscola.

Le variabili globali iniziano a causare problemi mentre il tuo programma scala; il che può accadere in molti modi, ma la parte centrale del problema è la quantità di stato richiesta dalla comprensione di ogni parte di codice.

Immagina una base di codice di 10 milioni di righe . In esso ci sono 1 milione di variabili. Sono tutte globali.
In un dato pezzo di codice di 100 righe, potresti usare 20 variabili.
Ogni volta che chiami una funzione, non hai idea di quale di queste 20 variabili verrà modificata; quando la tua funzione viene avviata, non hai idea da dove provenga la variabile state.
Quindi, per capire cosa significano le tue 100 righe di codice, devi capire e tenere a mente tutti i 10 milioni di righe di codice, oppure una sorta di convenzione sulla provenienza dei dati, quali dati possono e non possono essere modificati quando chiami una funzione di supporto, ecc.

Al contrario, se il tuo codice è quasi interamente alimentato da argomenti di funzione, variabili locali e tipi restituiti, devi solo capire la tua funzione per capire cosa fa. Inoltre, se quella funzione chiama un'altra funzione, sai quali informazioni le stai passando e quali informazioni restituisce.
Potresti non sapere cosa fa con queste informazioni, ma sai cosa non fa .
Ad esempio, non può modificare intero x e ne sei certo, perché non hai passato x alla funzione, né le hai assegnato dal suo valore di ritorno!

Rendere il codice più facile da ragionare su localmente è un obiettivo molto importante. Vuoi essere in grado di leggere una funzione, sapere cosa sta facendo e identificare i bug.

Scrivere codice è molto più semplice e molto meno importante che creare codice chiaro e di facile ragionamento.
Quasi tutto il codice in un progetto ampio e persistente viene letto centinaia di volte più spesso di quanto non venga modificato e viene scritto e progettato una sola volta.
Da questa regola, rendiamo più facile ragionare a livello locale. raggiungere la regola di "evitare lo stato globale".

Variabile globale contro Super-oggetto

Le variabili globali che vengono lette / scritte sono un esempio di stato globale. Ma lo stesso può essere un superoggetto a cui ogni cosa nel progetto ha un puntatore a cui passare come primo argomento.

Un superoggetto ha ancora dei vantaggi rispetto alle variabili globali; le variabili globali spesso hanno meccanismi confusi su come vengono inizializzate e ripulite (ti sto guardando, C / C ++), e se hai un superoggetto con tutto il tuo stato "globale" puoi istanziare due versioni del tuo superoggetto ed eseguirli contemporaneamente nello stesso processo (questo tenderà a non funzionare, ma di solito è a causa di uno stato globale implicito che il sistema operativo ti impone).

Ogni variabile globale che leggi, invece di un parametro, significa che qualsiasi bit di codice , ovunque potrebbe modificarne il comportamento. Ogni variabile globale su cui scrivi significa che stai modificando il comportamento di un codice arbitrariamente lontano.

E non sono solo gli umani a trovare gli stati globali un dolore; se il tuo stato è locale, scrivere test imbriglia che "fingere" uno stato o ambiente globale diventa molto più semplice. Se c'è (diciamo) un oggetto "mouse" globale, scrivere un test unitario che crea un mouse falso che finge di fare un certo movimento diventa più difficile, potrebbe anche essere più difficile scrivere una macro che riproduce un movimento del mouse registrato in un codice, soprattutto se intendi farlo mentre l'interfaccia utente rimane sensibile all'effettivo essere umano che utilizza un mouse.

Sicurezza

La sicurezza è una funzione della comprensione di ciò che fa il tuo codice. Sicurezza, all'interno di un programma, significa "il tuo codice fa solo ciò che dovrebbe essere autorizzato a fare"; con le variabili globali, hai una capacità più debole di capire cosa fa il codice, quindi meno capacità di controllare ciò che fa.

Dal punto di vista della sicurezza, il problema con le variabili globali è che possono creare comportamenti imprevisti e interrompere la localizzazione. L'idea più generale alla base di questo si chiama "Azione a distanza", dove una parte di un programma può avere un effetto inaspettato su un'altra.

Poiché la localizzazione non funziona, invece di dover capire solo una parte del programma, tu e chiunque lavori con il programma ora dovete capire qualsiasi parte del programma che potrebbe coinvolgere la vostra variabile globale. Ciò aumenta notevolmente la complessità del progetto e, in generale, i progetti complessi hanno maggiori probabilità di essere bacati e quindi insicuri. Come disse una volta gli informatici Edsger Dijkstra "Il programmatore competente è pienamente consapevole delle dimensioni strettamente limitate del proprio cranio".

I programmi tendono a crescere con il tempo in termini di dimensioni e portata. Anche se il tuo semplice script, creato isolatamente ora fa solo una cosa senza modularità, potrebbe essere riutilizzato da qualche altra parte in futuro dove potresti aver dimenticato le brutte implicazioni delle variabili globali, o peggio, te ne sei andato e nessuno sa nemmeno che contiene variabili globali. Le variabili globali sono come lasciare buchi nel terreno, rastrelli rivolti nella direzione sbagliata pronti per essere calpestati o chiodi nel tuo vialetto.

Sono, per molti versi, in pericolo imminente e, sebbene a volte necessari, dovrebbero essere trattato come tale.

Perché molti programmatori evitano di utilizzare variabili globali e ci sono esempi di violazioni della sicurezza causate dall'utilizzo di variabili globali?

Perché è più facile modificare codice che non utilizza variabili globali da eseguire in applicazioni non intenzionali , applicazioni che lo sviluppatore originale non aveva previsto. In realtà, se dipendi dallo stato globale, puoi avere al massimo uno di questi stati in un'applicazione senza un refactoring intensivo (che farebbe il refactoring dello stato globale).

Tali applicazioni non intenzionali potrebbero includere l'esecuzione del codice in ambienti multi-thread.

Tuttavia, ciò che molte persone non riescono a realizzare: malloc () è globale!

Lo stesso le persone che sostengono di non utilizzare le variabili globali usano sempre uno stato dell'allocatore globale.

Ciò significa che se una parte del tuo codice alloca molta memoria, malloc () richiede di più memoria dal sistema operativo, i blocchi di memoria si confondono con quelli allocati da altri pezzi del tuo codice, e quando lo stesso pezzo di codice libera tutta la memoria che stava usando, free () chiama non restituire la memoria al sistema operativo a causa della frammentazione. Il risultato finale è che il tuo programma finisce per utilizzare più memoria di quanto dovrebbe.

Quindi, proprio le persone che sostengono di non usare le variabili globali, stanno in realtà usando un allocatore con uno stato globale.

Mi chiedo perché nessuno degli standard delle principali organizzazioni di standardizzazione (C89 / C99 / C11 / C18 da ISO, POSIX da IEEE) abbia definito un allocatore che consente di avere più stati allocatori, cioè heap indipendenti.

Se quasi ogni linguaggio di programmazione può dichiarare una variabile a livello globale, accessibile solo nell'ambito del suo codice di implementazione, allora questo non è un problema. Non ci sono molte ragioni per usare variabili globali.

Tuttavia, non è così, motivo per cui quando mi sono ritrovato a scrivere i miei progetti in C & non in C ++, dove è naturalmente supportata come variabile statica alla clausola più esterna di una definizione di classe, ho dovuto accontentarmi delle variabili globali.