Seguridad de Aplicaciones: Guía Completa con Ejemplos y Mejores Prácticas

Seguridad de Aplicaciones

MAC

El control de acceso obligatorio está gestionado por un Admin que se encarga de definir las reglas. Los usuarios no pueden ni saltársela ni modificarla.

DAC

El control de acceso discrecional, que también sirve para administrar la posibilidad de las aplicaciones de acceder a recursos, permite a los usuarios la posibilidad de tomar decisiones y asignar atributos de seguridad, cambiando la política.

Validación de Entradas

Regla 1: Todo dato de entrada es nocivo hasta que se demuestre lo contrario.

Regla 2: Los datos tienen que ser validados en el momento en que crucen la frontera entre un entorno no confiable y uno confiable.

Estrategias de Validación

1. Verificar la validez y rechazar en otro caso. (Mejor whitelist) Rechazar ejecutables por ejemplo .exe .bat
2. Utilizar expresiones regulares para validar la entrada
3. No tomar decisiones de seguridad basadas en el nombre de un recurso, especialmente ficheros. Sino convertirlos a su forma canónica.

La canonicalización es el proceso por el cual varias formas equivalentes de un nombre se convierten en un nombre único y estándar: su nombre canónico.

Errores Comunes

Buffer Overflow

Cuando el programa permite que se escriba más allá del fin del buffer reservado. Ej. Si el buffer tenía una longitud de 10 caracteres y el argv[] (entrada usuario) tiene 15.

Tipos de Buffer Overflow:

• Stack: Puede permitir cambiar la dirección de retorno e incluir código para ser ejecutado.
• Heap: Más complicado de explotar pero también posible.
• Errores en la indexación de arrays

Forma de Ataque:

• Averiguar qué buffers están almacenados en la pila
• Escribir un pequeño programa para ejecutar lo que queramos (Shell).
• Añadir suficientes bytes para completar el buffer hasta alcanzar la dirección de retorno.
• Modificar la dirección de retorno para que apunte al comienzo del buffer (donde está nuestro código).

SQL Injection

Introducir código en lugar de datos.

Se basa en que muchos desarrolladores construyen la instrucción SQL a ejecutar a partir de los datos introducidos por el usuario. Si en lugar de datos el usuario introduce una instrucción SQL válida, esta se ejecutará como parte de la instrucción construida.

Lo mejor es filtrar las entradas para permitir únicamente valores válidos. Otra medida es no construir sentencias SQL directamente sino utilizar procedimientos almacenados. Algunos lenguajes de desarrollo actuales suelen incorporar funciones de filtrado de datos para evitar este tipo de ataques.

Command Injection

Un atacante puede modificar el comando o su entorno que ejecuta, controlando lo que el comando es. La vulneración se produce cuando:

• El programa recibe datos que proceden de una fuente no confiable
• Dichos datos son utilizados como parte de una cadena que representa el comando
• Al ejecutar el comando la aplicación otorga al atacante un privilegio que de otra forma no tendría.

Recomendaciones:

• No permitir a los usuarios tener control directo de los comandos a ejecutar.
• Crear whitelist con caracteres permitidos.
• No confiar en el entorno.
• Utilizar rutas completas.
• Ejecutar con los mínimos privilegios posibles.

Fuga de Información

Un atacante puede recibir información que le facilite el ataque a nuestro sistema. En los errores de aplicación se suele incluir mucha información que a un usuario no le serviría, pero sí a un atacante. Al tratar un error (exception) no se debe mostrar al usuario la traza/sentencia SQL/Indicación del Host donde se ejecuta/Información de que se está intentando ejecutar. Hay que usar logger como static final. Se debe evitar la salida estándar (System.out)

Causas de Problemas de Seguridad en la Web

• Inexperiencia en el desarrollo de aplicaciones web.
• No se utilizan metodologías de desarrollo adecuadas basándose únicamente en el diseño y sin realizar pruebas de seguridad.
• Reutilización de componentes reutilizados por otros.
• Falta de estado en la web.
• Falta de mecanismos de seguridad integrados.

Aspectos Importantes

• No podemos confiar en los clientes ya que lo pueden modificar.
• Cualquier dato que le pasemos puede ser visto por este.
• Cualquier código que se ejecute en el cliente está accesible al usuario.
• No hay que dar al cliente más información de la necesaria.
• El tráfico originado en el cliente no es fiable.
• El tráfico entre cliente servidor puede pasar por puntos intermedios.

Como regla general cualquier fichero con información importante se almacenará fuera del árbol accesible por el servidor.

Cross-Site Scripting

Este ataque se basa en introducir código de script donde la aplicación espera texto plano. Cuando la aplicación mande ese texto al navegador, lo interpretará como código y tratará de ejecutarlo. La idea es que se ejecute en la máquina de otro usuario.

Seguridad en Android

Se basa en tres conceptos fundamentales:

• Ejecución de las aplicaciones en sandboxes.
• Aplicaciones firmadas digitalmente
• Un modelo de permisos.

Permisos

Inicialmente el sistema de permisos se basaba en en DAC, en el cual existe un propietario de cada recurso el cual puede otorgar permisos.

A partir de 4.3 se incorpora un MAC de forma opcional, se consulta a una autoridad central, no importa la propiedad del recurso. A partir de 5.0 es obligatorio.

Android Security-Enhanced (SE) Linux funciona con la política de denegar todo por defecto excepto lo que se le ha dado permiso. En la versión 4 cualquier violación de acceso se registraba pero no se impedía. En la versión 5 cualquier violación de acceso se registraba y abortaba.