2. Ley de Murphy "Si hay varias maneras de hacer una tarea, y uno de estos caminos conduce al desastre, entonces alguien utilizará ese camino.” «Si algo puede salir mal, saldrá mal» Se tiende a recordar más vívidamente las veces en que cayó con el lado de la mantequilla hacia el suelo puesto que tiene mas consecuencias Por lo tanto, se tiene la impresión de que el pan siempre cae con la mantequilla hacia abajo, sin importar la verdadera probabilidad de cada ocurrencia. Joselin Rivero
3. Origen La auténtica ley de Murphy, originó una técnica de diseño llamada Diseño Defensivo Busca prever soluciones para evitar fallos en la utilización de un dispositivo que puedan llevar a un resultado inesperado. En la actualidad, vemos ejemplos de diseños realizados teniéndola en cuenta: Un cable USB, HDMI, SCART... Están diseñados para que sólo pueda conectarse de forma correcta Joselin Rivero
4. Programación Defensiva Proyecto que solicitaba la ubicación del usuario para su localización en un mapa. Se decidió utilizar los campos "país" y "población", pero al poco tiempo se detecto que algunos usuarios confundían población con número de habitantes si se situaba junto a país. Para ese momento, ya habían varios usuarios registrados de los cuáles no se sabía su población. El problema se soluciono cambiando la palabra "población" por "localidad" en el formulario. Pero era evitable si se hubiese tenido más en cuenta la programación defensiva validando mejor los campos del formulario. Joselin Rivero
5. ¿Qué es? Prevé y Busca soluciones que puedan evitar fallos en el diseño de un software Garantiza el funcionamiento esperado de algún elemento de la aplicación ante cualquier situación que pueda aparecer, por muy extraño que sea. Joselin Rivero
14. ISO 27001NO VERIFICACION de los parámetros de ENTRADA y SALIDA de las funciones de nuestros programas 12.2.1: El insumo de data en las aplicaciones debe ser validado para asegurar que esta data sea correcta y apropiada. 12.2.2, 12.2.3 y 12.2.4: Que no hayan errores, integridad y validar output. Reinaldo Blondell
22. Las auditorías de seguridad de código fuente apenas se practican.Reinaldo Blondell
23. Vulnerabilidades y Puntos Críticos más comunes al crear aplicaciones Grupo de Vulnerabilidades mas importantes en la actualidad según SANS: Reinaldo Blondell
24. Vulnerabilidades y Puntos Críticos Entre las 25 mas importantes existentes en la actualidad tenemos como referencia las siguientes: Defectos o fallas en la preservación de la estructura de las consultas SQL (SQL-injection). Fallas en la preservación de la estructura de las páginas web ( Cross-site Scripting) Control externo del estado de la aplicación (por ejemplo al utilizar cookies para mantener el estado). Inicialización defectuosa. Uso de un algoritmo criptográfico quebrado (obsoleto). Contraseñas establecidas en el código (hard-coded). Franyelvis Colmenares
26. Ejemplo Asumir que el siguiente código está en una aplicación web y que existe un parámetro "nombreUsuario" Si el usuario escribe su "Alicia”, la aplicación generara una sentencia SQL correcta similar a la siguiente, donde se seleccionaría al usuario "Alicia“: Pero si un usuario malintencionado escribe como nombre de usuario Se generaría la siguiente consulta SQL La base de datos ejecutaría la consulta en orden, seleccionaría el usuario 'Alicia', borraría la tabla 'usuarios' y seleccionaría datos que quizá no están disponibles para los usuarios web comunes Franyelvis Colmenares
28. Políticas de Programación La primera cosa que se debe hacer es redactar una política de programación, que contenga: Las cosas que NO se deben hacer La existencia de patrones El know-how de la empresa o grupo de desarrolladores Explícitamente indicar la suma importancia del seguimiento de las reglas Complejidad ciclomática Técnicamente, se puede cumplir con estas reglas Logging (log4net, log4j) Peer review (revisión de pares) Try / catch Franyelvis Colmenares
29. Logging Aproximadamente un 4% del código debe estar destinado a operaciones de logging (McConnell) Muy difícil enseñar a hacer buen logging, tiempo de aprendizaje aprox. 1 año. Mejor herramienta de logging: log4j / log4net: http://logging.apache.org Cada vez que ocurre una falla en el programa, podemos estar enterados por correo!! José Barrios
30. Ejemplo Logging (log4net) protected void Logon_Click(object sender, EventArgs e) { log.Info("Trata de autenticarse: " + UserEmail.Text + "/********"); if (verificar(UserEmail.Text, UserPass.Text)) { log.Info("Usuario autenticado"); … // redirección o a Inicio } else { log.Error("Usuario " + UserEmail.Text + "/" + UserPass.Text + " incorrectos"); Msg.Text = "Nombre o Clave de Usuario son inválidos, o el usuario ha sido dado de baja"; } } José Barrios
