Cosa dovrebbe sapere ogni programmatore sulla sicurezza? [chiuso]

427

Sono uno studente di informatica e ora sono al terzo anno di università. Fino ad ora abbiamo studiato molti argomenti relativi ai computer in generale (programmazione, algoritmi, architettura informatica, matematica, ecc.).

Sono molto sicuro che nessuno possa imparare tutto sulla sicurezza, ma certo che esiste una conoscenza "minima" che ogni programmatore o studente IT dovrebbe conoscere al riguardo e la mia domanda è: qual è questa conoscenza minima?

Puoi suggerire alcuni e-book o corsi o qualcosa può aiutare a iniziare con questa strada?

security 
— MH
fonte
6
— Thomas,
118
Regola n. 1: mai fidarsi dell'input dell'utente. Nemmeno se è tua nonna
— Anthony Forloney,
2
..e questa discussione ha anche la grande informazione - stackoverflow.com/questions/72394/...
— Sripathi Krishnan
la mia domanda non riguarda solo i programmatori e i loro errori, ma anche gli studenti di informatica e informatica
— Mohamad Alhamoud,
1
Guarda i tuoi messaggi di errore. Sebbene tu voglia essere facile da usare, la differenza tra "Questo account non esiste" e "La password non è valida" può essere pericolosa in alcuni casi.
— Michael Mior,

Risposte:

551

Principi da tenere a mente se si desidera proteggere le applicazioni:

  • Non fidarti mai di alcun input!
  • Convalida l'input da tutte le fonti non attendibili: utilizza whitelist e non blacklist
  • Pianifica la sicurezza dall'inizio: non è qualcosa che puoi attaccare alla fine
  • Mantieni la semplicità: la complessità aumenta la probabilità di falle nella sicurezza
  • Riduci al minimo la superficie di attacco
  • Assicurati di fallire in modo sicuro
  • Usa la difesa in profondità
  • Aderire al principio del privilegio minimo
  • Usa la modellazione delle minacce
  • Compartimentalizza - quindi il tuo sistema non è tutto o niente
  • Nascondere i segreti è difficile e i segreti nascosti nel codice non rimarranno segreti a lungo
  • Non scrivere la tua crittografia
  • L'uso di crypto non significa che sei al sicuro (gli attaccanti cercheranno un collegamento più debole)
  • Prestare attenzione agli overflow del buffer e a come proteggerli

Ci sono alcuni libri e articoli online eccellenti su come rendere sicure le tue applicazioni:

Addestra i tuoi sviluppatori sulle migliori pratiche di sicurezza delle applicazioni

Codebashing (a pagamento)

Security Innovation (a pagamento)

Bussola di sicurezza (a pagamento)

OWASP WebGoat (gratuito)

