Vale la pena mitigar los riesgos de seguridad en cada aplicación

Question

Como desarrolladores web, nuestras aplicaciones son vulnerables a una serie de agujeros de seguridad (xss, sql-injects, etc.). Soy un firme creyente de que, si está escribiendo una aplicación, debe estar protegida contra todas estas vulnerabilidades conocidas al . Sin embargo, estoy teniendo un momento difícil convencer a mi equipo (y la administración) de que vale la pena el esfuerzo.

Esto me lleva a preguntarme en qué condiciones debería uno pelear la lucha de seguridad? ¿Qué son los factores que deben tenerse en cuenta al decidir qué vulnerabilidades de seguridad a mitigar y cuáles ignorar?

Answer 1

Por supuesto que debe solucionar los problemas de seguridad. La única razón por la cual esto debería ser una prioridad menor es si "confías" en los usuarios del software (por ejemplo, nada que acepte la entrada del usuario es público), pero aún debe hacerse porque las personas pueden explotar algunos agujeros de seguridad por accidente .

Answer 2

Un análisis de seguridad completo no solo analiza las amenazas, sino también lo que podrían causar. Tomemos un Ejemplo, Inyección de SQL. ¿Qué sucede si su cuenta de acceso a la base de datos solo puede LEER pero nunca escribir en la base de datos? Ahora, SQL Injection no puede dañar su base de datos. Sin embargo, todavía tiene el problema de que las consultas SELECT se pueden manipular para obtener acceso a más resultados que los requeridos. ¿Es eso un problema? Probablemente sí, pero es un problema diferente de abordar porque de todos modos podría filtrar los datos en la salida.

Este no es un buen ejemplo de cómo se debe hacer, pero es un ejemplo de cómo a veces lamentablemente tiene que hacerse debido a limitaciones de tiempo y presupuesto. Básicamente: mire todas las amenazas, encuentre las que realmente puedan estropear las cosas y elimínelas.

Otro ejemplo: en Stackoverflow, creo que puedo insertar código arbitrario en este cuadro de respuestas, como un cuadro de entrada o posiblemente algo de JavaScript, pero nadie más que yo verá el cuadro de texto. El servidor lo quitará, y no puedo forjar un enlace que llene el cuadro de respuesta para otros usuarios. En resumen: solo puedo dispararme contra el pie, así que este no es un problema de seguridad al que Jeff debería preocuparse.

Answer 3

Esta es siempre una pregunta realmente difícil. Yo diría que depende de la accesibilidad del sitio web. Si va a tener una gran audiencia, es mejor asegurar todos los elementos estándar: xss, sql injects, etc. Además de eso, uno debe considerar seriamente qué otros métodos se pueden bloquear con un costo mínimo. Si un sitio tiene poco tráfico con una cantidad mínima de accesibilidad, entonces no estaría demasiado preocupado a menos que sea información confidencial.

Realmente depende. Si cree seriamente que la seguridad será un problema, elija algo que sepa que será utilizado para un ataque y construya defensas contra él, fuera del trabajo si fuera necesario. Luego supervise el sitio para ese ataque de seguridad. Cuando se realiza un ataque, infórmalo e indica que el daño fue prevenido porque hiciste algo al respecto de forma proactiva. Añada a eso lo que hubiera sucedido, posiblemente diciéndolo antes de decirle a alguien que el ataque fue prevenido. Si crees que no vale la pena el tiempo, probablemente no valga la pena hacerlo y tal vez quieras que los jefes y el equipo vivan y aprendan. Cuando el poo proverbial golpea al ventilador, déjalo caer y ayuda a arreglar las cosas.

Answer 4

Es probable que su empresa tenga políticas de privacidad y protección de datos, independientemente de si está horneando pan o desarrollando aplicaciones web, y esa debería ser la base de su enfoque.

Personalmente, trabajaría sobre la base de "¿Qué es lo peor que podría pasar?", Y actuaría en consecuencia. Si lo 'peor' es que un usuario interno malicioso derriba su sitio de intranet, entonces tal vez sea un riesgo que vale la pena vivir.Si el "peor" es que sus clientes Finanzas sin encriptar datos están expuestos, así ...

Answer 5

Por desgracia, creo que la respuesta es que no vale la pena en cada aplicación. Y es por eso que generalmente tenemos una seguridad pésima. Eche un vistazo a lo que el experto en seguridad Bruce Schneier tiene said on this.

Answer 6

Correctamente, se debe hacer una estimación de riesgo/retorno para cualquier esfuerzo de programación de seguridad. Sin embargo, de los tres aspectos principales de la seguridad informática (confidencialidad, integridad y disponibilidad), en realidad solo está pensando en la confidencialidad. Es decir, evitar el acceso no autorizado de los usuarios.

Si incluye integridad de los datos y la disponibilidad del sistema, se encuentra que el rendimiento de la mayoría de los esfuerzos de programación de seguridad es mucho mayor que únicamente a partir de la confidencialidad. El diseño seguro adecuado también atrapa una cantidad sorprendentemente grande de errores no maliciosos, lo que permite un mejor tiempo de actividad de la aplicación y la integridad de los datos.

