Recomendaría contratar a alguien (o algún desarrollador podría hacer eso) para educar al equipo de control de calidad usando OWASP Top 10 o WASC TC . Si desea una guía paso a paso sobre cómo deberían ser las pruebas de seguridad, puede usar OWASP Testing Guide , que te dará una imagen bastante buena.

Para agregar a la respuesta de ewanm89, se realiza un enfoque general de las pruebas de penetración dividiendo la prueba en diferentes fases:

• Planificación
• Descubrimiento / Recopilación de información
• ataque
• informes

Planificación

Durante la fase de planificación, por lo general, establece el alcance del ataque (qué sistemas y qué partes debe probar)

Descubrimiento / Recopilación de información

Descubrimiento de host, descubrimiento de servicio, mapeo de topología de red, búsqueda de campos de formulario http / html que pueden probarse más. La información que necesita recopilar depende de qué tipo de prueba de seguridad vaya a realizar.

Ataque

Búsqueda de vulnerabilidades en los servicios que descubrió en la fase anterior. Como es muy probable que encuentre información nueva y más relevante durante la fase de ataque, se moverá entre la fase de descubrimiento y la de ataque. Es decir. backend sql server detrás del servidor web.

Informes

En esta sección reportas tus hallazgos. El informe final suele tener las siguientes secciones:

• Resumen Ejecutivo
• Conclusiones detalladas
• Niveles de riesgo de vulnerabilidades encontradas
• Impacto empresarial
• Recomendaciones
• Conclusión

El siguiente enlace describe este enfoque con detalles: fases de Pentest

Podría hacer mucho peor que comenzar con el Manual de pruebas de seguridad de código abierto (es el manual que es de código abierto, no el objetivo ).

En cuanto a su lista actual, la inyección de código (en particular, pero no exclusivamente de SQL) debería estar muy arriba en su lista.

Si se trata de una aplicación basada en la web, deberías estar viendo la fijación / secuestro de la sesión, XSS. Echa un vistazo a arachni .

Si vas a abordar DDOS, entonces observa Sloloris y el estrangulamiento de la respuesta estrangulada.

Hacer que la gente piense como un atacante es complicado (y cuestionable por sus beneficios: un atacante solo necesita una debilidad, un defensor tiene que cubrirlos a todos). ¿Tal vez darles algunos honeypots para perfeccionar sus habilidades?

En última instancia, depende de lo que se está probando. Lo primero que hace un atacante profesional es investigar qué se está ejecutando, qué debilidades podrían ser bien conocidas y qué tipo de debilidades podrían haberse agregado.

Si es algo con un back-end de base de datos, voy a probar las pruebas de inyección de SQL. Para servicios web estaré buscando ataques XSS y CSRF. Los desbordamientos de búfer son probablemente solo contra el Servidor web / Máquina virtual subyacente a menos que estemos hablando de código nativo aquí (algún cliente enrollado en casa).

No hay una respuesta única, depende de lo que uno esté mirando.

He encontrado el libro "Metasploit: la Guía del probador de penetración" útil en una situación similar; Aunque es principalmente una guía de Metasploit, también analiza los conceptos básicos de las pruebas de penetración.

Un poco fuera de tema, pero es posible que desee consultar Backtrack , un sistema operativo de arranque desde disco para pruebas de penetración. Backtrack tiene Metasploit integrado. Ya que puedes iniciarlo desde un disco o una tarjeta de memoria, tu equipo puede experimentar con él sin tener que instalar nada.

Los tipos de ejemplos que dio son un gran comienzo. En general, desea que sus pruebas imiten la mentalidad del atacante de "cómo puedo hacer un mal uso de este activo". Sí, practique realizar pruebas deliberadamente (y dar entradas) que estén fuera de los requisitos y estén diseñadas, verificando si hay respuestas malas o peligrosas.

Bretik también hace referencia a un buen recurso, en la Guía de pruebas de OWASP. Sin embargo, muchos de estos pueden ser más avanzados y se pueden utilizar mejor para probadores de seguridad específicamente alineados.

También puede considerar que sus especialistas en seguridad trabajen para crear herramientas & Pruebas que tu QA puede ejecutar para probar aplicaciones. Algunas herramientas de análisis de seguridad estáticas y dinámicas ahora proporcionan enlaces o métodos para que QA realice las pruebas. Por ejemplo, una SME de seguridad podría usar W3AF (http://w3af.sourceforge.net/) para crear un script en Python que su probador de control de calidad puede ejecutar contra una aplicación