— bignum
fonte
+1 "sfruttare il software: come rompere il codice" è un ottimo libro, tuttavia quella presentazione a cui sei collegato è orribile.
— torre
7
Tuttavia, sfortunatamente è quasi impossibile istanziare il principio del privilegio minimo in qualsiasi sistema moderno. Ad esempio, il kernel Linux (sorgente che sto attualmente utilizzando) contiene oltre 9,4 milioni di righe di codice C e oltre 400K righe di assembly, tutte eseguite in un contesto senza restrizioni. Un semplice errore di calcolo (forse intenzionale) in una di queste milioni di righe comprometterà l'intero sistema. Forse nel prossimo secolo o due emergerà una soluzione, forse no, poiché a nessuno interessa davvero creare sistemi operativi / lingue / framework sicuri.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Aggiungerei "Il manuale del pirata informatico dell'applicazione Web" a quell'elenco.
— superato
34
Sostituisci "Non fidarti mai dell'input dell'utente!" a "Non fidarti mai di alcun input!". Gli input provenienti da altri software dovrebbero essere trattati allo stesso modo degli input dell'utente - ad esempio, nella registrazione di siti Web la maggior parte delle persone non considererebbe il campo User-Agent / ID browser come "input dell'utente" ma può contenere altrettanto facilmente, per esempio, un SQL Injection.
— Peteris,
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Bene, esiste quel sistema operativo sperimentale di Microsoft Research (Singularity) basato su .NET, che puntava alla sicurezza come obiettivo primario (nessun buffer overflow, yay!). Nessuna condivisione della memoria di processo, nessuna modifica del codice, anche i driver di dispositivo sono solo un altro processo isolato dal software in .NET. Un concetto piuttosto interessante, ma sarebbe molto difficile spingerlo alle persone (cosa più importante, praticamente non può fare retrocompatibilità con software esistenti o persino driver; un po 'come i primi 10 anni di Linux: D).
— Luaan,
102

Regola n. 1 di sicurezza per i programmatori: non fare il tuo

A meno che tu non sia un esperto di sicurezza e / o un crittografo, usa sempre una piattaforma di sicurezza, un framework o una libreria ben progettati, ben collaudati e maturi per fare il lavoro per te. Queste cose hanno passato anni a essere pensate, patchate, aggiornate ed esaminate da esperti e hacker. Volete ottenere quei vantaggi, non scartarli cercando di reinventare la ruota.

Ora, questo non vuol dire che non è necessario imparare nulla sulla sicurezza. Devi sicuramente conoscere abbastanza per capire cosa stai facendo e assicurarti di utilizzare correttamente gli strumenti. Tuttavia, se ti accorgi di iniziare a scrivere il tuo algoritmo di crittografia, il sistema di autenticazione, il disinfettante di input, ecc., Fermati, fai un passo indietro e ricorda la regola n. 1.

— Tyler McHenry
fonte
10
Questa è una brutta regola secondo me. Puoi essenzialmente essere preso di mira solo per la piattaforma selezionata, piuttosto che per qualsiasi interesse reale per le tue risorse. Pensa a tutte le falle di sicurezza che si trovano nelle piattaforme di terze parti e a tutti i prodotti che sono immediatamente vulnerabili solo perché lo usano. Non sarei così veloce nel fidarmi della mia sicurezza a terzi.
— Fosco,
9
Penso che questa sia una buona regola per Crypto: far rotolare la tua crittografia è una ricetta per il disastro. Ma far girare il tuo motore di blog potrebbe essere più sicuro, come sottolinea Fosco: se fai il tuo lancio, avrai meno probabilità di essere sorpreso da attacchi automatici che le installazioni di wordpress devono affrontare.
— James P McGrath,
5
Quando si tratta di criptovaluta, questa regola è assolutamente corretta. Non scrivere la tua crittografia, punto. Quando si tratta di utilizzare piattaforme di terze parti, dipende. Alcune piattaforme sono intrinsecamente più sicure, alcune sono intrinsecamente meno sicure e la maggior parte delle piattaforme probabilmente fornisce alcune funzionalità di sicurezza ma anche alcuni vettori di attacco noti. Accetta la recente vulnerabilità di Rails che ha causato un buco nella sicurezza su github . Indubbiamente Rails offre molte funzioni di sicurezza, ma ha anche alcune potenti funzionalità con impostazioni predefinite non sicure.
— Michael Kopinsky,
7
Quando si tratta di criptovalute, non farne una tua, ma capisci cosa stai usando. Se non capisci perché usare la stessa chiave di crittografia per RC4 per due messaggi sia un'idea orribile, leggi prima di usare qualsiasi codice di flusso, ad esempio.
— Christopher Creutzig,
3
Anche dopo il bug HeartBleed è evidente che questa è una buona regola. Immagina quanto sarebbe stato difficile trovare un bug simile a una heatbleed in un progetto personalizzato o proprietario. Se fai il tuo, ti stai nascondendo dietro l'oscurità e non saprai quali bug potrebbero essere sfruttati.
— Sqeaky
71

Ogni programmatore dovrebbe sapere come scrivere il codice exploit.

Senza sapere come vengono sfruttati i sistemi, si arrestano accidentalmente le vulnerabilità. Sapere come applicare il codice di patch è assolutamente insignificante a meno che non si sappia come testare le patch. La sicurezza non è solo un mucchio di esperimenti mentali, devi essere scientifico e testare i tuoi esperimenti.

— torre
fonte
10
Direi che non è affatto necessario. Aderisci al principio: se l'attaccante può causare un danneggiamento della memoria di qualsiasi tipo, considerati di proprietà. Non c'è bisogno di entrare nei dettagli di scrivere effettivamente exploit (funzionanti).
— newgre,
6
@newgre non tutte le vulnerabilità sono un buffer overflow. Esistono alcune migliaia di vulnerabilità coperte dal sistema di enumerazione di debolezza comune. Un programmatore deve capire la mente dell'attaccante o inconsapevolmente commetterà errori.
— arrosto il
1
So che non tutti sono buffer overflow, ma tutto ciò che viene generalmente definito "exploit" si basa su un tipo di danneggiamento della memoria: overflow del buffer, double frees, heap overflow, overflow relativi a numeri interi, stringhe di formato , ecc. Naturalmente ci sono altre cose come i bug logici, ma questo non era l'argomento di questa risposta per cominciare.
— newgre,
5
@newgre Questo è un tipo di exploit, ma oggi vengono scritti più exploit per sfruttare i difetti delle applicazioni Web rispetto ai problemi di corruzione della memoria. Gli exploit sono scritti sfruttando SQL Injection, Local File include, CSRF e XSS, questi sono i problemi più comuni. (Fonte: exploit-db.com )
— arrosto il
1
Sono d'accordo, se tu stesso puoi scrivere exploit, puoi capire cosa può andare al massimo una mente degli hacker!
— Linuxeasy,
42

La sicurezza è un processo, non un prodotto.

Molti sembrano dimenticare questa ovvia questione di fatto.

— ericteubert
fonte
23

Suggerisco di rivedere CWE / SANS TOP 25 errori di programmazione più pericolosi . È stato aggiornato per il 2010 con la promessa di aggiornamenti regolari in futuro. Il 2009 di revisione è disponibile pure.

Da http://cwe.mitre.org/top25/index.html

I 25 errori di programmazione più pericolosi del CWE / SANS del 2010 sono un elenco degli errori di programmazione più diffusi e critici che possono portare a gravi vulnerabilità del software. Sono spesso facili da trovare e facili da sfruttare. Sono pericolosi perché spesso consentono agli aggressori di assumere completamente il software, rubare dati o impedire al software di funzionare.

L'elenco dei 25 principali è uno strumento di educazione e sensibilizzazione per aiutare i programmatori a prevenire i tipi di vulnerabilità che affliggono l'industria del software, identificando ed evitando errori fin troppo comuni che si verificano prima ancora che il software venga spedito. I clienti del software possono utilizzare lo stesso elenco per aiutarli a richiedere software più sicuro. I ricercatori nella sicurezza del software possono utilizzare la Top 25 per concentrarsi su un sottoinsieme ristretto ma importante di tutti i punti deboli della sicurezza noti. Infine, i gestori di software e i CIO possono utilizzare l'elenco dei 25 principali come misuratore di progressi nei loro sforzi per proteggere il loro software.

— jschmier
fonte
1
Nota che i primi 4 errori in quell'elenco (e anche un gruppo di altri) sono tutti lo stesso errore - input di fiducia.
— Chris Dodd,
13

Un buon corso di partenza potrebbe essere il corso MIT in reti di computer e sicurezza . Una cosa che suggerirei è di non dimenticare la privacy. La privacy, in un certo senso, è davvero fondamentale per la sicurezza e spesso non è coperta da corsi tecnici sulla sicurezza. Potresti trovare materiale sulla privacy in questo corso su Etica e Legge in relazione a Internet.

— tvanfosson
fonte
Il collegamento al corso del MIT non funziona
— AntonioCS il
1
Collegamenti corretti (per ora). Grazie.
— tvanfosson,
10

Il team di Web Security di Mozilla ha messo insieme una grande guida , che ci atteniamo allo sviluppo dei nostri siti e servizi.

— potch
fonte
8

L'importanza delle impostazioni predefinite sicure in framework e API:

  • Molti dei primi framework web non sfuggivano all'html di default nei template e avevano problemi XSS per questo motivo
  • Molti dei primi framework Web hanno semplificato la concatenazione di SQL piuttosto che la creazione di query con parametri che portano a numerosi bug di iniezione SQL.
  • Alcune versioni di Erlang (R13B, forse altre) non verificano i certificati peer ssl per impostazione predefinita e probabilmente ci sono molti codici erlang sensibili agli attacchi SSL MITM
  • Il trasformatore XSLT di Java per impostazione predefinita consente l'esecuzione di codice java arbitrario. Ci sono stati molti gravi bug di sicurezza creati da questo.
  • Le API di analisi XML di Java per impostazione predefinita consentono al documento analizzato di leggere file arbitrari sul filesystem. Più divertimento :)
