Quali exploit web comuni dovrei conoscere?[Chiuso]
https://stackoverflow.com/questions/23102
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sono ancora piuttosto inesperto quando si tratta di programmazione web, ho trascorso la maggior parte del mio tempo su applicazioni client.Quindi sono curioso di conoscere gli exploit comuni che dovrei temere/testare nel mio sito.
Soluzione
OWASP mantiene un elenco dei I primi 10 attacchi web a cui prestare attenzione, oltre a tantissime altre informazioni di sicurezza utili per lo sviluppo web.
Altri suggerimenti
Sto pubblicando il Elenco abbreviato OWASP Top 2007 qui in modo che le persone non debbano cercare un altro collegamento nel caso in cui la fonte non funzioni.
Cross Site Scripting (XSS)
- I difetti XSS si verificano ogni volta che un'applicazione prende i dati forniti dall'utente e li invia a un browser Web senza prima convalidare o codificare il contenuto.XSS consente agli aggressori di eseguire script nel browser della vittima che possono dirottare le sessioni dell'utente, deturpare siti Web, eventualmente introdurre worm, ecc.
Difetti di iniezione
- I difetti di injection, in particolare l’SQL injection, sono comuni nelle applicazioni web.L'iniezione avviene quando i dati forniti dall'utente vengono inviati a un interprete come parte di un comando o di una query.I dati ostili dell'aggressore inducono l'interprete a eseguire comandi non intenzionali o a modificare i dati.
Esecuzione di file dannosi
- Il codice vulnerabile alla RFI (Remote File Inclusion) consente agli aggressori di includere codice e dati ostili, provocando attacchi devastanti, come la compromissione totale del server.Gli attacchi dannosi legati all'esecuzione di file colpiscono PHP, XML e qualsiasi framework che accetti nomi di file o file dagli utenti.
Riferimento a oggetti diretti non sicuri
- Un riferimento a un oggetto diretto si verifica quando uno sviluppatore espone un riferimento a un oggetto di implementazione interna, ad esempio un file, una directory, un record di database o una chiave, come URL o parametro del modulo.Gli aggressori possono manipolare tali riferimenti per accedere ad altri oggetti senza autorizzazione.
Falsificazione di richieste tra siti (CSRF)
- Un attacco CSRF forza il browser della vittima che ha effettuato l'accesso a inviare una richiesta pre-autenticata a un'applicazione web vulnerabile, che quindi costringe il browser della vittima a eseguire un'azione ostile a vantaggio dell'aggressore.CSRF può essere potente quanto l'applicazione web che attacca.
Perdita di informazioni e gestione impropria degli errori
- Le applicazioni possono perdere involontariamente informazioni sulla loro configurazione, sul funzionamento interno o violare la privacy a causa di una serie di problemi applicativi.Gli aggressori sfruttano questa debolezza per rubare dati sensibili o condurre attacchi più gravi.
Autenticazione e gestione delle sessioni interrotte
- Le credenziali dell'account e i token di sessione spesso non sono adeguatamente protetti.Gli aggressori compromettono password, chiavi o token di autenticazione per assumere l'identità di altri utenti.
Archiviazione crittografica non sicura
- Le applicazioni Web raramente utilizzano correttamente le funzioni crittografiche per proteggere dati e credenziali.Gli aggressori utilizzano dati scarsamente protetti per commettere furti di identità e altri crimini, come le frodi sulle carte di credito.
Comunicazioni non sicure
- Le applicazioni spesso non riescono a crittografare il traffico di rete quando è necessario proteggere le comunicazioni sensibili.
Impossibile limitare l'accesso all'URL
- Spesso un'applicazione protegge solo le funzionalità sensibili impedendo la visualizzazione di collegamenti o URL a utenti non autorizzati.Gli aggressori possono sfruttare questa debolezza per accedere ed eseguire operazioni non autorizzate accedendo direttamente a tali URL.
Il progetto Open Web Application Security
-Adamo
Questi tre sono i più importanti:
Tutti diranno "SQL Injection", perché è la vulnerabilità che sembra più spaventosa e quella più facile da capire.Il Cross-Site Scripting (XSS) arriverà al secondo posto perché è anche facile da capire.La "scarsa convalida dell'input" non è una vulnerabilità, ma piuttosto una valutazione di una best practice di sicurezza.
Proviamolo da una prospettiva diversa.Ecco le funzionalità che, se implementate in un'applicazione web, potrebbero confonderti:
SQL dinamico (ad esempio, generatori di query dell'interfaccia utente).A questo punto probabilmente saprai che l'unico modo affidabile e sicuro per utilizzare SQL in un'app Web è utilizzare query con parametri, in cui si associa esplicitamente ogni parametro nella query a una variabile.I luoghi in cui vedo che le app Web infrangono più frequentemente questa regola è quando l'input dannoso non è un parametro ovvio (come un nome), ma piuttosto un attributo di query.Un esempio ovvio sono i generatori di query "Smart Playlist" simili a iTunes che vedi sui siti di ricerca, dove cose come gli operatori delle clausole dove vengono passati direttamente al backend.Un'altra grande roccia da girare sono gli ordinamenti delle colonne delle tabelle, dove vedrai cose come DESC esposte nei parametri HTTP.
Upload di file.Il caricamento di file confonde le persone perché i nomi dei percorsi dei file assomigliano in modo sospetto ai nomi dei percorsi degli URL e perché i server Web semplificano l'implementazione della parte di "download" semplicemente indirizzando gli URL alle directory del filesystem.7 gestori di caricamento su 10 testati consentono agli aggressori di accedere a file arbitrari sul server, perché gli sviluppatori dell'app presupponevano che fossero applicate alla chiamata "open()" del filesystem le stesse autorizzazioni applicate alle query.
Memorizzazione della password.Se la tua richiesta può inviarmi la mia password grezza quando la perdo, fallisci.Esiste un'unica risposta sicura e affidabile per l'archiviazione delle password, che è bcrypt;se stai usando PHP, probabilmente vorrai PHPpass.
Generazione di numeri casuali.Un classico attacco alle web app:reimpostare la password di un altro utente e, poiché l'app utilizza la funzione "rand()" del sistema, che non è crittografata, la password è prevedibile.Questo vale anche ovunque tu stia eseguendo crittografia.Cosa che, tra l'altro, non dovresti fare:se ti affidi alle criptovalute ovunque, molto probabilmente sei vulnerabile.
Uscita dinamica.Le persone ripongono troppa fiducia nella convalida degli input.Le tue possibilità di eliminare gli input dell'utente da tutti i possibili metacaratteri, specialmente nel mondo reale, dove i metacaratteri sono parti necessarie dell'input dell'utente, sono basse.Un approccio molto migliore è avere un regime coerente di filtraggio degli output del database e di trasformazione in entità HTML, come quot, gt e lt.Rails lo farà automaticamente per te.
E-mail.Molte applicazioni implementano una sorta di funzionalità di posta in uscita che consente a un utente malintenzionato di creare un account anonimo o di non utilizzare alcun account per inviare e-mail controllate dall'utente malintenzionato a indirizzi e-mail arbitrari.
Oltre a queste funzionalità, l'errore n. 1 che potresti commettere nella tua applicazione è esporre un ID di riga del database da qualche parte, in modo che l'utente X possa vedere i dati per l'utente Y semplicemente modificando un numero da "5" a "6".
bool UserCredentialsOK(User user)
{
if (user.Name == "modesty")
return false;
else
// perform other checks
}
ATTACCHI INIEZIONE SQL.Sono facili da evitare ma fin troppo comuni.
MAI MAI MAI MAI (ho già detto "mai"?) fidati delle informazioni dell'utente che ti sono state trasmesse dagli elementi del modulo.Se i tuoi dati non vengono controllati prima di essere passati ad altri livelli logici della tua applicazione, potresti anche dare le chiavi del tuo sito a uno sconosciuto per strada.
Non dici su quale piattaforma ti trovi, ma se su ASP.NET inizia con il buon vecchio Scott Guthrie e il suo articolo "Suggerimento/trucco:Proteggiti dagli attacchi SQL Injection".
Dopodiché devi considerare quale tipo di dati consentirai agli utenti di inviare ed eventualmente estrarre dal tuo database.Se consenti l'inserimento di codice HTML e la successiva presentazione, sei molto esposto agli attacchi Cross Site Scripting (noti come XSS).
Questi sono i due che mi vengono in mente, ma il nostro Jeff Atwood ha scritto un buon articolo Codificare l'orrore con una recensione del libro"19 peccati capitali della sicurezza del software".
La maggior parte delle persone qui hanno menzionato SQL Injection e XSS, il che è tipo corretto, ma non lasciarti ingannare: la cosa più importante di cui devi preoccuparti come sviluppatore web è la VALIDAZIONE DELL'INPUT, da cui derivano XSS e SQL Injection.
Ad esempio, se hai un campo modulo che accetterà solo numeri interi, assicurati di implementare qualcosa sia sul lato client che sul lato server per disinfettare i dati.
Controlla e ricontrolla tutti i dati di input, soprattutto se finiranno in una query SQL.Suggerisco di creare una funzione di escape e di avvolgerla attorno a qualsiasi cosa entri in una query.Ad esempio:
$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";
Allo stesso modo, se intendi visualizzare informazioni inserite dall'utente su una pagina web, assicurati di aver rimosso tutti i tag <script> o qualsiasi altra cosa che potrebbe comportare l'esecuzione di Javascript (come onLoad= onMouseOver= ecc.attributi sui tag).
Questa è anche una breve presentazione sulla sicurezza da parte di uno degli sviluppatori principali di WordPress.
copre tutti i problemi di sicurezza di base nelle app Web.
I più comuni sono probabilmente gli attacchi di database injection e gli attacchi di cross-site scripting;principalmente perché sono i più facili da realizzare (probabilmente perché sono quelli per cui i programmatori sono più pigri).
Puoi vedere anche su questo sito che le cose più dannose di cui ti occuperai riguardano l'iniezione di codice nella tua applicazione, quindi XSS (Cross Site Scripting) e SQL injection (suggerimenti di Patrick) sono le tue maggiori preoccupazioni.Fondamentalmente vorrai assicurarti che se la tua applicazione consente a un utente di inserire qualsiasi codice, sia regolamentata e testata per essere sicuro che solo le cose che sei sicuro di voler consentire (un collegamento html, un'immagine, ecc.) ) vengono passati e non viene eseguito nient'altro.
SQL Injection.Cross Site Scripting.
L'utilizzo di procedure memorizzate e/o query parametrizzate contribuirà notevolmente a proteggerti dall'iniezione SQL.Fallo anche NON fai in modo che la tua app Web acceda al database come sa o dbo: configura un account utente standard e imposta le autorizzazioni.
Come per XSS (cross site scripting) ASP.NET ha alcune protezioni integrate.La cosa migliore è filtrare l'input utilizzando i controlli di convalida e Regex.
Non sono un esperto, ma da quello che ho imparato finora la regola d'oro è non fidarsi dei dati dell'utente (GET, POST, COOKIE).Tipi di attacchi comuni e come salvarti:
- Attacco SQL Injection:Utilizza query preparate
- Cross Site Scripting:Non inviare dati utente al browser senza prima filtrarli/evitarli.Ciò include anche i dati utente archiviati nel database, originariamente provenienti dagli utenti.
