Pensi attivamente alla sicurezza durante la codifica?

Quando stai codificando, pensi attivamente che il tuo codice possa essere sfruttato in modi in cui inizialmente non era destinato a fare e quindi ottenere l'accesso a informazioni protette, eseguire comandi o qualcos'altro che non vorresti che i tuoi utenti facessero?

Tipo. Disclaimer: sono un ragazzo della sicurezza;)

Quindi il modo in cui lavoro è che ho il mio modello di minaccia, che descrive quale tipo di attacchi da quale tipo di attaccanti sono probabili. Ciò aiuta a elaborare i requisiti di sicurezza. Quando in realtà sto codificando, faccio le solite pratiche di "codifica sicura" come stare attenti che le variabili del cursore siano sempre entro i limiti, l'input contaminato è sanificato, le condizioni di errore sono gestite. Quindi torno al mio modello di minaccia per vedere quali moduli hanno più probabilità di essere presi di mira dagli attaccanti; quelli ottengono qualche recensione extra.

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

In breve, utilizzo le migliori pratiche, ma non sviluppo i miei strumenti di sicurezza. Non sono un esperto di sicurezza al riguardo; Mi affido ad altri esperti di sicurezza, che presumibilmente hanno già riflettuto a fondo su questi problemi e hanno una chiara comprensione dei rischi e dei benefici.

Il mio approccio fondamentale alla sicurezza, oltre al semplice utilizzo degli strumenti di sicurezza, è quello di eliminare tutti i possibili input al sistema, tranne quello che mi aspetto. Se ho un campo numero di previdenza sociale, gli unici caratteri che dovrebbero effettivamente essere 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, questo va due volte.
Proprio l'altro giorno, un utente è riuscito a trovare e sfruttare il bug in uno dei miei vecchi programmi. Il danno era irreparabile. Vedi sotto:

Una volta era rotonda.

No, perché non lavoro in un dominio problematico in cui la sicurezza è rilevante (enorme software di visualizzazione dei dati). Ho fare avere un gruppo di afferma nel mio codice (controllo di indice, il controllo di coerenza, ecc), non a causa di problemi di sicurezza, ma perché mi piace codice errato di crash presto e crash visibilmente.

Assolutamente. Penso alle vulnerabilità legate all'iniezione, e anche al modo in cui la mia logica aziendale funzionerà in un ambiente desktop rispetto a un ambiente Web e in che modo viene implementata la sicurezza in entrambi i tipi di ambienti.

Non sono un esperto di sicurezza, ma quando codifico le applicazioni Web presumo sempre che l'input dell'utente possa contenere qualsiasi tipo di stranezza e che debba sempre essere completamente evaso e simili. Inoltre, sto attento a richiamare Ajax sul server per verificare che l'utente abbia effettuato l'accesso (se dovrebbe essere per quel particolare evento) e che disponga delle autorizzazioni per fare qualunque cosa stia cercando di fare.

La base di codice ha una serie di filtri per gli input. Non controllo mai direttamente PHP $_GETo $_POSTarray. Invece, li interrogo tramite 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 una partita multiplayer, tutti erano paranoici di exploit e modi per imbrogliare. L'imbroglio può distruggere totalmente un gioco, per non parlare dei modelli di business legati alla vendita di oggetti di gioco. Pertanto, i problemi di sicurezza e le misure antimanomissione erano molto importanti all'ordine del giorno. Mi è piaciuto molto. Ho già lavorato su altri progetti in cui dovevi sentirti in colpa per aver lavorato più a lungo sul codice solo per assicurarmi che fosse sicuro.

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

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

Quindi 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 posso convalidare l'origine dati, importa se i dati vengono manomessi, chi è l'origine dati, quanto sono sicuro? come potrebbe essere stato modificato ecc ...

Questo influisce sul design. I file di configurazione possono avere sezioni chiave crittografate o campi particolari potrebbero essere in chiaro con un campo firma associato. Le cose diventano più complesse con i servizi di connessione a Internet in quanto dovresti aspettarti un maggiore livello di ostilità lì.

Quindi al test, come testare tutto questo. Quali sono le tue immissioni massime di dati, cosa succede se spingi il software oltre questi limiti, come lo gestisce? Di cosa si fida? come puoi fingere quella fiducia?

Sì.

In passato ho avuto a che fare con abbastanza hacker da sapere che cercano costantemente di compromettere qualsiasi grande sito e ci sono abbastanza robot là fuori che anche i piccoli siti non sono sicuri.

Ora cerco di pensare come un hacker , al punto che a volte mi preoccupo i miei colleghi con commenti casuali su come i sistemi che diamo per scontati ogni giorno possano essere giocati.

Dovrebbe essere qualcosa che qualsiasi sviluppatore inserisce nel processo da zero in misura maggiore o minore, a seconda dell'applicazione, ecc. Sfortunatamente, poiché gli sviluppatori non tendono a quotare per motivi di sicurezza, gli acquirenti non tendono a pensarci ( Lo so, questo è un po 'catch-22, perché se gli acquirenti vogliono il preventivo più economico, forse non includerà la sicurezza)

Come sviluppatore puoi ottenere un netto vantaggio se sei esperto in questo settore: sto pensando in particolare a banche e servizi finanziari, ma sono applicabili anche altri settori. Attualmente possono stanziare tra 70 e 100.000 in formazione per un nuovo laureato che dovrà essere aggiornato sui processi, sulla sicurezza e su altri aspetti specifici dell'organizzazione. Se riesci a salvarli 30k di quello, è un buon CV in più!

Nel Regno Unito, l' Institute of Information Security Professionals e in Scozia, il Centre of Excellence in Security and Cybercrime stanno collaborando a stretto contatto con le università per aiutare a rivedere i materiali del corso, fornire lezioni per gli ospiti sulle implicazioni del mondo reale della scarsa programmazione e facilitare i collocamenti estivi (ad es. sviluppatori di software collocati in divisioni antifrode nelle forze dell'ordine.) La maggior parte delle organizzazioni di supporto lo fanno gratuitamente, poiché ha il potenziale per risparmiare loro una grande quantità di denaro - mi sembra un valore.

(disclaimer - Sono stato un ragazzo della sicurezza per varie organizzazioni globali)