— benmmurphy
fonte
5

Dovresti conoscere le tre A. Autenticazione, autorizzazione, audit. L'errore classico è quello di autenticare un utente, senza verificare se l'utente è autorizzato a eseguire alcune azioni, quindi un utente può guardare le foto private di altri utenti, l'errore ha fatto Diaspora. Molte, molte più persone dimenticano Audit, è necessario, in un sistema sicuro, essere in grado di dire chi ha fatto cosa e quando.

— rapadura
fonte
1
Non tutte le autorizzazioni richiedono l'autenticazione. "From ABAC to ZBAC" contrasta il controllo degli accessi NBAC (basato sull'autenticazione) con soluzioni che non richiedono l'autenticazione. "IBAC, RBAC, ABAC e persino CBAC - Claims Based Access Control si basano tutti sull'autenticazione ... Per semplicità questo documento li tratta come un'unica soluzione e ignora quelle versioni che hanno implementato aspetti dell'architettura ZBAC. Sono collettivamente denominate autenticazione Based Access Control (NBAC). "
— Mike Samuel,
4
  • Ricorda che tu (il programmatore) devi proteggere tutte le parti, ma l'attaccante deve riuscire a trovare solo un nodo nella tua armatura.
  • La sicurezza è un esempio di "incognite sconosciute". A volte non sai quali sono i possibili difetti di sicurezza (fino a dopo).
  • La differenza tra un bug e una falla di sicurezza dipende dall'intelligenza dell'attaccante.
