La Seguridad es una medida NO un característica
Usabilidad
Parte de un diseño
Ideas Previas
No hay conciencia y las estadísticas de incidentes no mejoran!!!
Falta de competencias
“El problema es del Admor Red / Oficial de Seguridad Informático”
Desconocimiento de las arquitecturas, API’S, frameworks….. Seguros.…
Problemas de seguridad
Ausencia infraestructura seguridad
Errores administrador/usuario
Exploits Programar bien !!!
entender cómo funcionan las cosas
aprender buenas políticas
aprender trampas habituales
• Es extremadamente sencillo equivocarse
• Mal diseño del lenguaje
• Malas prácticas de programación
• Hay lenguajes inmunes, pero no siempre podremos usarlos
• En C, cuidado con: strcpy, strcat,sprintf, gets, scanf Desbordamientos
Los desbordamientos de buffer se basan en introducir el código en el espacio reservado para las variables locales (los argumentos de un método / función) y después modificar la dirección de retorno/regreso (RET), donde regresa la información, para que apunte a un offset en donde hemos introducido nuestro código fuente.
Este código puede ser – por ejemplo – una ShellCode, : bash, sh, entre otros. El Desbordamiento del Buffer: Buffer OverFlow
• Programación defensiva. Cuidado con: strcpy() strcat() sprintf() scanf() sscanf() fscanf() vfscanf() vsprintf vscanf() vsscanf() streadd() strecpy() strtrns() • Evitarlas siempre que sea posible, casi todas tienen alternativas razonables.
Desbordamientos: defensa
gets() getchar(), fgetc(), getc(), read() Consejo, comprobar: • Siempre los límites! • Longitud de los datos antes de almacenarlos • No pasar datos excesivamente grandes a otras funciones Desbordamientos: más con las entradas
Seguridad en Java Seguridad General Arquitectura de la Seguridad Arquitectura de la Criptografía Política de permisos API para bloqueos de privilegios Certificados X.509 y listas de certificados revocados
JVM
Tres niveles de seguridad: Cargador de clases Verificador Gestores de seguridad Seguridad en Java
Seguridad en Java El cargador de clases (Class Loader), que determina como y cuando pueden cargar código los programas y garantiza que los componentes del sistema no han sido reemplazados.
El verificador de archivos de clases (Class file verifier), que garantiza que el código tiene el formato correcto, que el bytecode no viola las restriciones de seguridad de tipos de la JVM, que las pilas internas no puedan desbordarse ni por arriba ni por abajo y que las instucciones en bytecode tengan parámetos de tipos correctos.
El gestor de seguridad (Security Manager), que controla el acceso a los recursos en tiempo de ejecución. Los recursos sobre los que tiene control son multiples: E/S de red y ficheros, creación de cargadores de clases, manipulación de hilos de ejecución, ejecución de programas externos (del SO), detener la JVM, cargar código nativo en la máquina virtual, realizar determinadas operaciones en el entorno de ventanas o cargar ciertos tipos de clases.
Usando el Security Manager
Class MySecurityManager extends SecurityManager { . . . . . } try { System.setSecurityManager(new MySecurityManager(”java.policy")); } catch (SecurityException se) { System.out.println("SecurityManager already set!"); }
public boolean canRead() { SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkRead(path); } return fs.checkAccess(this, false); }
| Página siguiente |