Presentazione su Web App Security (capitolo degli studenti ACM)

Question

Presentazione su Web App Security (capitolo degli studenti ACM)

#1 da (2 voti)
#2 da (2 voti)

7

Sono un membro del locale capitolo degli studenti ACM nella mia università e, come parte delle nostre attività, sono in programma di tenere un discorso sui problemi attuali relativi alla sicurezza delle applicazioni Web (e possibilmente su misure di codifica sicure). Il discorso sarà presentato agli studenti del nostro dipartimento di informatica e durerà circa un'ora di teoria seguita da un modulo demo / pratico (circa 1 ora di seguito).

Voglio chiedere i tuoi suggerimenti su quali argomenti pensi che dovrei coprire e su come dimostrarne alcuni. Sono propenso a presentare la "lista TOP10 dei problemi di sicurezza web" di OWASP, parlarne e utilizzare le risorse della "Guida di OWASP alla creazione di app web sicure" per contromisure e suggerimenti.

Per il laboratorio pratico sto pensando di utilizzare un'app intenzionalmente vulnerabile come WebGoat o qualcosa di simile. Quali sono i tuoi pensieri? Grazie.

sql-injection xss csrf owasp owasp-top-ten

posta Ion 22.12.2011 - 05:58

fonte

2 risposte

Leggi altre domande sui tag sql-injection xss csrf owasp owasp-top-ten

Mantenere privati i dati degli utenti in un ambiente cloud come Google App Engine Come gestire le applicazioni tunnel come TeamViewer sulla rete aziendale

score 2 · Answer 1

La Top 10 di OWASP è una grande idea per i contenuti - anche se come puoi vedere dai miei altri post, consiglio sempre un pezzo di praticità aziendale, quindi se riesci a combinare il discorso con le informazioni sull'implementazione e sui rischi aziendali, penso che può fare una presentazione molto potente.

Ad esempio, incorporare informazioni su come la riparazione complessa per ciascuna delle 10 migliori OWASP può essere di alto valore (ad esempio, le modifiche al codice per ridurre il rischio di attacchi SQL injection sono relativamente semplici nei framework di codifica che hanno convalida e output dell'input moduli di codifica)

Potresti pensare che possa essere off-topic per tecnici, sviluppatori, ecc., ma li aiuterà se sono in grado di comprendere i driver aziendali (o i bloccanti) per il lavoro di riparazione.

score 2 · Answer 2

In termini di più contenuti puoi coprire il worm Sammy e come evita il problema di HTTPOnly cookies interamente. È importante notare che XSS è molto più che solo document.cookie e caselle di avviso PoC. CSRF diventa molto difficile da prevenire, ma non impossibile. I captcha possono essere utilizzati per prevenire CSRF anche se è presente XSS (difesa approfondita). Google infatti utilizza questo metodo, come per autorizzare lo scollegamento dell'account su youtube e in altri luoghi.

Ci sono molti diversi tipi di XSS, basato su dom xss è davvero uno strano. Quindi sì, in effetti puoi scrivere JavaScript non sicuro, anche se di solito non è questo il problema. (Ho ricevuto questa domanda molto quando ho fatto un intervento XSS.)

Molto recentemente il CSP e note da un mondo post-xss ha ottenuto molta attenzione. Ci sono molte grandi menti che lavorano sul problema di xss. Anche le funzionalità di sicurezza anti-riflesso XSS trovate in Chrome, IE e NoScript di Firefox sono interessanti, sono anche imperfette. Dove il filtro XSS di IE è di gran lunga il più difettoso .

Dico anche agli sviluppatori che XSS è un problema di output , e che in un controllo vista modello, la vista è il miglior posto per prevenire XSS. Cercare di uscire dall'input e archiviarlo nel database è una pratica orribile. Per uno, i dati diventano malformati e le operazioni di confronto possono fallire. Ma ancora più importante non hai idea di come verranno utilizzati i dati quando li inserirai nel database, molto spesso applicherai ciecamente il metodo di sanificazione XSS sbagliato.

Gli sviluppatori dovrebbero sapere di testare il loro codice. Ci sono molte soluzioni gratuite disponibili. C'è il Skipfish progetto open source e sitewatch ha un servizio gratuito.