Programación Defensiva<br />Barrios, José – Blondell, Reinaldo – Colmenares, Franyelvis – Rivero, Joselin<br />
Ley de Murphy<br />"Si hay varias maneras de hacer una tarea, y uno <br />de estos caminos conduce al desastre, entonces <...
Origen<br />La auténtica ley de Murphy, originó una técnica de diseño llamada Diseño Defensivo<br />Busca prever solucione...
Programación Defensiva<br />Proyecto que solicitaba la ubicación del usuario para su localización en un mapa. <br />Se dec...
¿Qué es?<br />Prevé y Busca soluciones que puedan evitar fallos en el diseño de un software <br />Garantiza el funcionamie...
Utilidad<br />Objetivos – Problemas que Resuelve<br />Joselin Rivero<br />
Utilidad<br />Apunta a resolver problemas asociados con la calidad<br />del software en todas sus fases<br />Reinaldo Blon...
SANS<br /><ul><li>El Instituto SANS (SysAdminAudit, Networking and Security Institute)
Agrupa a más de 165.000 profesionales de la seguridad informática (consultores,  administradores de sistemas, entes gubern...
Reunir información sobre todo lo referente a seguridad informática (sistemas operativos, redes, aplicaciones, etc.)
Ofrecer capacitación y certificación en el ámbito de la seguridad informática
Referencia habitual en la prensa sobre temas de auditoría informática</li></ul>Reinaldo Blondell<br />
¿Por qué?<br /><ul><li>Según SANS, la primera de las 10 peores vulnerabilidades que hay es:
ISO 27001</li></ul>NO VERIFICACION de los parámetros de ENTRADA y SALIDA de las funciones de nuestros programas<br />12.2....
¿Qué es una Vulnerabilidad?<br />Es cualquier defecto en el mismo que permita explotarlo con el fin de que un atacante pue...
Una mala configuración del software por parte del administrador/usuario.
Una incorrecta programación durante el proceso de desarrollo o actualización del software.
La gran mayoría hoy en día se deben al segundo caso ya que:
Existe bastante documentación de usuario para configurar el software.
Desconocimiento de seguridad informática en la mayoría de programadores.
Empresarios que interrumpen los ciclos de desarrollo del software para terminar antes los productos.
Próxima SlideShare
Cargando en…5
×

Programación Defensiva

1.309 visualizaciones

Publicado el

Ingeniería del Software

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
1.309
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
28
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Programación Defensiva

  1. 1. Programación Defensiva<br />Barrios, José – Blondell, Reinaldo – Colmenares, Franyelvis – Rivero, Joselin<br />
  2. 2. Ley de Murphy<br />"Si hay varias maneras de hacer una tarea, y uno <br />de estos caminos conduce al desastre, entonces <br />alguien utilizará ese camino.”<br />«Si algo puede salir mal, saldrá mal»<br />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<br />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.<br />Joselin Rivero<br />
  3. 3. Origen<br />La auténtica ley de Murphy, originó una técnica de diseño llamada Diseño Defensivo<br />Busca prever soluciones para evitar fallos en la utilización de un dispositivo que puedan llevar a un resultado inesperado.<br />En la actualidad, vemos ejemplos de diseños realizados teniéndola en cuenta: Un cable USB, HDMI, SCART... <br />Están diseñados para que sólo pueda conectarse de forma correcta<br />Joselin Rivero<br />
  4. 4. Programación Defensiva<br />Proyecto que solicitaba la ubicación del usuario para su localización en un mapa. <br />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.<br />El problema se soluciono cambiando la palabra "población" por "localidad" en el formulario. <br />Pero era evitable si se hubiese tenido más en cuenta la programación defensiva validando mejor los campos del formulario.<br />Joselin Rivero<br />
  5. 5. ¿Qué es?<br />Prevé y Busca soluciones que puedan evitar fallos en el diseño de un software <br />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.<br />Joselin Rivero<br />
  6. 6. Utilidad<br />Objetivos – Problemas que Resuelve<br />Joselin Rivero<br />
  7. 7. Utilidad<br />Apunta a resolver problemas asociados con la calidad<br />del software en todas sus fases<br />Reinaldo Blondell<br />
  8. 8. SANS<br /><ul><li>El Instituto SANS (SysAdminAudit, Networking and Security Institute)
  9. 9. Agrupa a más de 165.000 profesionales de la seguridad informática (consultores,  administradores de sistemas, entes gubernamentales, etc.)
  10. 10. Reunir información sobre todo lo referente a seguridad informática (sistemas operativos, redes, aplicaciones, etc.)
  11. 11. Ofrecer capacitación y certificación en el ámbito de la seguridad informática
  12. 12. Referencia habitual en la prensa sobre temas de auditoría informática</li></ul>Reinaldo Blondell<br />
  13. 13. ¿Por qué?<br /><ul><li>Según SANS, la primera de las 10 peores vulnerabilidades que hay es:
  14. 14. ISO 27001</li></ul>NO VERIFICACION de los parámetros de ENTRADA y SALIDA de las funciones de nuestros programas<br />12.2.1: El insumo de data en las aplicaciones debe ser validado para asegurar que esta data sea correcta y apropiada.<br />12.2.2, 12.2.3 y 12.2.4: Que no hayan errores, integridad y validar output.<br />Reinaldo Blondell<br />
  15. 15. ¿Qué es una Vulnerabilidad?<br />Es cualquier defecto en el mismo que permita explotarlo con el fin de que un atacante pueda hacerse con el control del sistema<br /><ul><li>Pueden deberse a:
  16. 16. Una mala configuración del software por parte del administrador/usuario.
  17. 17. Una incorrecta programación durante el proceso de desarrollo o actualización del software.
  18. 18. La gran mayoría hoy en día se deben al segundo caso ya que:
  19. 19. Existe bastante documentación de usuario para configurar el software.
  20. 20. Desconocimiento de seguridad informática en la mayoría de programadores.
  21. 21. Empresarios que interrumpen los ciclos de desarrollo del software para terminar antes los productos.
  22. 22. Las auditorías de seguridad de código fuente apenas se practican.</li></ul>Reinaldo Blondell<br />
  23. 23. Vulnerabilidades y Puntos Críticos más comunes al crear aplicaciones<br />Grupo de Vulnerabilidades mas importantes en la actualidad según SANS:<br />Reinaldo Blondell<br />
  24. 24. Vulnerabilidades y Puntos Críticos<br />Entre las 25 mas importantes existentes en la actualidad tenemos como referencia las siguientes:<br />Defectos o fallas en la preservación de la estructura de las consultas SQL (SQL-injection).<br />Fallas en la preservación de la estructura de las páginas web ( Cross-site Scripting)<br />Control externo del estado de la aplicación (por ejemplo al utilizar cookies para mantener el estado).<br />Inicialización defectuosa.<br />Uso de un algoritmo criptográfico quebrado (obsoleto).<br />Contraseñas establecidas en el código (hard-coded).<br />Franyelvis Colmenares<br />
  25. 25. Ejemplo<br />Franyelvis Colmenares<br />
  26. 26. Ejemplo<br />Asumir que el siguiente código está en una aplicación web y que existe un parámetro "nombreUsuario"<br />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“:<br />Pero si un usuario malintencionado escribe como nombre de usuario<br />Se generaría la siguiente consulta SQL<br />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<br />Franyelvis Colmenares<br />
  27. 27. Cómo evitar el SqlInjection<br />Franyelvis Colmenares<br />
  28. 28. Políticas de Programación<br />La primera cosa que se debe hacer es redactar una política de programación, que contenga:<br />Las cosas que NO se deben hacer<br />La existencia de patrones<br />El know-how de la empresa o grupo de desarrolladores<br />Explícitamente indicar la suma importancia del seguimiento de las reglas<br />Complejidad ciclomática<br />Técnicamente, se puede cumplir con estas reglas<br />Logging (log4net, log4j)<br />Peer review (revisión de pares)<br />Try / catch<br />Franyelvis Colmenares<br />
  29. 29. Logging<br />Aproximadamente un 4% del código debe estar destinado a operaciones de logging (McConnell)<br />Muy difícil enseñar a hacer buen logging, tiempo de aprendizaje aprox. 1 año.<br />Mejor herramienta de logging: log4j / log4net: http://logging.apache.org<br />Cada vez que ocurre una falla en el programa, podemos estar enterados por correo!!<br />José Barrios<br />
  30. 30. Ejemplo Logging (log4net)<br />protected void Logon_Click(object sender, EventArgs e)<br />{<br /> log.Info("Trata de autenticarse: " + UserEmail.Text + "/********");<br /> if (verificar(UserEmail.Text, UserPass.Text))<br /> {<br /> log.Info("Usuario autenticado");<br />… // redirección o a Inicio<br /> }<br /> else<br /> {<br /> log.Error("Usuario " + UserEmail.Text + "/" + UserPass.Text + " incorrectos");<br /> Msg.Text = "Nombre o Clave de Usuario son inválidos, o el usuario ha sido dado de baja";<br /> }<br />}<br />José Barrios<br />
  31. 31. Mejores Prácticas<br />José Barrios<br />
  32. 32. Recomendaciones<br />Evitar los Errores clásicos de la Programación<br />José Barrios<br />
  33. 33. Preguntas<br />Gracias por su atención…<br />El Equipo<br />

×