Hemos desarrollado una aplicación empresarial basada en ASP.NET que pronto se lanzará. Ahora, estamos preocupados por los aspectos de seguridad de la aplicación. He estado buscando en Backtrack 5 y también visité muchos sitios web sobre pruebas de lápiz, pero no fue muy útil. Deseo probar la aplicación desarrollada en busca de vulnerabilidades de seguridad mediante el retroceso.
Mi pregunta es ¿cómo puedo probar mi aplicación utilizando la capacidad completa de Backtrack?
Hay algunos videos vinculados que pueden darle un buen comienzo: " Tutoriales de prueba del lápiz de aplicación web " sin embargo, disparar una herramienta o dos a una aplicación no es un mecanismo confiable para garantizar la seguridad. Como dijo: "hemos desarrollado una aplicación empresarial basada en ASP.NET", lo mejor es trabajar usando, por ejemplo, Agile u otros CASOS DE PRUEBAS basados en SDLC y crear sus propios casos MISUSE. Enlace: " "
El razonamiento / racional detrás de este comentario es que usted (la empresa, los desarrolladores, etc.) son los que hicieron la aplicación. Usted sabe (ha documentado) cómo se supone que funciona y lo que NO debe hacer. Puede crear ataques "especialmente dirigidos" contra su propia aplicación que pueden producir mejores resultados.
El problema con las herramientas es que están preprogramadas con "conocidos conocidos". Los ataques y los atacantes todos evolucionan. Por lo tanto, confiar en una herramienta puede dejarlo todavía vulnerable si el autor de la herramienta no estaba al tanto de una nueva amenaza. Este fue el problema con JAVA recientemente, donde había problemas, Oracle haría sandbox, un atacante lo volvería a romper, lo arreglarían y otro atacante también lo volvería a romper.
Para algo como esto (prueba de aplicaciones), es una cosa muy amplia. Puede usar fuzzers, herramientas de red y una mezcla heterogénea de todo y cualquier cosa, y aún así hacerlo mal. Vale la pena comenzar desde cero:
What does my tool do (test case)
How can someone abuse that my tool is supposed to do? (misuse/abuse case)
Por ejemplo:
Test Case 1: Application takes input from user (a name)
Misuse Case 1: Rogue user tries to enter something other than a name (unicode, hex, etc.)
EDITED
Decidí volver a comentar sobre esto ya que veo la respuesta "contratar a un profesional". Si bien esto sería algo mejor que hacer ya que los "profesionales" tienden a estar mejor equipados y experimentados para lidiar con esto, también pueden y así fracasan. Un enfoque similar a SDLC debe estar a la vanguardia del desarrollo de código seguro. Las pruebas contra (contratar a un profesional) esta práctica de SDLC deberían ser secundarias. Hay una gran diferencia en las pruebas de penetración y la seguridad de la aplicación. Consulte: " Escribiendo un código seguro "
Lea otras preguntas en las etiquetas penetration-test asp.net kali-linux