¿Cuál es el costo del tiempo de inactividad, no necesariamente debido a un atacante? ¿Cuál es el costo reputacional de presentar datos incorrectos que podrían haberse detectado fácilmente como malos? Agregue eso al cálculo, y seguir las prácticas de programación segura vale la pena en casi todos los casos. Se deben considerar las precauciones de seguridad no como un esfuerzo adicional, pero deben ser parte de cada diseño e implementación de la aplicación. Si lo hace, el esfuerzo adicional se vuelve muy pequeño, y el rendimiento, en términos de operación más confiable y confiabilidad de la aplicación, es muy grande.

Answer 7

No mitigar vulnerabilidades, solucionarlos.

Si usted tiene una inyección de SQL, que se debe a su capa de acceso a la base de datos es incorrecto. Poner una estrategia de mitigación como filtrar los parámetros con palabras clave como 'SELECCIONAR' o '; DROP DATABASE 'es lo incorrecto. En cambio, cambie a un método de acceso a bases de datos que escapa automáticamente a los parámetros entrantes de la manera adecuada para la base de datos involucrada. A continuación, no solo soluciona el problema, sino que también se asegura de que la aplicación funcione correctamente cuando se enfrenta con un "O'Reilly" u otros datos problemáticos.

Si usted tiene una inyección HTML que lleva a XSS, su estrategia de plantillas que está animando a ciegas salida de texto sin escapar. No intente mitigar la situación detectando y rechazando '<' en los datos, omitirá algunos campos y no conocerá todos los casos especiales, sin mencionar que alguien podría tener una razón válida para ingresar un '<' '. En lugar de arreglarlo, cambie su sistema o estilo de plantillas para que siempre salga el texto siempre que salga de HTML, incluso si los datos "no pueden" contener caracteres especiales.

cuanto a lo que los problemas de seguridad que puede salir a ignorar, que depende de su negocio y la cantidad de clientes están confiando en él. Hay, en general, cuatro niveles de compromiso que afectaba a las aplicaciones web (que supongo que estás hablando como usted menciona inyección SQL y XSS):

1. -nivel de servidor compromiso. Por lo general, desde cuentas shell y FTP mal protegidas, pero también se intensificaron los compromisos a nivel de aplicación. Las aplicaciones que ejecutan el sistema() con datos proporcionados por el usuario a menudo se ponen en peligro tan mal, así como las inyecciones de SQL donde la base de datos es un servidor SQL mal configurado (usando xp_cmdshell). El atacante puede obtener acceso al shell en el servidor y felizmente puede enviar una gran cantidad de spam e intentos de piratería en otros servidores. Esto no es aceptable para ningún negocio.

2. Nivel de aplicación comprometido. Típicamente inyección SQL. El atacante puede leer o borrar cualquier información del cliente de la base de datos y de otra manera interferir con el funcionamiento de la aplicación.Esto es aceptable si se trata de una aplicación de juguete y sus clientes aceptarán la muerte de sus datos, o si el acceso a la aplicación está cerrado, solo estará disponible para las partes/clientes de confianza seleccionados.

3. Nivel de datos comprometido. Típicamente inyección de HTML a XSS. El atacante puede poner un iframe en su sitio apuntando a un exploit de seguridad del navegador poniendo malware en las máquinas de personas que miran la página con un software desactualizado. Esto es aceptable si no le importa un poco la seguridad de sus clientes o, de nuevo, si la aplicación está cerrada al acceso general.

4. Nivel de compromiso del usuario. Normalmente, formas de acción no verificadas que conducen a ataques de falsificación de solicitudes entre sitios. Aceptable si su aplicación no es de suficiente interés para los atacantes que se molesten en probar esto.

En general, la industria está por el momento cerca del nivel 3. Las aplicaciones que permiten ataques de nivel 1 ahora son raras; Los agujeros de nivel 2 son más comunes, pero son problemas que la mayoría de los autores conocen y saben que deben corregir. Los agujeros de nivel 3 son muy comunes y las tácticas para evitar todas las posibles inyecciones de HTML no son ampliamente seguidas. Hoy en día, los agujeros de nivel 4 afectan a la mayoría de las aplicaciones web.

Answer 8

Un enfoque pragmático es hacer una validación de entrada adecuada y en caso de un escape de salida adecuado.

Para cada variable que se obtiene como entrada, se aplican las reglas de filtrado más estrictas que tienen sentido: Si obtiene un identificador de una página, a continuación, un is_integer (myvariable) & & myvariable> 0; es un control adecuado

proceso de seguridad es un proceso de gestión de riesgos que va a lo largo de estas líneas:

1) examinar los casos de uso;

2) Piense en todos los riesgos que se aplican;

3) Elija qué riesgos eliminar (mediante codificación segura u otros medios), que se pueden mitigar mediante controles de compensación (por ejemplo, una amenaza a la demanda o la política del usuario) y qué riesgos aceptar (porque son tan remotos o demasiado costoso para contrarrestar). No olvide monitorear esos riesgos sin embargo.

Así, la yuxtaposición de los dos párrafos anteriores, llegamos a la conclusión de que un programador escribir un controlador de solicitudes para la web siempre debe ser consciente de los posibles riesgos y tomar la decisión de eliminar/mitigar/aceptarlos. Como el programador tiene un tiempo limitado en sus manos, debe aplicar la validación de entrada fascista y no confiar en que la fuente de datos tenga datos desinfectados, ya que podría no ser el único que usa la misma base de datos.

En una nota lateral, si solo piensa en OWASP Top Ten, ha hecho su diligencia debida.