Discussione Ufficiale La programmazione e la sicurezza del codice: una necessità per le scuole

[haxo]

In un'era dove la tecnologia è sempre più presente nella vita quotidiana, l'importanza della sicurezza nella programmazione non può essere trascurata. Tuttavia, ci sono ancora molte scuole che insegnano a programmare in maniera scorretta e poco sicura, mettendo a rischio la sicurezza dei dati e la privacy degli utilizzatori. Queste pratiche, se non corrette, possono portare a gravi problemi di sicurezza, come falle di sicurezza e violazioni dei dati.

1    INTRODUZIONE

La programmazione sta diventando sempre più importante nella nostra società, dall'utilizzo delle app che usiamo ogni giorno per la comunicazione e lo shopping, fino ai sistemi di sicurezza che proteggono le nostre informazioni personali (o almeno che dovrebbero farlo).

Le pratiche di codifica non sicure includono la mancata gestione corretta degli errori, la mancanza di controlli di accesso, la mancata crittografia dei dati sensibili e l'utilizzo di componenti vulnerabili. Se non correttamente gestite, queste pratiche possono portare a gravi problemi di sicurezza, come falle di sicurezza e violazioni dei dati. Questi problemi possono avere conseguenze serie per gli utenti finali, compreso il furto di informazioni personali, come password e informazioni finanziarie, e anche la compromissione dei sistemi e delle reti.

Essendo ancora uno studente, vi posso confermare che purtroppo questo, in molte classi non viene insegnato, mettendo a rischio le applicazioni che creeranno.

2    LA NON GESTIONE DEGLI ERRORI NELLA PROGRAMMAZIONE

La non gestione corretta degli errori nella programmazione comporta rischi per la sicurezza dei dati e la privacy, tra cui:

