Lista di controllo per le vulnerabilità di programmazione dei siti Web

Question

Guardare SO online è stato piuttosto istruttivo per me.Vorrei fare un elenco di controllo delle varie vulnerabilità ed exploit utilizzati contro i siti Web e quali tecniche di programmazione possono essere utilizzate per difendersi da essi.

• Quali categorie di vulnerabilità?
  • sito in crash
  • irrompere nel server
  • violare i login di altre persone
  • spam
  • sockpuppeting, meatpuppeting
  • eccetera...
• Che tipo di tecniche di programmazione difensiva?
• eccetera...

Answer 1

Dal Apri il progetto di sicurezza delle applicazioni Web:

1. IL Top ten dell'OWASP vulnerabilità (pdf)
2. Per un elenco più dolorosamente esaustivo: Categoria:Vulnerabilità

I primi dieci sono:

1. Scripting cross-site (XSS)
2. Difetti di injection (SQL injection, script injection)
3. Esecuzione di file dannosi
4. Riferimento diretto all'oggetto non sicuro
5. Falsificazione di richieste intersito (XSRF)
6. Perdita di informazioni e gestione impropria degli errori
7. Autenticazione e gestione della sessione interrotte
8. Archiviazione crittografica non sicura
9. Comunicazioni insicure
10. Impossibile limitare l'accesso all'URL

Answer 2

Ritengo che le informazioni OWASP siano una risorsa preziosa.Anche quanto segue potrebbe essere interessante, in particolare i modelli di attacco:

• CERT Le 10 migliori pratiche di codifica sicura
• Enumerazione e classificazione dei modelli di attacco comuni
• Modelli di attacco
• Programmazione sicura per Linux e Unix
• Una tassonomia degli errori di codifica che influiscono sulla sicurezza
• Programmazione sicura con presentazione di analisi statica

Answer 3

Ovviamente testare ogni campo per le vulnerabilità:

• SQL - stringhe di escape (ad es. mysql_real_escape_string)
• XSS
• HTML stampato dai campi di input (solitamente un buon segno di XSS)
• Qualsiasi altra cosa che non sia lo scopo specifico per cui è stato creato il campo

Cerca loop infiniti (l'unica cosa indiretta (se molte persone la trovassero accidentalmente) che potrebbe davvero uccidere un server).

Answer 4

Alcune tecniche di prevenzione:

XSS

• Se prendi parametri/input dall'utente e pianifichi di pubblicarlo, sia in un registro che in una pagina web, disinfettalo (rimuovi/elimina qualsiasi cosa che assomigli a HTML, virgolette, javascript...) Se stampi l'URI corrente di una pagina dentro di sé, igienizza!Anche stampare PHP_SELF, ad esempio, non è sicuro.Igienizzare!L'XSS riflettente proviene principalmente da parametri di pagina non disinfettati.

• Se prendi qualsiasi input dall'utente e lo salvi o lo stampi, avvisalo se viene rilevato qualcosa di pericoloso/non valido e chiedigli di reinserirlo.un IDS è utile per il rilevamento (come PHPIDS). Quindi disinfettare prima di archiviare/stampare.Quindi, quando stampi qualcosa dall'archivio/database, disinfettalo di nuovo!Ingresso -> IDS/igienizzazione -> negozio -> igienizzazione -> uscita

• utilizzare uno scanner di codici durante lo sviluppo per individuare il codice potenzialmente vulnerabile.

XSRF

• Non usare mai Get Request per funzionalità distruttiva, cioèeliminando un post.Invece, accetta solo richieste post.GET rende le cose ancora più facili per gli hacker.
• Controllare il referrer per assicurarsi che la richiesta provenga dal tuo sito non funziona.Non è difficile falsificare il referrer.
• Utilizza un hash casuale come token che deve essere presente e valido in ogni richiesta e che scadrà dopo un po'.Stampa il token in un campo del modulo nascosto e controllalo sul lato server quando il modulo viene pubblicato.I malintenzionati dovrebbero fornire il token corretto per falsificare una richiesta e, se riuscissero a ottenere il token reale, dovrebbe farlo prima che scada.

SQL Injection

• la tua classe di astrazione ORM o db dovrebbe avere metodi di sanificazione: usali sempre.Se non stai utilizzando una classe di astrazione ORM o db...tu dovresti essere.

Answer 5

SQL Injection

Answer 6

XSS Attacchi (Cross Site Scripting).

Answer 7

Facile da controllare e facile da risolvere:la sanificazione dei dati ricevuti dal lato client.Controllare cose come ';' può aiutare a prevenire il codice dannoso iniettato nell'applicazione.

Answer 8

Buongiorno,

Un buon strumento di analisi statica per la sicurezza è Cerca difetti scritto da David Wheeler.Fa un buon lavoro cercando vari exploit di sicurezza,

Tuttavia, non sostituisce il fatto che qualcuno esperto legga il tuo codice.Come dice David sulla sua pagina web, "Uno sciocco con uno strumento è pur sempre uno sciocco!"

HTH.

Saluti, Rob

Answer 9

Puoi ottenere buoni componenti aggiuntivi per Firefox per testare molteplici difetti e vulnerabilità come xss e sql injection Bussola di sicurezza.Peccato che non funzioni su Firefox 3.0.Spero che questi verranno aggiornati presto.