Your SlideShare is downloading. ×
Programación Defensiva
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Programación Defensiva

798
views

Published on

Ingeniería del Software

Ingeniería del Software


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
798
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Programación Defensiva
    Barrios, José – Blondell, Reinaldo – Colmenares, Franyelvis – Rivero, Joselin
  • 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
  • 6. Utilidad
    Objetivos – Problemas que Resuelve
    Joselin Rivero
  • 7. Utilidad
    Apunta a resolver problemas asociados con la calidad
    del software en todas sus fases
    Reinaldo Blondell
  • 8. SANS
    • El Instituto SANS (SysAdminAudit, Networking and Security Institute)
    • 9. Agrupa a más de 165.000 profesionales de la seguridad informática (consultores,  administradores de sistemas, entes gubernamentales, etc.)
    • 10. Reunir información sobre todo lo referente a seguridad informática (sistemas operativos, redes, aplicaciones, etc.)
    • 11. Ofrecer capacitación y certificación en el ámbito de la seguridad informática
    • 12. Referencia habitual en la prensa sobre temas de auditoría informática
    Reinaldo Blondell
  • 13. ¿Por qué?
    • Según SANS, la primera de las 10 peores vulnerabilidades que hay es:
    • 14. ISO 27001
    NO 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
  • 15. ¿Qué es una Vulnerabilidad?
    Es cualquier defecto en el mismo que permita explotarlo con el fin de que un atacante pueda hacerse con el control del sistema
    • Pueden deberse a:
    • 16. Una mala configuración del software por parte del administrador/usuario.
    • 17. Una incorrecta programación durante el proceso de desarrollo o actualización del software.
    • 18. La gran mayoría hoy en día se deben al segundo caso ya que:
    • 19. Existe bastante documentación de usuario para configurar el software.
    • 20. Desconocimiento de seguridad informática en la mayoría de programadores.
    • 21. Empresarios que interrumpen los ciclos de desarrollo del software para terminar antes los productos.
    • 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
  • 25. Ejemplo
    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
  • 27. Cómo evitar el SqlInjection
    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
  • 31. Mejores Prácticas
    José Barrios
  • 32. Recomendaciones
    Evitar los Errores clásicos de la Programación
    José Barrios
  • 33. Preguntas
    Gracias por su atención…
    El Equipo