1. Vulnerabilità: la NON gestione degli errori può rendere un sistema vulnerabile a attacchi informatici. (pensiamo all'XSS o SQL Injection)
2. Interruzione del servizio: gli errori non gestiti possono causare la interruzione del servizio e quindi il crash del sistema, rendendo il sistema inutilizzabile.
3. Prestazioni lente: la mancata gestione degli errori può causare problemi di prestazioni, ad esempio tempi di risposta lenti o spreco inutile dell'utilizzazione del sistema.
4. Mancata fiducia dell'utente: la mancata gestione degli errori può ridurre la fiducia degli utenti nella sicurezza del sistema, poiché dimostra che il sistema non è per niente affidabile.

3    LE AZIENDE ASSUMONO PERSONALE CHE NON SA GESTIRE LA SICUREZZA

Uno dei tanti effetti collaterali che riguardano l'assunzione del personale che non sa gestire la sicurezza è quella dei dati non sicuri, in quanto vulnerabili. Se le aziende ercontinuano ad assumere del personale che non ha le giuste conoscenze per gestire la sicurezza e gli errori, i dati degli utenti saranno facilmente esposti a rischi (anche gravi).

4    L'ANELLO PIU' DEBOLE DELLA SICUREZZA: IL FATTORE UMANO

Gli studenti dovrebbero avere una conoscenza base di quella che viene chiamata "ingegneria sociale".
Non importa quali strumenti di sicurezza utilizziamo (anche i più sicuri del mondo), se i dipendenti non vengono istruiti a riconoscere le minacce degli ingegneri sociali.

Praticamente è come se installassimo tutto il necessario per rendere la nostra casa sicura, ma lasciassimo la finestra di una stanza aperta, risultato? guai seri.

Con l'avanzare degli anni, altri prodotti di sicurezza verranno installate nelle aziende, per questo l'attaccante deciderà di sfruttare i punti deboli del lato umano.

 

[fennek]

Se posso condividere la mia esperienza, ci sono alcune cose che mi piacerebbe aggiungere:

1. la "sicurezza" di un sistema non è un interruttore. Non esistono sistemi sicuri e sistemi non sicuri. Esistono sistemi più sicuri e sistemi meno sicuri. Quanto deve essere sicuro il sistema dipende dal tuo threat model, dal valore dei dati che proteggi, e da tutte quelle considerazioni che si fanno durante il "risk assessment". Diverse cose concorrono a decidere l'outcome, compreso il tuo budget. Per esempio, il sistema su cui lavoro è airgapped, tutto ridondante, con multipli firewall perimetrali. Ma manco con tutti gli stipendi che prenderò nella mia vita potrei permettermelo, quindi per i miei documenti personali li metto su qualcosa di un pochino meno sicuro, ma che costa 6 zeri di meno al mese
2. oltre alla parte di programmazione, l'intera infrastruttura intorno deve essere studiata per essere sicura. Per esempio, i sistemi non dovrebbero essere in grado di aprire connessioni outgoing, ma solo rispondere. In generale, la sicurezza è verticale: parte dalla sicurezza fisica dell'hardware, dei device dei tuoi dipendenti (e non del network! ZeroTrust/BeyondCorp docet: noi per esempio anche se siamo connessi alla rete aziendale, da certi paesi abbiamo accesso limitato. Stessa cosa, se andiamo per business in certi paesi, ci danno un nuovo laptop e un nuovo smartphone che vengono poi fisicamente distrutti al ritorno. Per molte aziende questo chiaramente sarebbe overkill, e si ritorna allo step 1), dalle procedure per proteggere il tuo codice sorgente (4 eyes principles, signed commits), all'educazione dei tuoi dipendenti.
3. Il monitoraggio è chiaramente fondamentale: devi poter avere chiara visibilita su quello che succede, ed essere proattivo (e.g., scanner)
4. Devi avere delle policy in place: cosa succede se una nuova vulnerabilità viene pubblicata? Come aggiorni i tuoi sistemi? Quanto ti ci vuole a far arrivare un hotfix in produzione?

Personalmente, trovo l'intero discorso sulla sicurezza affascinante, perché è parte integrante di qualsiasi attività, ed ogni volta che parli con qualcuno impari qualcosa di nuovo, visto che è un mondo incredibilmente vasto, ci sono sempre nuovi particolari da scoprire Ed è per questo che un forum come Inforge è affascinante ;-)

 

[0xbro]

A scuola molto probabilmente verrà mostrato il tutto senza accennare nemmeno ai frameworks, e magari con qualche pratica sbagliata.

Purtroppo è proprio così... io sono uscito da un ITIS informatico che sapevo scrivere del codice funzionante, ma non sapevo nemmeno cosa fosse del codice ottimizzato o del codice sicuro. Per il meme, ho ripreso alcuni programmi che avevo scritto alle superiori e, ovviamente, erano tutti programmi molto facilmente bucabili e pieni di bug. Ah, non avevamo nemmeno mai utilizzato dei framework, sempre e solo codice scritto a mano, da zero, per cui puoi immaginare da te cosa non ci fosse in questi siti web...

Nella realtà questo discorso è ahimè più complesso di così.
Se stai parlando sempre dello sviluppo, è complesso poichè quando assumi un Junior lo devi anche formare in merito alla sicurezza, non puoi aspettarti (tu azienda) che la persona conosca tutte le pratiche ad oggi utilizzate (Auth0 compreso, magari). Purtroppo manca spesse volte la formazione interna, e chi sviluppa viene lasciato nel suo mondo, senza nemmeno una guida con più esperienza.
Non me la sentirei di dare la colpa al personale insomma, non in toto; il personale dovrebbe avere le competenze minime, ma dovrebbe poi essere formato (e se entri da junior la figura che hai sopra deve controllare e correggerti quando sbagli).

Sono d'accordo con quanto dici, il personale dovrebbe avere delle conoscenze minime, ma sono anche sempre più convinto che i fondamenti di sicurezza di base si debbano iniziare ad anticipare nelle scuole superiori, soprattutto perché ogni anno numerosi neo-diplomati degli ITIS informatici vengono assunti come software dev senza aver però mai toccato un framework e senza aver mai studiato un minimo la sicurezza del codice.

Qualche settimana fa sono tornato nella mia vecchia scuola e ho appreso di come ai professori sia stato richiesto di seguire dei corsi di aggiornamento incentrati proprio sulla sicurezza informatica (non so che tipo di corsi fossero, ma è già un passo avanti il fatto che i prof abbiano dovuto seguirli). Però non basta ancora, e infatti i prof mi hanno chiesto di collaborare con la scuola e portare - in futuro - la mia esperienza nel settore infosec tra i banchi degli studenti; primo per sensibilizzare sulla materia, secondo per far capire come le loro applicazioni possano subire effettivamente dei reali attacchi, e terzo per aiutare gli studenti a prepararsi (anche autonomamente) al mondo reale.


Con questo vorrei anche fare un appello a tutte le persone che sono qui e che masticano un po' di questi concetti: cercate di fare sensibilizzazione e di portare la vostra esperienza a chi ancora non ha avuto modo di toccarla con mano. Che siano i vostri compagni di classe, i vostri colleghi, i vostri vecchi professori o il vostro gruppo di amici. La scuola, si sa, non prepara ancora a dovere - e forse non lo farà mai - ma noi singoli, che queste cose le viviamo, possiamo provare a colmare questo gap. Se ne avete l'opportunità, fatelo!

 

[--- Ra ---]

Guarda, per esperienza quando sviluppi qualcosa è scontato trovare delle vulnerabilità, il fattore umano è l'unica vera cosa che non puoi combattere, perché se l'utente fa stronzate durante l'utilizzo e arreca dei danni al suo sistema non è di certo colpa tua, ovviamente la mia opinione su quello che deve poter fare un utente è abbastanza chiaro, meno può fare in modo semplice, meglio è, infatti, un buon sistema ha una granularità di permessi molto vasti, così evitiamo molti problemi con istruzioni arbitrarie. Da noi queste cose le si spiegava e prendevi un votaccio se il tuo programma poteva venir manomesso in meno di 5 minuti, quindi, ne so qualcosa, il nostro docente era un asso nel trovare i bug ed era il suo gioco preferito nella correzione degli esercizi, come biasimarlo, quello è anche il mio gioco preferito, andare a trovare una piccola crepa nel prodotto e infilarci di forza un ordigno, funziona sempre, se sai sgamare i bug lo fai subito.

Mi sento di dissentire su un paio di cose. Innanzitutto non è sempre vero quello che dici in merito alla responsabilità del programmatore: se si progetta un Sistema Operativo, per esempio, e si permette all'utilizzatore di fare dei danni durante un consueto utilizzo del software, allora la colpa è necessariamente dello sviluppatore, che non ha preso le misure necessarie affinché il sistema fosse sicuro. Si pensi anche ad un sistema bancario...in questi casi un programmatore non può commettere quasi alcun tipo di errore nella progettazione, altrimenti le conseguenze sarebbero devastanti. In secundis, il sistema non deve essere di difficile utilizzo come hai proposto dicendo "meno può fare in modo semplice, meglio è", ma deve essere usabile. La cosa importante è che venga rispettato il principio del minimo privilegio: ossia bisogna assegnare all'utente il privilegio più basso possibile per lo svolgimento del compito che ha richiesto. Poi ci sono tante altre regole che riguardano i meccanismi di protezione e sicurezza, che occorre rispettare in numerosi contesti per avere un sistema quasi sicuro. Ovvio poi che la sicurezza al 100% non esiste.

 

[DispatchCode]

Ho anche io un mio pensiero in merito, dopo anni di lavoro.

Le pratiche di codifica non sicure includono la mancata gestione corretta degli errori, la mancanza di controlli di accesso, la mancata crittografia dei dati sensibili e l'utilizzo di componenti vulnerabili. Se non correttamente gestite, queste pratiche possono portare a gravi problemi di sicurezza, come falle di sicurezza e violazioni dei dati. Questi problemi possono avere conseguenze serie per gli utenti finali, compreso il furto di informazioni personali, come password e informazioni finanziarie, e anche la compromissione dei sistemi e delle reti.

Sulla gestione degli errori è vero. Ho visto codici senza try/catch per esempio, oppure quando utilizzati, viene fatto un pò alla buona (eg. catch(\Exception e), così catturi tutto senza capire poi l'eccezione esatta).

A scuola purtroppo non accenna e non si insegnano (anche per motivi di tempo oltre che di programmi scolastici) strumenti che poi vengono usati a lavoro; per esempio, i "controlli di accesso" così come la sicurezza delle query è ormai demandata sempre ai framework. Che programmi in Java o in PHP usi un framework (Symphony, Laravel, Spring per Java e così via) quindi i check sulla sicurezza e la pulizia avviene in maniera trasparente (come per le sql injection, per esempio).

A scuola molto probabilmente verrà mostrato il tutto senza accennare nemmeno ai frameworks, e magari con qualche pratica sbagliata.

Sulla crittografia, dipende dalle applicazioni: per esempio, se hai a che fare con i pagamenti, non andrai a prenderti a farti carico del problema di cifrare i dati di una carta di credito per tenerli sul tuo DB. Non li salvi a DB direttamente, ti appoggi a gateway come ad esempio Stripe.

2 LA NON GESTIONE DEGLI ERRORI NELLA PROGRAMMAZIONE​

La non gestione corretta degli errori nella programmazione comporta rischi per la sicurezza dei dati e la privacy, tra cui:

1. Vulnerabilità: la NON gestione degli errori può rendere un sistema vulnerabile a attacchi informatici. (pensiamo all'XSS o SQL Injection)
2. Interruzione del servizio: gli errori non gestiti possono causare la interruzione del servizio e quindi il crash del sistema, rendendo il sistema inutilizzabile.
3. Prestazioni lente: la mancata gestione degli errori può causare problemi di prestazioni, ad esempio tempi di risposta lenti o spreco inutile dell'utilizzazione del sistema.
4. Mancata fiducia dell'utente: la mancata gestione degli errori può ridurre la fiducia degli utenti nella sicurezza del sistema, poiché dimostra che il sistema non è per niente affidabile.

Sul punto 1 vale quanto dicevo sopra.
Sul resto concordo più o meno, sul punto 3 un pò meno (ora mi spiego). Il 4 è verissimo, ma non ne farei un problema di sicurezza: il fatto di usarlo e vedere un errore ti fa pensare che il prodotto che stai utilizzando non è all'altezza, che può crearti rallentmenti nell'utilizzo e via dicendo.

Sul punto 3 concordo in parte poichè le prestazioni spesso subiscono degradi dovuti al codice non ottimizzato. Specie se questo codice ha a che fare con delle query. Ad oggi per fortuna esistono sistemi che semplificano un pò le cose... come l'utilizzo della cache (Redis), che se usata dove serve e non a c@zzo, rende le applicazioni molto fluide.
Se parliamo di software desktop allora il discorso è diverso e mi trovo più in linea con quanto hai scritto, oltre che al codice scritto in maniera non ottimizzata.

la mia opinione su quello che deve poter fare un utente è abbastanza chiaro, meno può fare in modo semplice, meglio è, infatti, un buon sistema ha una granularità di permessi molto vasti, così evitiamo molti problemi con istruzioni arbitrarie.

Se intendi che meno cose può fare e meglio è, mi trovo d'accordo. I software dovrebbero essere i più semplici e chiari possibili da utilizzare, l'interfaccia pulica, le opzioni poche; se c'è meno scelta ma quello che c'è è utile e l'utente è guidato, ci si evita anche buona parte dei problemi di usabilità.

3 LE AZIENDE ASSUMONO PERSONALE CHE NON SA GESTIRE LA SICUREZZA​

Uno dei tanti effetti collaterali che riguardano l'assunzione del personale che non sa gestire la sicurezza è quella dei dati non sicuri, in quanto vulnerabili. Se le aziende ercontinuano ad assumere del personale che non ha le giuste conoscenze per gestire la sicurezza e gli errori, i dati degli utenti saranno facilmente esposti a rischi (anche gravi).

Nella realtà questo discorso è ahimè più complesso di così.
Se stai parlando sempre dello sviluppo, è complesso poichè quando assumi un Junior lo devi anche formare in merito alla sicurezza, non puoi aspettarti (tu azienda) che la persona conosca tutte le pratiche ad oggi utilizzate (Auth0 compreso, magari). Purtroppo manca spesse volte la formazione interna, e chi sviluppa viene lasciato nel suo mondo, senza nemmeno una guida con più esperienza.
Non me la sentirei di dare la colpa al personale insomma, non in toto; il personale dovrebbe avere le competenze minime, ma dovrebbe poi essere formato (e se entri da junior la figura che hai sopra deve controllare e correggerti quando sbagli).

 

[DispatchCode]

Comunque non si può affermare che le aziende non abbiano le competenza per poter verificare il software che distribuiscono, semplicemente più il tuo software si diffonde più è facile che un buco venga trovato, nulla di più nessuno è perfetto e tutti possiamo fare degli errorini che poi si trasformano in delle vere e proprie valanghe.

Si concordo. Sviluppando ti rendi conto che fare uscire cose funzionanti è già un'ottima cosa, se sono utilizzabili allora hai fatto il tuo. C'è poi da dire che ci si appoggia a dipendenze esterne anche, quindi in un certo senso "ti affidi" arrivato ad un certo punto (per esempio, Log4J, tanto per dire).

 

[TheWorm91]

sono uscito da un ITIS informatico che sapevo scrivere del codice funzionante, ma non sapevo nemmeno cosa fosse del codice ottimizzato o del codice sicuro. Per il meme, ho ripreso alcuni programmi che avevo scritto alle superiori e, ovviamente, erano tutti programmi molto facilmente bucabili e pieni di bug. Ah, non avevamo nemmeno mai utilizzato dei framework, sempre e solo codice scritto a mano, da zero, per cui puoi immaginare da te cosa non ci fosse in questi siti web...

Stessa situazione ma non me la sento di criticare troppo il sistema di insegnamento di quel periodo, le ore a disposizione erano veramente poche ed era un periodo diverso da oggi per quanto riguarda gli attacchi e la sicurezza informatica.
Penso di aver avuto dei buoni professori che mi hanno insegnato molto.
Sono convinto che con il macello che sta accadendo verrà data molta più importanza alla sicurezza nei programmi scolastici.

 

[nfvblog]

Mi sento di dissentire su un paio di cose. Innanzitutto non è sempre vero quello che dici in merito alla responsabilità del programmatore: se si progetta un Sistema Operativo, per esempio, e si permette all'utilizzatore di fare dei danni durante un consueto utilizzo del software, allora la colpa è necessariamente dello sviluppatore, che non ha preso le misure necessarie affinché il sistema fosse sicuro. Si pensi anche ad un sistema bancario...in questi casi un programmatore non può commettere quasi alcun tipo di errore nella progettazione, altrimenti le conseguenze sarebbero devastanti. In secundis, il sistema non deve essere di difficile utilizzo come hai proposto dicendo "meno può fare in modo semplice, meglio è", ma deve essere usabile. La cosa importante è che venga rispettato il principio del minimo privilegio: ossia bisogna assegnare all'utente il privilegio più basso possibile per lo svolgimento del compito che ha richiesto. Poi ci sono tante altre regole che riguardano i meccanismi di protezione e sicurezza, che occorre rispettare in numerosi contesti per avere un sistema quasi sicuro. Ovvio poi che la sicurezza al 100% non esiste.

Si, ovviamente se si tratta ovviamente, nel normale utilizzo un programma non si deve rompere, è un prerequisito indispensabile. Ovviamente se l'utente forza delle condizioni li non puoi farci molto.

 

[--- Ra ---]

Si concordo. Sviluppando ti rendi conto che fare uscire cose funzionanti è già un'ottima cosa, se sono utilizzabili allora hai fatto il tuo. C'è poi da dire che ci si appoggia a dipendenze esterne anche, quindi in un certo senso "ti affidi" arrivato ad un certo punto (per esempio, Log4J, tanto per dire).

Si concordo anch'io. Ovviamente non si può mai fare tutto da soli...viviamo sulle spalle dei giganti ehehe.
P.s: Hanno trovato vulnerabiltà critiche qualche tempo fa anche in Log4J

 

[0xbro]

Ho appena scoperto, con mio grande piacere, che in North Dakota è stata firmata il 24 marzo una nuova legge che inserisce l'insegnamento dell'informatica e della sicurezza informatica nelle scuole elementari, medie e superiori!

Le parole di Kirsten Baesler, sovrintendente scolastico:

"Oggi è il culmine di anni di lavoro delle parti interessate di tutti i settori per riconoscere e promuovere l'importanza dell'educazione alla cybersicurezza e all'informatica nelle nostre scuole elementari, medie e superiori [...]. I nostri studenti hanno più che mai accesso a computer e dispositivi tecnologici nelle nostre scuole. È fondamentale che i nostri studenti apprendano anche le competenze in materia di sicurezza informatica. La capacità di gestire la tecnologia è importante anche per aiutare gli studenti del Nord Dakota a trovare un buon lavoro. I datori di lavoro cercano studenti che abbiano le capacità di affrontare sfide tecnologiche e attacchi informatici e di portare a termine le attività quotidiane utilizzando dispositivi tecnologici"

Una divisione dello Stato, chiamata EduTech, svilupperà esempi di piani di cybersicurezza e informatica che amministratori e insegnanti potranno utilizzare per assistere le scuole nello sviluppo dei propri piani.

 

[0xbro]

Questa è una bella notizia! Soltanto in North Dakota o anche in altri stati Americani? Speriamo che iniziative di questo tipo vengano adottate presto anche qui in Italia

Da quel che ho letto, al momento il North Dakota è il primo stato in USA a fare una cosa simile, però questo fa comunque ben sperare perchè spesso poi i singoli stati seguono a ruota l'iniziativa del primo. La mia speranza è che una decisione simile si rifletta anche nell'unione europea - sia per le visioni spesso comuni con l'USA, sia per una questione di "concorrenza nella formazione di giovani specializzati". Potrebbe però volerci ancora del tempo, but never say never

 

[nfvblog]

Guarda, per esperienza quando sviluppi qualcosa è scontato trovare delle vulnerabilità, il fattore umano è l'unica vera cosa che non puoi combattere, perché se l'utente fa stronzate durante l'utilizzo e arreca dei danni al suo sistema non è di certo colpa tua, ovviamente la mia opinione su quello che deve poter fare un utente è abbastanza chiaro, meno può fare in modo semplice, meglio è, infatti, un buon sistema ha una granularità di permessi molto vasti, così evitiamo molti problemi con istruzioni arbitrarie. Da noi queste cose le si spiegava e prendevi un votaccio se il tuo programma poteva venir manomesso in meno di 5 minuti, quindi, ne so qualcosa, il nostro docente era un asso nel trovare i bug ed era il suo gioco preferito nella correzione degli esercizi, come biasimarlo, quello è anche il mio gioco preferito, andare a trovare una piccola crepa nel prodotto e infilarci di forza un ordigno, funziona sempre, se sai sgamare i bug lo fai subito.

 

[--- Ra ---]

Se posso condividere la mia esperienza, ci sono alcune cose che mi piacerebbe aggiungere:

1. la "sicurezza" di un sistema non è un interruttore. Non esistono sistemi sicuri e sistemi non sicuri. Esistono sistemi più sicuri e sistemi meno sicuri. Quanto deve essere sicuro il sistema dipende dal tuo threat model, dal valore dei dati che proteggi, e da tutte quelle considerazioni che si fanno durante il "risk assessment". Diverse cose concorrono a decidere l'outcome, compreso il tuo budget. Per esempio, il sistema su cui lavoro è airgapped, tutto ridondante, con multipli firewall perimetrali. Ma manco con tutti gli stipendi che prenderò nella mia vita potrei permettermelo, quindi per i miei documenti personali li metto su qualcosa di un pochino meno sicuro, ma che costa 6 zeri di meno al mese
2. oltre alla parte di programmazione, l'intera infrastruttura intorno deve essere studiata per essere sicura. Per esempio, i sistemi non dovrebbero essere in grado di aprire connessioni outgoing, ma solo rispondere. In generale, la sicurezza è verticale: parte dalla sicurezza fisica dell'hardware, dei device dei tuoi dipendenti (e non del network! ZeroTrust/BeyondCorp docet: noi per esempio anche se siamo connessi alla rete aziendale, da certi paesi abbiamo accesso limitato. Stessa cosa, se andiamo per business in certi paesi, ci danno un nuovo laptop e un nuovo smartphone che vengono poi fisicamente distrutti al ritorno. Per molte aziende questo chiaramente sarebbe overkill, e si ritorna allo step 1), dalle procedure per proteggere il tuo codice sorgente (4 eyes principles, signed commits), all'educazione dei tuoi dipendenti.
3. Il monitoraggio è chiaramente fondamentale: devi poter avere chiara visibilita su quello che succede, ed essere proattivo (e.g., scanner)
4. Devi avere delle policy in place: cosa succede se una nuova vulnerabilità viene pubblicata? Come aggiorni i tuoi sistemi? Quanto ti ci vuole a far arrivare un hotfix in produzione?

Personalmente, trovo l'intero discorso sulla sicurezza affascinante, perché è parte integrante di qualsiasi attività, ed ogni volta che parli con qualcuno impari qualcosa di nuovo, visto che è un mondo incredibilmente vasto, ci sono sempre nuovi particolari da scoprire Ed è per questo che un forum come Inforge è affascinante ;-)

Condivido appieno @fennek, è proprio così.

 

[nfvblog]

Ho anche io un mio pensiero in merito, dopo anni di lavoro.



Sulla gestione degli errori è vero. Ho visto codici senza try/catch per esempio, oppure quando utilizzati, viene fatto un pò alla buona (eg. catch(\Exception e), così catturi tutto senza capire poi l'eccezione esatta).

A scuola purtroppo non accenna e non si insegnano (anche per motivi di tempo oltre che di programmi scolastici) strumenti che poi vengono usati a lavoro; per esempio, i "controlli di accesso" così come la sicurezza delle query è ormai demandata sempre ai framework. Che programmi in Java o in PHP usi un framework (Symphony, Laravel, Spring per Java e così via) quindi i check sulla sicurezza e la pulizia avviene in maniera trasparente (come per le sql injection, per esempio).

A scuola molto probabilmente verrà mostrato il tutto senza accennare nemmeno ai frameworks, e magari con qualche pratica sbagliata.

Sulla crittografia, dipende dalle applicazioni: per esempio, se hai a che fare con i pagamenti, non andrai a prenderti a farti carico del problema di cifrare i dati di una carta di credito per tenerli sul tuo DB. Non li salvi a DB direttamente, ti appoggi a gateway come ad esempio Stripe.



Sul punto 1 vale quanto dicevo sopra.
Sul resto concordo più o meno, sul punto 3 un pò meno (ora mi spiego). Il 4 è verissimo, ma non ne farei un problema di sicurezza: il fatto di usarlo e vedere un errore ti fa pensare che il prodotto che stai utilizzando non è all'altezza, che può crearti rallentmenti nell'utilizzo e via dicendo.

Sul punto 3 concordo in parte poichè le prestazioni spesso subiscono degradi dovuti al codice non ottimizzato. Specie se questo codice ha a che fare con delle query. Ad oggi per fortuna esistono sistemi che semplificano un pò le cose... come l'utilizzo della cache (Redis), che se usata dove serve e non a c@zzo, rende le applicazioni molto fluide.
Se parliamo di software desktop allora il discorso è diverso e mi trovo più in linea con quanto hai scritto, oltre che al codice scritto in maniera non ottimizzata.



Se intendi che meno cose può fare e meglio è, mi trovo d'accordo. I software dovrebbero essere i più semplici e chiari possibili da utilizzare, l'interfaccia pulica, le opzioni poche; se c'è meno scelta ma quello che c'è è utile e l'utente è guidato, ci si evita anche buona parte dei problemi di usabilità.



Nella realtà questo discorso è ahimè più complesso di così.
Se stai parlando sempre dello sviluppo, è complesso poichè quando assumi un Junior lo devi anche formare in merito alla sicurezza, non puoi aspettarti (tu azienda) che la persona conosca tutte le pratiche ad oggi utilizzate (Auth0 compreso, magari). Purtroppo manca spesse volte la formazione interna, e chi sviluppa viene lasciato nel suo mondo, senza nemmeno una guida con più esperienza.
Non me la sentirei di dare la colpa al personale insomma, non in toto; il personale dovrebbe avere le competenze minime, ma dovrebbe poi essere formato (e se entri da junior la figura che hai sopra deve controllare e correggerti quando sbagli).

Si, indento proprio quello, se fai un programma che fa troppe cose è sia più semplice che qualcosa si rompa sia diventa alle volte scomodo nell'utilizzo di tutti i giorni

 

[nfvblog]

Comunque non si può affermare che le aziende non abbiano le competenza per poter verificare il software che distribuiscono, semplicemente più il tuo software si diffonde più è facile che un buco venga trovato, nulla di più nessuno è perfetto e tutti possiamo fare degli errorini che poi si trasformano in delle vere e proprie valanghe.

 

[haxo]

Guarda, per esperienza quando sviluppi qualcosa è scontato trovare delle vulnerabilità

Naturalmente.
Nel caso di questo topic e delle mie parole, erano riferite in modo generale a scuole che non insegnano nulla riguardo sicurezza.

 

[--- Ra ---]

Ho appena scoperto, con mio grande piacere, che in North Dakota è stata firmata il 24 marzo una nuova legge che inserisce l'insegnamento dell'informatica e della sicurezza informatica nelle scuole elementari, medie e superiori!

Le parole di Kirsten Baesler, sovrintendente scolastico:


Una divisione dello Stato, chiamata EduTech, svilupperà esempi di piani di cybersicurezza e informatica che amministratori e insegnanti potranno utilizzare per assistere le scuole nello sviluppo dei propri piani.

Questa è una bella notizia! Soltanto in North Dakota o anche in altri stati Americani? Speriamo che iniziative di questo tipo vengano adottate presto anche qui in Italia