La forma più semplice di codifica sicura

Autore: Peleus Uhley , Principal Scientist & Lead Security Strategist

All'interno del settore della sicurezza, ci imbattiamo spesso in situazioni in cui fornire indicazioni immediate sulla sicurezza non è semplice. Ad esempio, un team potrebbe utilizzare un nuovo linguaggio all'avanguardia che non dispone di molti strumenti di sicurezza o linee guida esistenti disponibili. Se sei una piccola startup, potresti non avere il budget per le soluzioni di sicurezza aziendale. Nelle grandi organizzazioni, il processo di migrazione di un team appena acquisito negli strumenti e nei corsi di formazione esistenti può richiedere diverse settimane. Che consiglio possiamo dare a quei team per portarli sulla strada della sicurezza oggi?

In queste situazioni, ricordo loro di tornare alla loro formazione originale per sviluppatori. Molti sviluppatori hanno familiarità con il termine "debito tecnico", che si riferisce alle "eventuali conseguenze di una cattiva progettazione del sistema, architettura software o sviluppo software all'interno di una base di codice". L'indebitamento tecnico è una componente dell'indebitamento tecnico complessivo di un'applicazione. Maggiore è il debito tecnico per un'applicazione, maggiore è la possibilità di problemi di sicurezza. Inoltre, è molto più facile integrare strumenti e tecniche di sicurezza nel codice sviluppato con processi solidi.

In una certa misura, l'industria lo sapeva da tempo. Agli sviluppatori piacciono le istruzioni preparate perché il codice precompilato viene eseguito più velocemente e agli addetti alla sicurezza piace perché il codice precompilato è meno iniettabile. Gli sviluppatori desiderano la gestione delle eccezioni perché rende l'applicazione Web più stabile e possono indirizzare in modo pulito gli utenti a una pagina di supporto che offre un'esperienza utente migliore. Gli addetti alla sicurezza desiderano la gestione delle eccezioni in modo che ci sia un piano per l'input dannoso e perché mostrare la traccia dello stack è una perdita di informazioni. Tuttavia, facciamo un ulteriore passo avanti.

Se cerchi sul Web elenchi di "Top 10" per le migliori pratiche degli sviluppatori e/o errori di codifica comuni, vedrai che c'è una chiara sovrapposizione nei principi di codifica tradizionali e nei principi di sicurezza in tutte le lingue. Posso esaminare praticamente qualsiasi elenco e giustificare molti dei loro punti utilizzando concetti di sicurezza. Ecco solo alcuni dei loro consigli e come si relazionano alla sicurezza:

• Utilizza un processo di compilazione con strumenti per verificare la presenza di errori e ridurre a icona i file. Per quanto riguarda la sicurezza, stabilire ciò ti consentirà di integrare più facilmente gli strumenti di sicurezza nel processo di compilazione.
• Usa sempre un doctype basato su standard per evitare la modalità Quirks. La modalità Quirks semplifica l'iniezione di vulnerabilità XSS nel tuo sito.
• Un tag JavaScript inline vuoto nel markup HTML. In termini di sicurezza, evitare JavaScript inline semplifica il supporto dei criteri di sicurezza dei contenuti.

• Errore comune n. 1–3: inserire troppa logica nel controller/vista/modello. Questi tre punti si occupano tutti di mantenere il codice progettato in modo pulito per una migliore manutenibilità. La sicurezza è un motivo comune per eseguire la manutenzione del codice. Spesso, la tua risposta agli attacchi attivi contro il tuo sistema sarà rallentata perché il codice non può essere modificato facilmente o è troppo complesso per identificare un singolo punto di convalida.

• Errore comune n. 5: usare troppe gemme. Il controllo delle librerie di terze parti aiuta anche a limitare la superficie di attacco e a ridurre i costi di manutenzione per mantenerle aggiornate per le vulnerabilità della sicurezza.
• Errore comune n. 7: mancanza di test automatizzati. Come menzionato negli elenchi HTML, l'utilizzo di un framework di test automatizzato consente di includere anche i test di sicurezza. Questo blog fa riferimento all'uso di tecniche come BDD per le quali esistono anche framework di sicurezza BDD basati su Ruby come .
• Errore comune n. 10: controllo di informazioni riservate nei repository del codice sorgente. Questa è chiaramente una regola di sicurezza. In questo esempio, si riferiscono a un problema specifico con i token segreti Rails. Tuttavia, questo è un errore comune per lo sviluppo in generale. Separare le credenziali dal codice è semplicemente una buona igiene della codifica: può prevenire una perdita involontaria delle credenziali e consentire una rotazione delle credenziali senza dover ricostruire l'applicazione.

• Usa sempre MVC. Questo è stato menzionato anche nella Top 10 di Rails. Lo sviluppo centralizzato consente la convalida centralizzata.
• Non reinventare la ruota. Questo vale anche per la sicurezza. Ad esempio, non inventare la tua ruota della libreria di crittografia!
• Applica unit test automatizzati e test harness a ogni livello. Anche in questo caso, sarà più facile includere i test di sicurezza.
• Sviluppare secondo le specifiche, non il server delle applicazioni. Questo punto evidenzia l'importanza di non bloccare il codice in una versione specifica del server. Uno dei problemi più frequenti con cui le grandi aziende devono lottare è la migrazione da piattaforme più vecchie e vulnerabili, perché il codice dipende troppo dal vecchio ambiente. Questo concetto è anche correlato al n. 16 nel loro elenco, "Pianificare gli aggiornamenti delle versioni".
• Pianifica l'utilizzo della sicurezza Java EE dal primo giorno. L'idea qui è simile a "Non reinventare la ruota". La maggior parte delle piattaforme di sviluppo fornisce framework di sicurezza già testati e pronti per l'uso.

È vero che la formazione specifica sulla sicurezza sarà sempre necessaria per argomenti come l'autenticazione, l'autorizzazione, la crittografia, ecc. E la formazione sulla sicurezza ti mostra sicuramente come pensare al tuo codice in modo difensivo, il che aiuterà con gli errori della logica dell'applicazione. Tuttavia, molti dei bug e dei problemi di sicurezza di basso livello possono essere rilevati seguendo le buone pratiche di codifica vecchio stile di base. Più puoi controllare il tuo debito tecnico complessivo, più controllerai il tuo debito di sicurezza.