¿Auditoría de seguridad de aplicaciones de una aplicación web .NET?

votos
3

¿Alguien tiene sugerencias para la auditoría de seguridad de una aplicación web .NET?

Estoy interesado en todas las opciones. Me gustaría poder hacer algo de manera inmune a mi aplicación para detectar riesgos de seguridad.

EDITAR:

Para aclarar, el sistema ha sido diseñado teniendo en cuenta la seguridad. El entorno se ha configurado teniendo en cuenta la seguridad. Quiero una medida de seguridad independiente, aparte de sí, es seguro ... El costo de tener a alguien que audite más de 1 millón de líneas de código es probablemente más costoso que el desarrollo. Parece que realmente todavía no existe un buen enfoque automatizado / económico. Gracias por tus sugerencias

El objetivo de una auditoría sería verificar de forma independiente la seguridad que implementó el equipo.

Por cierto, hay varias herramientas automatizadas de hack / probe para sondear aplicaciones / servidores web, pero estoy un poco preocupado acerca de si son gusanos o no ...

Publicado el 10/12/2008 a las 00:44
fuente por usuario
En otros idiomas...                            


6 respuestas

votos
3

Lo mejor para hacer:

  • Contratar a un tipo de seguridad para el análisis del código fuente
  • La segunda mejor cosa para hacer es contratar a un tipo de seguridad / compañía de pentesting para el análisis de caja negra

Las siguientes herramientas ayudarán:

  • Herramientas de análisis estático Fortify / Ounce Labs - Revisión de código
  • Considere soluciones como el objeto seguro de HP WebInspects (complemento VS.NET)
  • Comprar un escáner de aplicaciones Blackbox como Netsparker, Appscan, WebInspect, Hailstorm, Acunetix o la versión gratuita de Netsparker

Contratar a un especialista en seguridad es una idea mucho mejor (aunque costará más) porque no solo encontrarán problemas de inyección y técnicos donde pueda encontrar una herramienta automatizada, sino que también encontrarán todos los problemas lógicos.

Respondida el 15/12/2008 a las 16:40
fuente por usuario

votos
2

Cualquier persona en su situación tiene las siguientes opciones disponibles:

  1. Revisión de código,
  2. Análisis estático de la base de código usando una herramienta,
  3. Análisis dinámico de la aplicación en tiempo de ejecución.

Mitchel ya ha señalado el uso de Fortify. De hecho, Fortify tiene dos productos para cubrir las áreas de análisis estático y dinámico: SCA (herramienta de análisis estático, para usar en el desarrollo) y PTA (que realiza análisis de la aplicación a medida que se ejecutan los casos de prueba durante la prueba).

Sin embargo, ninguna herramienta es perfecta y puede terminar con falsos positivos (fragmentos de su base de código aunque no sean vulnerables serán marcados) y falsos negativos. Solo una revisión del código podría resolver tales problemas. Las revisiones de los códigos son costosas, no todas las personas de su organización podrían revisar el código con los ojos de un experto en seguridad.

Para comenzar, con uno puede comenzar con OWASP. Se recomienda encarecidamente entender los principios que rigen la seguridad antes de estudiar la Guía de desarrollo de OWASP (3.0 está en borrador, 2.0 puede considerarse estable). Finalmente, puede prepararse para realizar el primer escaneo de su código base .

Respondida el 11/12/2008 a las 21:36
fuente por usuario

votos
0

Te recomiendo que te comuniques con Artec Group , Security Compass y Veracode y revises sus ofertas ...

Respondida el 17/05/2009 a las 00:51
fuente por usuario

votos
0

Hemos usado Telus para llevar a cabo las pruebas de la pluma varias veces y hemos quedado impresionados con los resultados.

Respondida el 15/12/2008 a las 16:59
fuente por usuario

votos
0

Las pruebas y el análisis estático es una forma muy pobre de encontrar vulnerabilidades de seguridad, y es realmente un método de último recurso si no ha pensado en la seguridad durante todo el proceso de diseño e implementación.

El problema es que ahora intenta enumerar todas las formas en que su aplicación podría fallar, y negarlas (mediante parches), en lugar de tratar de especificar qué debe hacer su aplicación, y evitar todo lo que no sea eso (mediante programación defensiva ) Dado que su aplicación probablemente tiene infinitas formas de fallar y solo algunas de las cosas que debe hacer, debe adoptar el enfoque de "denegar de manera predeterminada" y permitir solo las cosas buenas.

Dicho de otra manera, es más fácil y más efectivo incorporar controles para evitar clases enteras de vulnerabilidades típicas (por ejemplo, ver OWASP como se menciona en otras respuestas) sin importar cómo puedan surgir, que buscar lo que se ha confundido específicamente. alguna versión de tu código tiene. Debería intentar evidenciar la presencia de buenos controles (que se pueden hacer), en lugar de la ausencia de cosas malas (que no pueden).

Si logra que alguien revise sus requisitos de diseño y seguridad (¿contra qué está tratando de proteger exactamente?), Con acceso total al código y a todos los detalles, será más valioso que algún tipo de prueba de recuadro negro. Porque si su diseño es incorrecto, no importará qué tan bien lo haya implementado.

Respondida el 15/12/2008 a las 16:32
fuente por usuario

votos
0

Una de las primeras cosas que comencé a hacer con nuestra aplicación interna es utilizar una herramienta como Fortify que hace un análisis de seguridad de su código base.

De lo contrario, podría considerar contratar los servicios de una empresa de terceros especializada en seguridad para que prueben su aplicación

Respondida el 10/12/2008 a las 01:28
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more