Pensi attivamente alla sicurezza durante la codifica?

Kindof. Disclaimer: I'm a security guy;)

Quindi il modo in cui lavoro è che ho il mio modello di minaccia, che descrive il tipo di attacchi da che tipo di aggressori sono probabili. Questo aiuta a capire i requisiti di sicurezza. Quando in realtà sto codificando, faccio le solite pratiche di "codifica sicura", ad esempio facendo attenzione che le variabili del cursore siano sempre entro i limiti, l'input contaminato è disinfettato, le condizioni di errore vengono gestite. Quindi torno al mio modello di minaccia per vedere quali moduli sono più suscettibili di essere presi di mira dagli aggressori; quelli ottengono qualche recensione in più.

Uso le pratiche standard del settore, come l'utilizzo dei parametri SQL. Utilizzo piattaforme "sicure", come .NET Framework, e sfrutta le funzionalità di sicurezza come i token anti-contraffazione in ASP.NET MVC. Non scrivo i miei algoritmi di crittografia, ma capisco che cosa tali crittografie forniscono in termini di vantaggi per la sicurezza e quando ho bisogno di usarli per ottenere tali benefici di sicurezza.

In breve, utilizzo le best practice, ma non sviluppo i miei strumenti di sicurezza. Non sono un esperto di sicurezza in questo senso; Mi baso su altri esperti di sicurezza, che presumibilmente hanno già riflettuto a fondo su questi temi e hanno una chiara comprensione dei rischi e dei benefici.

Il mio approccio fondamentale alla sicurezza, oltre al semplice utilizzo di strumenti di sicurezza, consiste nell'eliminare tutti gli input possibili per il sistema tranne quello che mi aspetto. Se si dispone di un campo con numero di previdenza sociale, gli unici caratteri che dovrebbero essere effettivamente visualizzati sono cifre e trattini numerici, in uno schema specifico.

Convalido l'input dell'utente sia sul client che sul server.

Assolutamente.

La sicurezza è tutto. E con software numerico, che va due volte.
Proprio l'altro giorno, un utente è riuscito a trovare e sfruttare l'errore in uno dei miei vecchi programmi. Il danno era irreparabile. Vedi sotto:

Un tempo era rotondo.

No, perché non lavoro in un dominio problematico in cui la sicurezza è rilevante (massivo SW di visualizzazione dei dati). Io faccio ho un sacco di affermazioni nel mio codice (controllo dell'indice, controllo di coerenza, ecc.), Non a causa di problemi di sicurezza, ma perché mi piace il codice sbagliato per bloccarmi presto e andare in crash in modo visibile.

Assolutamente. Penso alle vulnerabilità di iniezione e anche a come la mia logica di business funzionerà in un ambiente desktop rispetto a un ambiente web e in che modo la sicurezza viene implementata in entrambi i tipi di ambienti.

Non sono un esperto di sicurezza, ma quando codifico applicazioni web presumo sempre che l'input dell'utente possa contenere ogni sorta di stranezza e dovrebbe sempre essere completamente sfuggito e simile. Inoltre, sto attento a fare chiamate Ajax al server per verificare che l'utente abbia effettuato l'accesso (se dovrebbe essere per quel particolare evento) e che abbiano i permessi per fare qualunque cosa stiano tentando di fare.

Il codebase ha un set di filtri per gli input. Non controllo mai direttamente gli array $_GET o $_POST di PHP. Invece, li interroga attraverso una funzione Request::get('parameter', 'filter') con filtri come int , text e pochi altri. (E Request::post() per gli input POST, ovviamente.)

Sì. Quando lavoravo a un gioco multiplayer, tutti erano paranoici di exploit e modi per imbrogliare. L'inganno può distruggere completamente un gioco, per non parlare di modelli di business legati alla vendita di materiale di gioco. Quindi i problemi di sicurezza e le misure anti-manomissione erano molto in cima all'agenda. Mi è piaciuto molto. Ho lavorato su altri progetti prima di dove dovevi sentirti in colpa per aver lavorato più a lungo sul codice solo per assicurarti che fosse sicuro.

Sì. La sicurezza è importante e non dovrebbe essere un ripensamento; aggiungere sicurezza dopo che il fatto è generalmente più difficile che progettarlo inizialmente nell'applicazione, e se lo aggiungi in seguito probabilmente ti mancherai un po 'di cose (o semplicemente non ti preoccuperai di aggiungerlo).

Comprendi i principi generali di sicurezza (integrità, autenticazione, autorizzazione) e poi leggi alcuni libri su come le persone hanno sovvertito questi pilastri della sicurezza per millenni e sarai a metà strada.

Poi leggi alcuni buoni libri sulle strategie di progettazione e test e imparerai come progettare la testabilità nella tua architettura.

Ora arriviamo al punto in cui penso alla sicurezza. Sto pensando a come convalidare la fonte dei dati, importa se i dati sono manomessi, chi è la fonte dei dati, quanto sono sicuro di ciò? come potrebbe essere stato modificato ecc ...

Ciò influenza il design. I file di configurazione possono avere sezioni chiave crittografate, o particolari campi potrebbero essere in chiaro con un campo firma associato. Le cose si fanno più complesse con i servizi di internet in quanto dovresti aspettarti un maggiore livello di ostilità.

Poi alla prova, come testate tutto questo. Quali sono i tuoi dati massimi, cosa succede se spingi il software oltre questi limiti, come lo gestisce? Di cosa si fida? come puoi fingere questa fiducia?

Sì.

In passato ho avuto a che fare con un numero sufficiente di hacker per sapere che cercano costantemente di compromettere qualsiasi sito grande, e ci sono abbastanza bot là fuori che persino i piccoli siti non sono sicuri.

Cerco di pensare come un hacker tutto il tempo ora, al punto in cui a volte mi preoccupo dei miei colleghi con commenti casuali su come i sistemi che diamo per scontato ogni giorno possano essere giocati.

Dovrebbe essere qualcosa che qualsiasi sviluppatore si integra nel processo da zero a un livello maggiore o minore, a seconda dell'applicazione ecc. Sfortunatamente, poiché gli sviluppatori non tendono a quotare per sicurezza, gli acquirenti non tendono a pensare (lo so, questo è un po 'catch-22, perché se gli acquirenti vogliono la citazione più economica, forse non includerà la sicurezza)

Come sviluppatore puoi ottenere un netto vantaggio se sei esperto in questo settore - sto pensando specificamente alle banche e ai servizi finanziari, ma anche altri settori sono applicabili. Attualmente possono prevedere 70 - 100k di formazione per un neolaureato per essere aggiornati su processi, sicurezza e altri aspetti specifici di tale organizzazione. Se puoi salvarli 30k, è un buon CV plus!

Nel Regno Unito, i Professionisti dell'Istituto di sicurezza delle informazioni , e in Scozia, il Centro di eccellenza in sicurezza e cibercriminalità lavorano a stretto contatto con le università per aiutare a rivedere i materiali del corso, fornire lezioni agli ospiti sulle implicazioni del mondo reale della codifica scadente e facilitare i posizionamenti estivi (ad esempio, gli sviluppatori di software collocati nelle divisioni antifrode nelle forze dell'ordine.) La maggior parte delle organizzazioni di supporto lo fanno gratuitamente, poiché ha il potenziale per salvarle una grande quantità di denaro - mi sembra un valore.

(disclaimer - Sono stato addetto alla sicurezza per varie organizzazioni globali)