Quali diversi tipi di sicurezza esistono? Perché e quando dovrebbero essere implementati?
Esempio: Prevenzione dell'iniezione SQL
Quali diversi tipi di sicurezza esistono? Perché e quando dovrebbero essere implementati?
Esempio: Prevenzione dell'iniezione SQL
a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety.
Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited...
Non riesco a contare gli exploit basati su questo.
Non sono un esperto, ma secondo la mia esperienza, esistono diversi ben noti vettori di attacco per i sistemi:
Dati utente non convalidati
Questo è il classico meccanismo di overrun buffer, SQL injection, drive-by-download ed è causato da una pianificazione insufficiente o da un'educazione su pratiche di codifica sicure. È importante assicurarsi che gli sviluppatori comprendano come utilizzare il codice qualsiasi non sicuro per sfruttare un attacco zero-day su un computer. Solo perché il tuo sito web non fa nulla di particolarmente segreto / importante, non significa che ottenere l'accesso come root al tuo webserver non possa danneggiare le altre parti dell'organizzazione.
Debole sicurezza
Questo può essere una combinazione di scarsa infrastruttura di sicurezza, politica o password non valide. La password più popolare al mondo è "password1" poiché la maggior parte dei provider di posta elettronica ha iniziato a insistere su password alfanumeriche - in precedenza era "password". Se un attacco basato sul dizionario può indovinare la password di un utente, la politica è stata insufficiente.
Backdoor
Alcuni programmatori intraprendenti lasciano backdoor di accesso rapido nel codice nel caso in cui debbano saltare e "riparare" il sistema. Se hai qualcuno di questi, intenzionale o meno, il tuo sistema è una bomba a orologeria.
Che cosa fare a proposito
Applicazioni web:
In base al numero di attacchi - vedi le statistiche di Verizon , < a href="http://www.owasp.org/index.php/Category%3aOWASP_Top_Ten_Project"> OWASP , WHID e altri: la singola cosa più importante che puoi fare per migliorare la sicurezza di un'applicazione web è implementare la validazione dell'input solido . Non fidarti di nulla che il client / browser ti manda. Questo risolverà il problema dell'iniezione SQL e aiuterà in una serie di altre aree, tra cui l'overflow del campo / buffer.
Dipende completamente dal tipo di app, dal potenziale exploit e dall'ambiente atteso.
Se corri in un ambiente che si presume sia sicuro, potresti discutere poco o nulla.
Se stai scrivendo un'app Web esposta pubblicamente o un'app che coinvolge un'API esposta pubblicamente, dovresti pensare agli scenari probabili come defacement, false submission, exploit di autenticazione, accesso ai dati che non appartengono a te , ecc.
Se stai costruendo un'app che memorizza i dati localmente potresti doverti preoccupare della sicurezza di tali dati, mantenendoli separati tra gli utenti su un sistema multiutente, ecc.
IMHO non ci sono problemi di sicurezza che sono SEMPRE applicabili in ogni situazione.
Leggi altre domande sui tag security comparison