Insegnare a una persona amata le pratiche di codifica sicure

Direi che un ottimo modo per imparare è che lei rompa le applicazioni che ha già scritto.

Supponendo che lei stia scrivendo applicazioni web, la indichi verso la Top 10 di OWASP. Falle vedere se riesce a trovare uno di questi difetti nel suo codice. Non c'è modo migliore per conoscere i concetti di sicurezza che vederli realmente sul proprio codice.

Una volta individuato un difetto, farla riscrivere dall'applicazione per correggere l'errore. In questo modo le permetterà di apprezzare l'effetto di cose come l'igiene e la convalida degli input dell'utente e delle query parametrizzate.

Prendi passi incrementali. Non vorrei passare direttamente alla progettazione di una nuova applicazione con la sicurezza in mente prima di capire veramente quale tipo di codici causano difetti di sicurezza.

Prenderò la posizione che potrebbe farmi flambare ...

Il problema che vedo è che la programmazione sicura viene insegnata come aggiunta. Le migliori pratiche dovrebbero essere insegnate fin dall'inizio (inclusa la sicurezza). La bugia viene insegnata è che la pratica rende prefetto. La verità è che la pratica diventa permanente. Quindi se stai sbagliando, devi disimparare ciò che hai imparato. Questo è un approccio bassackwards.

Direi che le pratiche di codifica sicure dovrebbero essere insegnate fin dal primo giorno. Non c'è motivo di imparare come farlo, e quindi imparare come farlo in modo sicuro. È uno spreco di tempo e denaro ...

I miei 2 bit, 1 e zero altro da dire ...

Mentre sono d'accordo in linea di principio con Everett, c'è un altro punto di vista. Il punto di una lezione è di apprendere un concetto, che può quindi essere ulteriormente sviluppato. Questo riduce la pendenza della curva di apprendimento. Insegnare troppo troppo velocemente è travolgente; di fronte ad un assalto di informazioni, la maggior parte dei cervelli "perde".

