¿Cómo respondo a una vulnerabilidad de seguridad publicada en mi aplicación?

37

En mi tiempo libre escribo un código PHP cuyo propósito es bloquear el enlace spam y otras actividades maliciosas.

El 11 de mayo, alguien que descubrió una vulnerabilidad XSS en la versión de WordPress de este código lo publicó sin notificarme primero . Afortunadamente, mis usuarios están concentrados y me lo notificaron el 12 de mayo. El 13 de mayo publiqué una solución.

Eso no fue el final.

Desde entonces, he descubierto que la vulnerabilidad se agregó a una amplia variedad de bases de datos como OSVDB y CVE y varios réplicas de esas bases de datos, con diversos grados de inexactitud.

Por ejemplo, uno de estos sitios enumera a alguien completamente diferente como autor del software. Otro lo enumera como que nunca ha sido parchado .

Así que mi principal preocupación es:

Dado que las vulnerabilidades en mi aplicación se publicarán en Internet, me guste o no, ¿cómo ...?

  • ¿Conoce una vulnerabilidad de día cero contra mi aplicación lo antes posible, sin tener que recibir notificaciones irrelevantes?
  • ¿Averigua cuándo las bases de datos de vulnerabilidades crean entradas relacionadas con mi aplicación?
  • ¿Asegurar la precisión de las entradas de la base de datos de vulnerabilidades relacionadas con mi aplicación?
pregunta Michael Hampton 29.08.2012 - 22:44
fuente

5 respuestas

10

Me gustó la respuesta de D.W. Tanto que detesto escribir otra, pero tuve algunos puntos que fueron lo suficientemente grandes que lamentablemente estoy repitiendo aquí:

¿Cómo puedo informarme sobre una vulnerabilidad de día cero contra mi aplicación lo antes posible, sin tener que recibir notificaciones irrelevantes?

Acérquese a la fuente de divulgación de vulnerabilidades que pueda, y comprenda que no siempre será la misma fuente. Tendrá que ser una combinación de mejorar la recuperación de información y hacer que sea fácil de encontrar (lo que tiene sus propias implicaciones de spam).

Las buenas ideas incluyen: - tenga una forma obvia en su sitio para incluir errores y vulnerabilidades - asegúrese de que, cuando vuelva a empaquetar el paquete, parte del acuerdo sea que los errores de seguridad se envíen a su sistema de seguimiento de errores / vulnerabilidades. Probablemente querrá discutir cómo se examinan los problemas antes de enviarlos a su manera, pero tenga en cuenta que a menudo las vulnerabilidades más grandes se encuentran en la forma en que su sistema se integra con el sistema más grande. - asegúrese de que los sitios de publicación de vulnerabilidades sepan cómo encontrarlo - no solucionará un verdadero "día cero", ya que pueden demorarse horas o días, pero definitivamente desea escuchar directamente de ellos. - recopilar toda la información que pueda sobre las posibles vulnerabilidades del producto - Alertas de Google - fue una gran idea. Estoy seguro de que hay otros.

Es posible que tengas que aceptar que te llegará información irrelevante; lo mejor que puedes hacer es clasificarla.

Tenga en cuenta, también, que no todas las vulnerabilidades son encontradas por los buenos. Esperar que alguien más lo encuentre nunca es la forma ideal de encontrar vulnerabilidades. A medida que el producto crezca, querrá introducir algún tipo de verificación de seguridad, incluyendo cosas como:

  • Análisis de seguridad de código, tanto manual como automatizado.
  • prueba de la pluma
  • revisión independiente

El nivel de esfuerzo debe equilibrarse con el costo del error, pero es posible que el costo de encontrar y responder a una vulnerabilidad que se divulgue en público sea mayor que la implementación de su propia verificación de seguridad.

¿Cómo puedo saber cuándo las bases de datos de vulnerabilidades crean entradas relacionadas con mi aplicación?

Muchas de las bases de datos de vulnerabilidades tienen alertas de transmisión: debería poder suscribirse a una transmisión y filtrarla u obtener una fuente RSS y limitarla con criterios de búsqueda.

¿Cómo puedo: garantizar la precisión de las entradas de la base de datos de vulnerabilidades relacionadas con mi aplicación?

Primero: crea una relación con los grupos de bases de datos. Y deje claro cómo crear una relación con usted si un grupo de bases de datos está buscando llegar. guía de CERT , y este artículo - son excelentes recursos para recomendaciones, pero la parte crítica es darse cuenta de que si no pueden llegar a ti, no obtendrán la respuesta correcta.

Y es un proceso bidireccional: tiene una forma de encontrarlo, pero también una forma de publicar información. Y cuando publiques, incluye respuestas sólidas. Como desarrollador de soluciones, tengo demasiados rodeos con los proveedores de soluciones que brindan información de vulnerabilidad de seguridad que parece que la inventaron en el viaje para trabajar sin pruebas reales o información objetiva. Listar cosas como:

  • detalles sobre el arreglo
  • detalles sobre las pruebas utilizadas para verificar la solución
  • detalles específicos sobre el impacto de tomar la solución (¿hay alguna posibilidad de que algo en lo que confío cambie o se rompa?)
  • resumen general del alcance del cambio; por ejemplo, "corrección realizada a una función de utilidad subyacente", "corrección realizada a base de código especalizado utilizada para la interoperabilidad XYZ, el impacto fuera de este espacio es extremadamente limitado"

