Rischi per la sicurezza diversi da quelli [chiuso]

La corretta gestione delle sessioni e il controllo dell'accesso a livello di funzione è un punto molto importante nella sicurezza web ( Scopri Gestione della sessione OWASP e Controllo di accesso a livello di funzione ).

Assicurati sempre che i token di sessione siano realmente validi solo per le azioni che un determinato utente può eseguire. E solo per quel determinato utente.

Questo è un grosso problema e il 99% di tutti i siti Web che ho provato finora erano vulnerabili agli attacchi che si sono evoluti intorno a questo. Per esempio. quando i token possono essere utilizzati per eseguire azioni, l'utente attualmente connesso non dovrebbe essere in grado di farlo. Come: sostituzione di un ID in una richiesta con l'ID di un altro utente (o record). Sareste sorpresi di quanto spesso questo metodo estremamente semplice funzioni per ottenere informazioni personali di altri utenti!

• Tutti gli URL sono accessibili solo agli utenti con determinati privilegi.
• Gli utenti non dovrebbero essere in grado di aggiungere semplicemente campi a una richiesta. Buon esempio: ho già visto più siti Web / app, dove è stato possibile dirottare altri account utente semplicemente aggiungendo un campo "email" nel modulo in cui ogni utente può modificare le proprie informazioni sul profilo.
• Assicurati che il tuo modo di concedere ruoli agli utenti / agli amministratori sia sicuro e che gli utenti non possano concedere loro stessi privilegi / ruoli aggiuntivi.
• I moduli di reimpostazione della password sono spesso anche un buon punto di accesso per gli aggressori, e lo sono solo per inviare spam ad altri utenti.

Le sessioni devono essere distrutte alla disconnessione / modifica della password e non essere riutilizzate in qualsiasi momento.

A parte questo, dovresti anche preoccuparti della divulgazione di informazioni (quando un utente malintenzionato applica errori, ad esempio con richieste HTTP o metodi -metali non validi, come OPZIONE invece di OPZIONI). E, naturalmente, assicurati sempre che il tuo sito web utilizzi solo le librerie più aggiornate (javascript, moduli server e così via).

Non divulgare mai alcuna informazione sensibile - ad es. assicurati che i token di sessione non vengano mai trasmessi tramite richieste GET.

Assicurati inoltre che il tuo server permetta solo determinati metodi HTTP (ad esempio non consentire "TRACE").

Convalida dell'input: protegge tutti i moduli di caricamento file, sono molto vulnerabili. Per esempio. carico utile nel nome del file. Ho anche visto spesso che la dimensione massima del file è stata convalidata solo sul lato client.

Utilizza i captcha quando necessario e assicurati che non possano essere aggirati a causa di una cattiva implementazione.

Ultimo ma non meno importante, dovresti anche preoccuparti dei reindirizzamenti aperti.

In realtà ci sono molte cose di cui dovresti preoccuparti. Iniezione per esempio: non c'è solo l'iniezione SQL, ma anche l'iniezione di Javascript è un rischio elevato per la sicurezza della tua applicazione. Succede più spesso di SQL-injection, di gran lunga.

Potrei andare avanti con questa lista per un po ', ma ti suggerisco di dare un seguito leggendo alcune checklist come questa: link

Qualcosa che ho imparato dall'esperienza: gli sviluppatori (me compreso) possono e DEVONO dimenticare le cose. SQLi è un ottimo esempio: se ti affidi agli sviluppatori per utilizzare un escape_string (user_input) ogni volta che viene utilizzato, lo dimenticheranno.

Idem XSS e XSRF: gli sviluppatori mancheranno sempre almeno un posto in cui le stringhe possono essere sfuggite. E CSP non è una correzione al 100% per XSS.

È assolutamente fondamentale utilizzare framework / librerie che siano invulnerabili a tali problemi (o dove sia necessario l'opt-in). Non conosco specificamente ASP.net, quindi non posso davvero raccomandarne uno, ma un termine da cercare è "auto-fuga contestuale" (per XSS).

In termini di altri problemi, ti suggerisco di consultare OWASP Top 10 - fanno un bel buon lavoro di mostrare qual è la cosa importante.

Una cosa a cui prestare attenzione in particolare è "riferimento agli oggetti diretti non sicuri" o "esplorazione forzata", assicurando che gli ACL vengano applicati ad ogni caricamento della pagina. E tornando alla prima cosa che ho detto, dovrebbero essere applicati automaticamente - lo sviluppatore non dovrebbe ricordarsi di farlo. Qualsiasi comportamento non sicuro dovrebbe essere esplicitamente opt-in.

Spero che ti aiuti!

La lista che hai è un buon punto di partenza, ma ce ne sono molte altre che dovresti cercare. Molti di questi dipendono da ciò che si sta facendo nella propria applicazione e da quali sono i requisiti della propria applicazione. Ecco una breve lista per iniziare:

Controllo di accesso:
Assicurarsi che solo gli utenti autenticati e autorizzati abbiano accesso alle azioni del controllore. Ricorda che qualsiasi metodo pubblico su una classe che eredita dal Controller può essere richiesto dal Web, non solo i metodi che restituiscono un ActionResult. Il modo migliore per gestire ciò è decorare tutti i controller con l'attributo [Authorize] e qualsiasi metodo che deve essere accessibile da utenti non autenticati dovrebbe avere l'attributo [AllowAnonymous] applicato.

Vulnerabilità correlate al caricamento di file: Esistono molte possibili vulnerabilità correlate ai caricamenti dannosi. Se non si stanno disinfettando correttamente i file caricati, è possibile che un utente malintenzionato possa sovrascrivere alcuni dei file esistenti, inclusi i file javascript e i modelli Razor (consultare l'inclusione dei file locali per ulteriori informazioni). Dovresti idealmente rinominare i file caricati in qualcosa che l'utente non può controllare o indovinare. Inoltre, questo dovrebbe idealmente essere al di fuori della web root.

Altre aree di ricerca sono la falsificazione di richieste lato server, bypass di crittografia, difetti di registrazione / reimpostazione della password, ecc. L'elenco potrebbe continuare all'infinito.

Come altri hanno già detto, consulta il Progetto Top 10 OSWAP . Nota alcune nuove aggiunte alla loro lista 2017 proposta: Insufficiente protezione contro gli attacchi e API sottoprotette.

Incapsula ha anche una buona lista di minacce alla sicurezza delle applicazioni web che consiglio di recensire . Ovviamente la raccomandazione è un WAF, ma è bene che tu stia considerando la sicurezza all'inizio del design. Hai coperto alcune di queste minacce, ma considera anche:

• APT
• Attacchi di social engineering
• Inclusioni di file remoti

e ce ne sono molti altri. Sfortunatamente, non c'è fine alle minacce, ma prenderle seriamente le ridurrà in modo sostanziale.

Posso chiederti, quali funzionalità richiede il tuo sito web o che cosa è il targeting in quanto ciò influisce su vulnerabilità specifiche per prestare maggiore attenzione oltre alle (importanti) nozioni di base.