È bello dire che "le pratiche di codifica sicure dovrebbero essere insegnate fin dal primo giorno", e molto difficile dimostrare come quel programma "Hello World" possa essere vulnerabile, specialmente quando "cos'è un programma per computer" è un nuovo concetto per la classe. Un progetto di sito Web che tocca archivi di dati condivisi (che non ho visto fino a metà dell'università) è più facile da mostrare punti deboli, ma spesso queste debolezze sono inerenti alla creazione di un ambiente web di proof-of-concept di base con il " impostazioni predefinite. È molto facile dimostrare che un'applicazione presenta delle vulnerabilità, quando le vulnerabilità sono note. È più difficile (impossibile, davvero) provare che nessuno esiste.

Penso in modo simile all'OP; ad un certo punto nello sviluppo di un programmatore, l'idea di "come qualcuno potrebbe usare questo codice per fare cose che non vuoi che facciano, e come puoi prevenirlo" può essere unito a quello che stai facendo. Il punto di partenza è probabilmente da qualche parte in giro per imparare sia sulla comunicazione esterna o persistenza (lettura / scrittura di dati su un disco rigido o database, o l'invio attraverso un canale di rete), o i principi orientati agli oggetti (ereditarietà, sovraccarico / override, ecc.), qualunque cosa avvenga prima. È qui che un programmatore può iniziare a scrivere programmi che hanno il potere di fare danni nelle mani sbagliate, e quindi bisogna fare attenzione a garantire che le mani sbagliate non siano in grado di usare male il programma.

Alcuni concetti sono facili da comprendere; "Il mio programma funziona con i dati che sono un segreto dei suoi utenti, mi fido di esso e devo garantire che solo quelli che dovrebbero vedere i dati siano autorizzati a farlo". Alcuni sono più difficili; Ho visto persone che sono sinceramente scioccate nello scoprire che i binari del programma possono essere decompilati e letti per scoprire credenziali o chiavi codificate (e che alcuni ambienti come .NET mettono abbastanza metadati nei binari per produrre quasi esattamente lo stesso codice sorgente usato per costruire loro), o che il loro binario assemblato può essere trasportato su una forma compilata da un utente malintenzionato che si collega usando classi o membri pubblici non sigillati e quindi ha accesso a tutti i segreti con cui lavorano le classi. Questi sono i trucchi di base che dovrebbero essere illustrati, e quindi dovrebbero essere illustrate le soluzioni per loro e come e perché funzionano spiegati.

Proprio come gli altri aspetti di una vera educazione (forse questo dovrebbe essere più su Parenting.SE ...), penso che ritorni al pensiero critico .

Mia figlia sta anche frequentando alcuni corsi CS universitari e sto aiutandola a lavorare con loro. Tuttavia, non le ho dato le informazioni, lei ha bisogno di lavorare per questo.
In molti casi, le spiego qualcosa di molto sbagliato e mi aspetto che lei mi chiami. (Lei di solito lo fa). A volte, è solo leggermente sbagliato, e quindi è più difficile per lei notarlo. A volte lei non se ne accorge subito e inizia a costruire qualcosa basandosi su un'ipotesi sbagliata - quindi deve lavorare all'indietro per trovare il problema. (Anche lei sta migliorando.)

In questo modo, la costringo ad abituarmi a mettere in discussione le ipotesi.
Non è per niente entusiasta dei miei metodi.

Allo stesso modo, le chiedo di individuare in qualsiasi modo che il suo codice possa essere utilizzato impropriamente, accidentalmente o maliziosamente. Le ho spiegato che Lei possiede il suo codice ed è responsabile di ciò che il suo codice , non c'è spazio per la passività qui. Parte di questo è la corretta gestione delle eccezioni, che i suoi istruttori si aspettano che facciano comunque, anche senza approfondire la questione fino a molto più tardi.

Ora, naturalmente, mi oppongo a tutte le forme di insegnamento "programmazione settoriale dei carichi" - a meno che non sia esplicitamente indicato come tale , per consentire l'apprendimento dei concetti di base, con l'avvertenza che è non tutta la storia e torneremo su questo più tardi. (Come la precedente gestione delle eccezioni).

Il mio punto di tutto questo è che "programmazione sicura" non è diverso da "programmazione" .
Tuttavia, proprio come l'intero Libro della Programmazione non può essere insegnato in una sola seduta tutto in una volta, ma i concetti vengono introdotti gradualmente - gli aspetti "di sicurezza" dei concetti di programmazione potrebbero aspettare, mentre il concetto di base viene insegnato e compreso, con l'esplicito nota che "non abbiamo ancora finito qui". Anche l'aspettativa che almeno gli studenti migliori avrebbero capito alcuni degli aspetti insicuri.

TL; DR :

1. Un nuovo concetto di programmazione deve essere appreso gradualmente, alcuni aspetti (inclusa la sicurezza) possono essere insegnati più tardi rispetto ad altri;
2. Detto concetto di programmazione è non completo fino a quando tutti gli aspetti sono appresi e compresi, compresi gli aspetti di sicurezza (e dovrebbe essere notato fino ad allora);
3. I programmatori hanno un controllo completo sul loro codice e per essere un programmatore bisogna sapere come si può abusare del proprio codice;
4. Gli studenti che praticano il pensiero critico dovrebbero pensarlo da soli (non necessariamente tutti di sicurezza, ma il contesto mancante e buona parte del cattivo uso del codice);
5. Gli studenti che non praticano il pensiero critico non dovrebbero davvero imparare a programmare ...

Penso che alla fine si debba cercare di capire a che punto l'educazione alla sicurezza non offusca il punto della lezione. Gli incarichi di lezione sono in genere problemi semplificati progettati per esporre un particolare problema e mostrano come risolvere quel particolare problema.

Penso che il modo più ideale per affrontarlo sia iniziare a fare qualcosa come hackthissite.org per scoprire quanti attacchi funzionano e quali sono i pericoli. Avere un sano apprezzamento su come il codice può essere sovvertito è un ottimo modo per aiutare qualcuno a capire l'importanza delle pratiche di codifica sicure. Facendolo in parallelo significa che non offuscherà gli argomenti che i suoi istruttori stanno cercando di ottenere e mostrerà anche quali sono i problemi di sicurezza.

Dal mio punto di vista, come analista di sistemi, c'è un modo: dovresti insegnare ai primi un concetto di standardizzazione, classificazione e corrispondenza dei modelli. Le seguenti domande sono facili e potrebbero essere portate all'inizio ...

• Pensa a "tutti i possibili dati immessi", che l'utente può inserire e crea un elenco rigoroso di essi.
• Impara / insegni espressioni regolari. Questo strumento può essere utilizzato per la corrispondenza e la disinfezione.
• Principio di "valori predefiniti", se i dati di input sono mancanti o non validi.
• Utilizza i file di registro. In caso di dubbi o incongruenze di input, il software dovrebbe utilizzare una sorta di registrazione per "scriverlo". I file di registro sono uno dei modi migliori per eseguire il debug e scoprire i buchi di sicurezza, che qualcuno potrebbe utilizzare o sta già utilizzando.
• Utilizza i messaggi di errore e i casi di errore. Pensa ai casi in cui il sistema potrebbe fallire e pensa al numero di errore appropriato e al messaggio dettagliato. Alcuni errori potrebbero portare a due diversi messaggi di errore dettagliati: uno per l'utente, semplice e semplice, uno per il proprietario del sistema, a scopo di debug o di sicurezza.

L'utente è sempre "cattivo", l'utente vuole sempre rompere il tuo software - non dare mai all'utente più informazioni di quelle che chiede, e se lo chiede, controlla sempre, se è privato di ricevere anche una risposta di semplice "Non hai accesso" - i messaggi di errore possono aiutare gli hacker a capire lo stato del sistema, sta cercando di rompere.

Potrebbe pensare di più, ma questo può e dovrebbe essere insegnato fin dall'inizio.