secure coding guidelines
Questo tutorial spiega la codifica sicura, come evitare le vulnerabilità legate alla sicurezza e fornisce le linee guida per la codifica e l'elenco di controllo per le pratiche di codifica sicure:
Per avere la sicurezza integrata nel software e implementare le linee guida e le best practice per la codifica sicura, l'intera organizzazione insieme al team identificato per lavorare sullo sviluppo dell'applicazione previsto deve considerare alcuni aspetti.
Qui, discuteremo quegli aspetti che aiutano a sviluppare un software protetto.
È così semplice se uno sviluppatore non sa cosa si intende con 'Sicurezza per il software' e come un hacker può hackerare il proprio software, prenderne il controllo e provare a sfruttarlo, è semplicemente impossibile codificare un software sicuro. Quindi, lo sviluppatore deve prima capire il significato di Secure Coding.
Cosa imparerai:
- Cos'è la codifica sicura?
- Linee guida per la codifica sicura
- Elenco di controllo per pratiche di codice sicuro
- Conclusione
Cos'è la codifica sicura?
La codifica sicura consiste nel progettare e sviluppare software tramite evitando le debolezze che portano a vulnerabilità relative alla sicurezza aderendo agli standard di sicurezza specificati e alle migliori pratiche del settore.
La prima vera domanda che sorge nella mente di tutti è 'Quanta sicurezza è richiesta per il nostro software' o Quando possiamo dire che il nostro software è protetto? e Quali sono questi standard di sicurezza ?
Frodi e minacce alla sicurezza aumentano di giorno in giorno e stiamo assistendo a nuove varietà e modalità di hacking, anche nel cosiddetto software più protetto.
Recentemente abbiamo sentito che il programma Aaadhar dell'UIDAI è stato manomesso per i dati personali. Quindi è davvero difficile sapere quanta sicurezza è richiesta per il software e quali sono gli standard di sicurezza a meno che non comprendiamo le minacce coinvolte nel software e diamo loro la priorità in base ai rischi per l'azienda.
Potrebbe essere difficile fornire una protezione di sicurezza al 100% al software, ma se il team del programma analizza il file Rischi e titoli che sono coinvolti nel loro software, ad esempio potenziali minacce e se il team può prendersi cura di mitigare tali rischi, allora sarebbe un bene dal punto di sicurezza dell'applicazione.
Pertanto, il primo compito del team è identificare e analizzare i rischi e i titoli coinvolti nella loro applicazione, comprendere le possibili opzioni di mitigazione e adottare di conseguenza l'opzione migliore.
Quindi, una volta identificate, le prime dieci vulnerabilità classificano quasi tutti gli attacchi che è probabile che un programma debba affrontare. Ciò contribuirà a dare un senso alle minacce ea dare la priorità agli sforzi di sicurezza e sviluppo più verso la prevenzione che la mitigazione.
Per esempio. Sebbene stiamo progettando di sviluppare un'app correlata alla salute, che gestisca e memorizzi i dati sanitari dell'individuo e le sue informazioni personali, il principale rischio per la sicurezza dell'applicazione è il furto dei dati sanitari personali.
Mitigazione del rischio
Per mitigare il rischio,
- L'implementazione della sicurezza per l'accesso ai dati da parte di un utente non autorizzato deve essere gestita con un'autenticazione e un'autorizzazione adeguate (implementazioni di criteri per password complesse, autenticazione a 2 fattori).
- È necessario prestare attenzione per garantire che non vi siano perdite di dati durante la trasmissione di dati da una fonte a un'altra fonte implementando canali protetti (HTTPS) di trasmissione dati e implementando la crittografia dei dati durante il transito.
- Un'altra possibilità è la manomissione o il furto dei dati inattivi. Pertanto, l'archiviazione dei dati sanitari personali (utilizzando la crittografia) è molto essenziale.
Prima di passare allo 'Standard di codifica sicura', è sempre meglio che l'intero team del programma disponga di un file 'Sessione di sensibilizzazione alla sicurezza' e discuti e fai un brainstorming su,
- Il requisito di sicurezza per il loro prodotto specifico.
- Possibili vantaggi che un hacker avrebbe hackerando il proprio sistema.
- Possibili modi e mezzi per compromettere la sicurezza della loro applicazione.
- Pratiche di sicurezza comuni seguite in un settore e dominio simili.
- Comprensione dei problemi di sicurezza tipici dei rispettivi programmi.
Aiuta anche la squadra a gestire meglio, se riesce a capire il file Fonti delle vulnerabilità che il loro software può affrontare e le ragioni per cui il software è costruito Povero / inadeguato Sicurezza .
Motivi per un'implementazione della sicurezza inadeguata
In generale, i seguenti sono alcuni motivi per un'implementazione della protezione inadeguata nell'applicazione.
- La priorità è data per il rilascio funzionale rispetto agli aspetti di sicurezza.
- Ignoranza o nessuna consapevolezza riguardo alla sicurezza del software e agli hacker.
- Poca chiarezza sul Programma o sul Software Design stesso.
- La complessità del programma.
- Dati insufficienti, informazioni sul sistema live in cui verrà distribuito.
- Nessuna considerazione della sicurezza nelle fasi SDLC.
- Conoscenza e comprensione insufficienti delle specifiche della lingua utilizzata nel software.
- Conoscenza insufficiente per il team e gli sviluppatori sulle linee guida per la codifica di sicurezza.
Sappiamo che non è che tutti gli sviluppatori e i tester siano consapevoli della sicurezza di un'applicazione e potrebbero non avere una conoscenza approfondita delle vulnerabilità e degli exploit della sicurezza, specialmente per l'applicazione su cui lavorerebbero. In generale, avranno familiarità con, 'Come codificare in modo funzionale' ma non tutti sanno 'Come codificare in modo sicuro'.
Quindi l'aspetto molto importante per l'organizzazione di adottare pratiche di codifica sicura nel proprio software è innanzitutto 'Train People' . Pertanto, la formazione del proprio team sugli aspetti della codifica sicura, sulle migliori pratiche di codifica della sicurezza e sull'utilizzo dello strumento corretto è molto importante.
Il principio di progettazione più importante della sicurezza del software è 'Implementa la sicurezza per progettazione e impostazione predefinita' .
Linee guida per la codifica sicura
Per ottenere la sicurezza, è molto essenziale disporre di un file 'Standard di codifica sicura' identificato per un programma all'inizio dello sviluppo dell'applicazione, e questo aiuta il team a prendersi cura dei Secure Default per il software e aiuta a proteggerlo dagli attacchi.
È essenziale assicurarsi che l'intera squadra lo sia Costruito per aderire a questo standard , indipendentemente dal linguaggio di codifica e dagli strumenti che stanno utilizzando nel programma.
Di seguito sono riportati alcuni esempi che devono essere implementati per impostazione predefinita nella progettazione del codice sicuro:
- L'accesso dovrebbe essere limitato solo agli utenti autenticati e l'autenticazione deve essere implementata a ogni livello.
- I canali di comunicazione devono essere crittografati per proteggere i token di autenticazione.
- Tutte le chiavi, password e certificati devono essere adeguatamente archiviati e protetti.
- È necessario implementare la crittografia dei file, la crittografia del database e la crittografia degli elementi dati.
Selezione della lingua per la codifica sicura
La selezione della lingua per la codifica potrebbe non dipendere dalla codifica sicura. Non c'è niente di specifico come linguaggio protetto o non protetto per la codifica per creare un software protetto.
È proprio il modo in cui utilizziamo un linguaggio di programmazione per costruire il software e quanta conoscenza approfondita ha lo sviluppatore sul linguaggio di codifica nell'implementazione degli aspetti di sicurezza.
Tuttavia, è chiarito che, però Gli standard di codifica sicura sono indipendenti dalla selezione della lingua, le best practice per il codice sicuro dipendono dalla lingua, dalla piattaforma e dall'implementazione .
Pertanto, per disporre di un codice sicuro, è essenziale che lo sviluppatore abbia una conoscenza approfondita del linguaggio utilizzato nel programma, in modo che le migliori pratiche di sicurezza possano essere implementate facilmente.
Esempio:
- La probabilità di una vulnerabilità di overflow del buffer varia da linguaggio a linguaggio, ma C, C ++ e Assembly sono considerati i più suscettibili a causa delle loro capacità di gestione della memoria obsolete. Diverse funzioni C lib standard, come strcpy () e memcpy (), sono vulnerabili agli attacchi di buffer overflow. L'utilizzo errato di queste funzioni, copiando un buffer di origine che è troppo grande per essere contenuto nel buffer di destinazione, provoca un overflow del buffer.
- Il problema comune nelle applicazioni Web basate su Java è la possibile perdita di risorse che può verificarsi a causa di risorse di sistema aperte, come file, socket e connessioni di database.
Il prossimo aspetto della sicurezza riguarda il strumenti da utilizzare nel programma applicativo per ottimizzare la sicurezza, utilizzando strumenti come Ambienti di sviluppo integrati saranno molto utili in quanto forniscono molto Avvisi agli utenti e attirare l'attenzione su tali avvisi per cercare di migliorare la qualità del software.
- L'integrazione di librerie / plug-in commerciali o open source come Eclipse, Spring Tool Suite, RAD con IDE aiuta gli sviluppatori a scrivere codice sicuro rilevando e identificando il codice potenzialmente vulnerabile e fornisce avvisi sui risultati relativi all'esecuzione di file dannosi, fuga di informazioni e gestione impropria degli errori.
È anche essenziale utilizzare l'estensione Analizzatori statici e dinamici per migliorare gli aspetti di sicurezza del software. In generale, gli analizzatori statici sono ottimizzati per tipi specifici di errore, quindi finiscono per trovare un gran numero di falsi positivi mentre identificano errori specifici. A volte ci sono possibilità che perdano anche gli errori effettivi.
Quindi si consiglia di utilizzare più analizzatori statici per ottenere una migliore copertura di diversi tipi di errori ed evitare molti falsi positivi. A volte, si consiglia anche di eseguire test manuale per eliminare i falsi positivi .
Regole e raccomandazioni per la codifica sicura
Sarà utile per il programma definire una serie di file 'Regole e consigli per la codifica sicura' a cui il codice sorgente può essere valutato per la conformità in modo che i tester possano eseguire il 'Test di conformità della conformità' per ciascuno di questi standard di codifica sicura.
Quindi il codice di sicurezza può essere certificato come conforme o non conforme utilizzando tali regole rispetto al benchmark impostato.
Alcune delle regole menzionate di seguito possono essere utilizzate per verificare la presenza di violazioni della sicurezza:
- I file devono essere chiusi quando non sono più necessari.
- Ogni volta che si passa una struttura attraverso un confine, è necessario evitare la fuga di informazioni.
- Gli oggetti devono essere dichiarati con una durata di archiviazione appropriata.
Pertanto, i casi di test per verificare queste regole devono essere progettati ed eseguiti per verificare la conformità della conformità. È stato inoltre rilevato che la maggior parte delle vulnerabilità sono causate da tipici errori di programmazione comuni.
Quindi, lo sviluppatore deve capire 'Metodo di codifica non sicuro' , mentre apprendono anche le migliori pratiche di Secure Coding. È ideale per raccogliere gli errori di programmazione più comuni che contribuiscono alle vulnerabilità di sicurezza della loro applicazione in modo che possano essere risolti durante la codifica.
come eseguire un file swf
Questi tipici errori di programmazione derivano principalmente da buffer overflow, cross-site scripting e difetti di injection.
Alcune delle tipiche vulnerabilità di programmazione includono,
- SQL Injection (neutralizzazione impropria di elementi speciali utilizzati in un comando SQL).
- Overflow di numeri interi.
- Buffer overflow (copia buffer senza controllo delle dimensioni dell'input).
- Stringa di formato non controllata.
- Autenticazione e autorizzazione mancanti (autorizzazione errata).
- Esposizione a dati sensibili.
- Gestione impropria degli errori.
Alcuni di questi errori possono causare il crash del sistema, l'accesso imprevisto al sistema e la perdita del controllo del software a causa degli hacker.
Errori di programmazione comuni da evitare
Di seguito sono elencati alcuni errori di programmazione comuni che devono essere evitati:
- Neutralizzazione impropria di elementi speciali utilizzati in un comando SQL ('SQL Injection').
- Copia nel buffer senza controllare la dimensione dell'input ('Overflow del buffer classico').
- Autenticazione mancante per la funzione critica.
- Autorizzazione mancante o errata.
- Utilizzo di credenziali hardcoded.
- Crittografia mancante dei dati sensibili.
- Caricamento illimitato di file con tipo pericoloso.
- Affidamento a input non attendibili in una decisione sulla sicurezza.
- Esecuzione con privilegi non necessari.
- Cross-Site Request Forgery (CSRF).
- Download del codice senza verifica dell'integrità.
- Calcolo errato della dimensione del buffer.
- Limitazione impropria di tentativi di autenticazione eccessivi.
- Reindirizzamento URL a un sito non attendibile ('Reindirizzamento aperto').
- Stringa di formato non controllata.
- Uso di un hash unidirezionale senza sale.
Elenco di controllo per pratiche di codice sicuro
Ultimo, ma non meno importante, dopo aver considerato tutti i punti sopra degli aspetti relativi allo sviluppo di software sicuro, gli sviluppatori devono seguire il Elenco di controllo stabilito per le pratiche del codice sicuro per garantire che le cose non vengano perse. Di seguito sono riportati alcuni, ma non un elenco esaustivo.
Convalida dell'input:
- Non fidarti dell'input, considera la convalida centralizzata dell'input.
- Non fare affidamento sulla convalida lato client.
- Fai attenzione ai problemi di canonicalizzazione.
- Limita, rifiuta e disinfetta l'input. Convalida per tipo, lunghezza, formato e intervallo.
Autenticazione:
- Partizionamento del sito per area anonima, identificata e autenticata.
- Usa password complesse.
- Supporta i periodi di scadenza della password e la disabilitazione dell'account.
- Non archiviare le credenziali (utilizzare hash unidirezionali con salt).
- Crittografa i canali di comunicazione per proteggere i token di autenticazione.
- Passa i cookie di autenticazione basata su form solo su connessioni HTTPS.
Autorizzazione:
- Usa account con privilegi minimi.
- Considera la granularità dell'autorizzazione.
- Applicare la separazione dei privilegi.
- Limita l'accesso degli utenti alle risorse a livello di sistema.
- Utilizza il protocollo OAuth 2.0 per l'autenticazione e l'autorizzazione.
- Convalida API di esecuzione.
- Whitelist metodi consentiti.
- Proteggi le azioni privilegiate e le raccolte di risorse sensibili.
- Protezione contro la contraffazione di risorse tra siti (CSRF).
Gestione delle sessioni:
- Crea un identificatore di sessione sul server.
- Termina la sessione con il Logoff.
- Genera una nuova sessione alla nuova autenticazione.
- Imposta l'attributo 'protetto' per i cookie trasmessi tramite TLS.
Crittografia:
- Utilizza la crittografia durante 'Dati in transito, Dati in archiviazione, Dati in movimento, Integrità dei messaggi'.
- Non sviluppare il tuo. Utilizza funzionalità della piattaforma collaudate.
- Mantieni i dati non crittografati vicino all'algoritmo.
- Usa l'algoritmo e la dimensione della chiave corretti.
- Evita la gestione delle chiavi (usa DPAPI).
- Fai scorrere periodicamente le chiavi.
- Conserva le chiavi in un luogo limitato.
Registrazione e controllo:
- Identifica comportamenti dannosi.
- Sapere che aspetto ha un buon traffico.
- Controlla e registra l'attività in tutti i livelli dell'applicazione.
- Accesso sicuro ai file di registro.
- Eseguire il backup e analizzare regolarmente i file di registro.
Codifica dell'uscita:
- Effettua la 'convalida dell'input (XML, JSON ...).
- Usa query con parametri.
- Eseguire la 'convalida dello schema'.
- Eseguire la codifica (XML, JSON ..).
- Invia intestazioni di sicurezza.
Riferimento: ' Elenco di controllo delle pratiche di codifica sicura OWASP (In breve, lista di controllo SCP) '
Riepilogo tabulare della lista di controllo della codifica sicura
La tabella seguente riassume il 'Cose da ricordare per il codice sicuro' di un'applicazione.
# | Che cosa? |
---|---|
7 | Per garantire che l'intero team sia obbligato a rispettare lo standard di codifica sicura. |
uno | Per capire chiaramente, 'Cos'è Secure Code'? |
Due | Comprendere le comuni 'Fonti delle vulnerabilità'. |
3 | Condurre la 'sessione di sensibilizzazione alla sicurezza' per il team. |
4 | Identificare e analizzare 'Rischi e titoli' coinvolti nell'applicazione e metodi per 'mitigare'. |
5 | 'Formare il team' su standard di codifica sicura, best practice e linee guida. |
6 | Per definire lo 'standard di codifica sicura' |
8 | Utilizzare il 'linguaggio di facile implementazione' e avere una 'conoscenza approfondita' di esso. |
9 | Per utilizzare gli strumenti IDE (Integrated Development Environment) |
10 | Per utilizzare 'analizzatori statici e dinamici' e 'più analizzatori statici' per eliminare i 'falsi positivi' |
undici | Per eseguire il 'test manuale' ovunque sia necessario per identificare l'errore, saltare gli errori. |
12 | Per definire una serie di 'regole e raccomandazioni per la codifica sicura' |
13 | Eseguire il 'Test di conformità della conformità' per le regole impostate. |
14 | Comprendere il 'metodo di codifica non sicuro' e raccogliere gli 'errori di programmazione comuni'. |
quindici | Per seguire rigorosamente la 'Lista di controllo SCP' |
Conclusione
Ci auguriamo che questo tutorial sia la tua migliore guida per garantire la sicurezza del software.
Le linee guida di codifica per lo sviluppo sicuro del software sono state elencate qui in termini semplici con esempi per una facile comprensione del concetto.
Buona lettura!!
Lettura consigliata
- Test di sicurezza (una guida completa)
- Le 30 migliori società di sicurezza informatica nel 2021 (aziende di piccole e grandi dimensioni)
- Nozioni di base di programmazione informatica per principianti | Tutorial sulla codifica
- I 15 migliori editor di codice gratuiti per una perfetta esperienza di codifica
- Esercitazione sul test di SQL Injection (esempio e prevenzione di attacchi di SQL injection)
- Gli sviluppatori non sono buoni tester. Cosa dici?
- Formato e linee guida dell'esame della Fondazione ISTQB per la risoluzione dei documenti
- Linee guida per i test di sicurezza delle app mobili