Y detalles de qué CVE u otro problema publicado está intentando solucionar.

Póngalo en la mayor cantidad de transmisiones que pueda: suscripción por correo electrónico, blog, sitio web, etc. Desea que esto sea posible.

Y dar a conocer su proceso. Si envío una vulnerabilidad a su sitio web, ¿puedo esperar recibir una respuesta en 24 horas? ¿Cómo calificas la severidad? ¿Cuál es el proceso de resolución? Si se trata de un producto que está integrado en otras soluciones, ¿quién realiza las pruebas de interoperabilidad?

No necesitas métricas perfectas, necesitas estar a la altura de ellas. Por lo tanto, si su tiempo de respuesta es de 2 semanas, comuníquelo a los usuarios.

    
respondido por el bethlakshmi 12.09.2012 - 18:31
fuente
27

Para el futuro, hay una cosa crítica que debe hacer:

  • Proporcione una forma fácil para que las personas le informen de errores de seguridad.

    Eché un vistazo a la página web de su aplicación y noté que no parece indicar ninguna forma en que un investigador de seguridad se comunique con usted para informarle sobre una vulnerabilidad de seguridad. No hay una dirección de correo electrónico para reportar vulnerabilidades de seguridad, o al menos no pude encontrar una. No pude encontrar un rastreador de errores que permita a las personas enviar un informe de vulnerabilidad de seguridad confidencial (o incluso cualquier rastreador de errores que permita que un miembro del público presente un informe de errores, y mucho menos un informe confidencial de un error de seguridad) p>

    Vea, por ejemplo, Recomendaciones para vendedores y Hey corporaciones: ¡Proporcione una manera fácil de revelar las vulnerabilidades a usted! .

    Por supuesto, esto no es una bala de plata. Incluso si proporciona una forma clara de informar sobre una vulnerabilidad de seguridad, algunas personas podrían no contactarlo, pero algunos investigadores responsables lo harán. En cualquier caso, puedo decirle una cosa: si no proporciona ninguna forma obvia de comunicarse con usted con un informe de error de seguridad, ¡eso reduce significativamente la probabilidad de que los investigadores de seguridad lo hagan en el futuro!

También hay algunos pasos adicionales que podría tomar, si quisiera, pero estos son opcionales y más allá de lo que clasificaría como importante o esencial para un proyecto de código abierto:

respondido por el D.W. 30.08.2012 - 07:42
fuente
8

Las vulnerabilidades de día cero son más a menudo subterráneas que no, por lo que será difícil de detener a través de una fuente confiable. Las declaraciones publicadas normalmente solo se producen después de que las víctimas hayan detectado y rastreado la vulnerabilidad, a menudo con la suficiente anticipación para que otras víctimas potenciales puedan reparar sus sistemas. Desafortunadamente, estos mensajes solo llegan a la comunidad de código abierto una vez que los editores distribuyen la información sobre la vulnerabilidad, lo que lleva a un efecto dominó de la aplicación de parches.

Afortunadamente, si actualiza automáticamente su software a través de un administrador de paquetes, la comunidad de código abierto puede parchear automáticamente las vulnerabilidades, lo que mitigará la necesidad de la auto validación.

En primer lugar, vale la pena mencionar que CVE tiene una lista de servicios de alerta de vulnerabilidad que pueden ser de su interés. . Estas herramientas enviarán notificaciones para avisarte cuando sea necesario.

Es posible que le interese leer algunos boletines de vulnerabilidades como @RISK , que publica artículos sobre vulnerabilidades en un base semanal.

SecurityFocus también actualiza su sitio web con una lista de vulnerabilidades (aunque sin una fuente) en un espectro de software.

Para filtrar notificaciones irrelevantes, es posible que le interese un filtro de script programado en el contenido de las palabras clave relacionadas con su software.

    
respondido por el Daniel Li 29.08.2012 - 22:52
fuente
3

Alertas de Google : realice una consulta de búsqueda que encuentre menciones de su software y vulnerabilidades, configúrela para que le envíe un correo electrónico a diario, y sabrás de cualquier cosa dentro de las 24 horas posteriores a la indexación de Google.

    
respondido por el pgs 06.09.2012 - 02:08
fuente
0

Si su software está incluido en grandes distribuciones como Fedora, Debian, gentoo, etc., será beneficioso ponerse en contacto con sus equipos de seguridad. Estoy seguro de que estarán más que contentos de que solucione cualquier problema de seguridad futuro que surja, ya que beneficiaría los recursos que tienen para verificar varias fuentes de información de vulnerabilidad diariamente.

    
respondido por el akostadinov 07.09.2012 - 09:38
fuente

Lea otras preguntas en las etiquetas