it-swarm-es.com

Realización de una revisión manual del código de seguridad: ¿a qué se debe prestar atención?

Tenemos una aplicación PHP que queremos que un consultor de seguridad externo revise el código, pero no tengo claro "cómo" realizar ese proceso.

Especificamos qué tipo de pruebas debería hacer, y la primera parte de su informe enviado solo señala MUY estándar 'problemas' en el uso de eval (), fopen (), etc., bajo el título 'Problemas de validación de entrada'.

Vi TODOS estos problemas informados por mi cuenta cuando ejecuté una herramienta de revisión automática de códigos de seguridad.

(A) No sé si ese es el alcance del problema dentro de mi código y el tipo hizo un buen trabajo, O
(B) solo está ejecutando estas herramientas automatizadas y simplemente filtrando la salida para eliminar el ruido, ¡y listo!

Preguntas:

  1. ¿Qué debería pedirle que haga?
  2. ¿Cómo puedo verificar su trabajo para saber que realmente lo está haciendo bien?

(copiado de https://stackoverflow.com/questions/4311151/getting-a-manual-security-code-review-done-what-to-watch-out-for )

16
matt74tm

Darse cuenta de que incluso tiene esa pregunta ya lo pone por delante del juego.
También agregaría:

(C) No es muy bueno para revisar el código, por lo que solo obtendrá "fruta madura"
(D) Es realmente un pentester, que piensa que es " oh tan fácil " ramificarse en código, así que obtendrás resultados similares a los de un pentest, solo que se remontan al código real.
(E) Es un desarrollador, sin mucha comprensión de seguridad, pero conoce un código incorrecto.
etc ...

El asunto es que parece que no está siendo muy transparente contigo, por lo que realmente no importa qué opción sea. Incluso (A) My code has no problems no vale mucho, a menos que pueda respaldarlo con una prueba de qué problemas no tiene su código (sic).
Y no, ejecutar una herramienta automatizada no cuenta como una revisión del código de seguridad, como aparentemente sintió, correctamente.

Entonces, a sus preguntas:

1. What should you ask him to do "Revisión del código de seguridad". Él debería estar diciendo usted lo que hará y/o recomendará qué más necesitas (esta podría/debería ser una lista bastante larga). Por supuesto, puede/debe darle más información, como lo que hace su aplicación, quién tiene acceso, qué tan sensibles son los datos, etc. Pero incluso si no lo hace, debe pedir esta información. Sin él, simplemente no es una revisión de código de nivel profesional.

2. How do I cross-check his work - Yo diría que, en general, hay 3 posibilidades:

  • Aprenda lo suficiente sobre el tema para comprender lo que dice estar haciendo y para hacer las preguntas difíciles, o busque a alguien que lo haga (siempre es cierto cuando se trata de un proveedor de un servicio que no comprende del todo ...)
  • Haga que otro consultor realice una revisión competitiva, aunque solo sea en un subconjunto de la aplicación.
  • (Y esta es la buena) Realice una prueba de penetración de caja negra externa. Esta es la mejor forma de validar la revisión del código. Por supuesto, pida a otra persona que haga el pentest y compare los resultados. Nota que no todas las vulnerabilidades encontradas en pentest son relevantes para ser encontradas en una revisión de código, y viceversa, pero debería darle alguna indicación.
7
AviD

Llego a esto desde la posición de ser el tipo que realiza la revisión del código de seguridad (aunque yo no hice la tuya ;-). Entonces, lo que desea saber es si el código podría implementarse con bajo riesgo y, de no ser así, cuáles son los riesgos. Por lo tanto, debe preguntarle a su consultor que, en lugar de preguntar "¿puede encontrar algunas vulnerabilidades en mi código"? La respuesta a la pregunta relacionada con el riesgo debe incluir:

  • lo que ha intentado para identificar los riesgos
  • qué ataques ha considerado (supongo que una aplicación PHP estará basada en la web, en cuyo caso la lista de los 10 principales de OWASP es apropiada como punto de partida)
  • por qué consideró esos ataques (en otras palabras, qué modelo de amenaza usó)
  • qué riesgo residual queda
5
user185

Debe considerar tanto la amplitud como la profundidad de la revisión. Por amplitud, me refiero a la gama de riesgos/ataques/amenazas que se cubrirán en la revisión. Debe comenzar con el Estándar de verificación de seguridad de aplicaciones de OWASP para tener una idea de lo que debe cubrirse aquí. Por profundidad, me refiero a qué tan bien el consultor verificará que cada área haya sido defendida adecuadamente. En el extremo inferior, un escaneo automatizado de herramientas proporciona poca seguridad. En el extremo superior, una inspección manual o un caso de prueba real debería esencialmente demostrar que las defensas correctas están en su lugar, se han diseñado correctamente y se utilizan en todos los lugares donde deben estar.

2
planetlevel