Presentación sobre la seguridad de la aplicación web (Capítulo de estudiantes de ACM)

7

Soy miembro del capítulo local de estudiantes de ACM en mi universidad y, como parte de nuestras actividades, tengo programado dar una charla sobre temas actuales sobre seguridad de aplicaciones web (y posiblemente medidas de codificación seguras). La charla se presentará a los estudiantes de nuestro departamento de ciencias de la computación y durará alrededor de una hora de teoría, seguida de un módulo de demostración / manual (alrededor de 1 hora también).

Quiero pedirle sus sugerencias sobre qué temas cree que debería cubrir y cómo mostrar algunos de ellos. Estoy inclinado a presentar la "Lista de TOP10 de problemas de seguridad web" por OWASP, hablar sobre ellos y usar los recursos de la "Guía de OWASP para crear aplicaciones web seguras" para contramedidas y sugerencias.

Para el laboratorio práctico, estoy pensando en utilizar una aplicación intencionalmente vulnerable como WebGoat o algo relacionado. ¿Cuáles son tus pensamientos? Gracias.

    
pregunta Ion 22.12.2011 - 05:58
fuente

2 respuestas

2

El Top 10 de OWASP es una gran idea para el contenido, aunque como puede ver en mis otras publicaciones, siempre recomiendo una parte sobre la practicidad del negocio, así que si puede combinar la charla con información sobre la implementación y el riesgo empresarial, creo que Puede hacer una presentación muy poderosa.

Por ejemplo, incorporar información sobre cómo la remediación compleja para cada uno de los 10 principales de OWASP puede ser de gran valor (por ejemplo, los cambios de código para reducir el riesgo de ataques de inyección SQL son relativamente sencillos en los marcos de codificación que tienen validación de entrada y salida módulos de codificación)

Puede pensar que eso puede ser ajeno al tema para gente técnica, desarrolladores, etc., pero les ayudará si están en condiciones de comprender a los conductores de negocios (o bloqueadores) para el trabajo de remediación.

    
respondido por el Rory Alsop 22.12.2011 - 12:50
fuente
2

En términos de más contenido, puede cubrir el gusano Sammy y cómo evita el problema de HTTPOnly cookies por completo. Es importante tener en cuenta que XSS es mucho más que solo document.cookie y cuadros de alerta PoC. CSRF se vuelve muy difícil de prevenir, pero no imposible. Captcha se puede utilizar para evitar CSRF incluso si XSS está presente (defensa en profundidad). De hecho, Google utiliza este método, como para autorizar la desvinculación de cuentas en youtube y en otros lugares.

Hay muchos tipos diferentes de XSS, dom based xss siendo realmente extraño. Entonces sí, de hecho puedes escribir JavaScript inseguro, aunque ese no es el problema. (He recibido mucho esta pregunta al hacer una charla sobre XSS).

Recientemente, CSP y notas de un mundo post-xss ha recibido mucha atención. Hay un montón de grandes mentes trabajando en el problema de xss. Las características de seguridad antirreflejos XSS que se encuentran en Chrome, IE y NoScript de Firefox también son interesantes, también tienen fallas. Donde el filtro XSS de IE es, con mucho, el más defectuoso .

También les digo a los desarrolladores que XSS es un problema de salida , y que en un Control de Vista Modelo, la Vista es la El mejor lugar para prevenir el XSS. Tratar de escapar de la entrada y almacenarla en la base de datos es una práctica horrible. Por un lado, los datos se vuelven mal formados y las operaciones de comparación pueden fallar. Pero, lo que es más importante, no tiene idea de cómo se utilizarán los datos cuando los inserte en la base de datos. La mayoría de las veces, aplicará ciegamente el método de saneamiento de XSS incorrecto.

Los desarrolladores deben saber probar su código. Hay muchas soluciones gratuitas disponibles. Existe el proyecto de código abierto Skipfish y sitewatch tiene un servicio gratuito.

    
respondido por el rook 22.12.2011 - 16:47
fuente

Lea otras preguntas en las etiquetas