— Rory
fonte
4

Aggiungerei quanto segue:

  • Come funzionano le firme digitali e i certificati digitali
  • Che cos'è il sandboxing

Comprendi come funzionano i diversi vettori di attacco:

  • Buffer overflow / underflow / etc sul codice nativo
  • Ingegneria sociale
  • Spoofing DNS
  • Uomo nel mezzo
  • CSRF / XSS et al
  • SQL Injection
  • Attacchi crittografici (es: sfruttamento di algoritmi crittografici deboli come DES)
  • Errori di programma / framework (ad es. L' ultimo difetto di sicurezza di github )

Puoi facilmente google per tutto questo. Questo ti darà una buona base. Se vuoi vedere le vulnerabilità delle app web, c'è un progetto chiamato google gruyere che ti mostra come sfruttare un'app web funzionante.

— Miguel Ping
fonte
4

quando stai costruendo una qualsiasi impresa o uno dei tuoi software, dovresti semplicemente pensare come un hacker. Come sappiamo anche gli hacker non sono esperti in tutte le cose, ma quando trovano qualche vulnerabilità iniziano a scavare in esso raccogliendo informazioni su tutto le cose e infine attaccare il nostro software. Quindi per prevenire tali attacchi dovremmo seguire alcune regole ben note come:

  • cerca sempre di infrangere i tuoi codici (usa cheatheets e google le cose per maggiori informazioni).
  • essere aggiornato per difetti di sicurezza nel campo di programmazione.
  • e come accennato in precedenza, non fidarsi mai di alcun tipo di utente o input automatizzati.
  • usano le applicazioni open source (i loro maggiori difetti di sicurezza sono noti e risolti).

puoi trovare più risorse di sicurezza sui seguenti link:

per ulteriori informazioni google sui flussi di sicurezza del fornitore dell'applicazione.

— rahul_pratap
fonte
3
  1. Perché è importante.
  2. Si tratta di compromessi.
  3. La crittografia è in gran parte una distrazione dalla sicurezza.
— Richard
fonte
3

Assicurati anche di consultare la Top 10 di OWASP per una classificazione di tutti i principali vettori / vulnerabilità di attacco.

Queste cose sono affascinanti da leggere. Imparare a pensare come un attaccante ti insegnerà a cosa pensare mentre scrivi il tuo codice.

— Michael Kopinsky
fonte
2

Saltare e hash le password degli utenti. Non salvarli mai in testo normale nel database.

— Abdull
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.