Web : Ataque y Defensa. Claudio Salazar Estudiante Ing. Civil Informática UTFSM Pinguinux Team Temario 1. 2. 3. 4. 5. 6. 7. Introducción Cross Site Scripting (XSS) Inyección SQL Nuestro código en el servidor Ataques NG Previniendo .. Medidas en el servidor Introducción ¿ Seguridad, tanta importancia ? ● ● ● ● ● ● Robo de datos Violación de privacidad Personificación Ejecución remota de código Suplantación de contenido (phishing) Cambio de contenido (deface) Introducción ● ● 90% de los sitios son vulnerables. 75% de los sitios son blanco de XSS. En Chile .. La mayoría de los atacantes son extranjeros. ● Script kiddies efectúan mass deface. ● Linux lidera sistemas atacados. ● Existen organismos fiscales que velan por políticas de seguridad. ● go ? Cross-Site Scripting (XSS) “ En el futuro, XSS será el buffer overflow y JavaScript el shellcode “ Cross-Site Scripting (XSS) ● ● Tipo de ataque que aprovecha la mala validación de datos en páginas generadas dinámicamente. El atacante puede incluir código malicioso (JavaScript) que será ejecutado en el navegador de la víctima. Cross-Site Scripting (XSS) 2 tipos de XSS ● ● Persistente: Código inyectado que luego es guardado y mostrado cada vez que se visita el sitio. No Persistente: Código inyectado en una url aprovechando el método GET y entregado a la víctima ocultado en enlaces, preferentemente. Cross-Site Scripting (XSS) Descubriendo XSS ● Cualquier sitio que devuelva datos ingresados por el usuario puede ser vulnerable (form, db, etc). Probando con el conocido <script>alert(“xss”);</script> ● Cross-Site Scripting (XSS) Peligros de XSS Fácil de encontrar ● Útil para el phishing ● Pérdida de cookies ● Alteración de páginas hacia el cliente ● Patrones cada vez más creativos ● La gran mayoría de los usuarios tiene activado Javascript. ● IE más vulnerable que Mozilla Firefox. ● Cross-Site Scripting (XSS) Y ahora estamos en la Web 2.0, qué ? Ajax amplia el abanico de posibilidades en que un atacante pueda inyectar código. ● Ajax expone funciones internas al cliente ● Puentes (Ajax Bridging) pueden ocultar ataques a sitios externos. ● Ajax y XSS como w0rm. ● Cross-Site Scripting (XSS) Muy aburrido ? Inyección SQL Inyección SQL Se inyecta código SQL en variables ingresadas por el usuario que posteriormente son parte de consultas a la base de datos ● Un mal saneamiento de los datos nos lleva a ejecutar sentencias no esperadas en la DB ● No es problema de la DB. ● Inyección SQL El atacante no sabe la organización de la db, a menos que se trate de una aplicación open source. ● Mediante el ingreso de caracteres que tienen significado especial en la consulta, va recopilando información a partir de los errores. ● 1' OR 1 = 1; -- Inyección SQL Ejemplo 1 $r = pg_query($conexion, "SELECT * FROM usuarios WHERE usuario='{$user}' AND pass='{$pass}'"); $usr = pg_fetch_array($r); if($usr[0] == $user) echo "OK"; http://sitio.com/?user=admin&pass=meechemate http://sitio.com/?user=admin&pass=1' OR 1=1;-- Inyección SQL Datos importantes sobre la db en los esquemas de información. ● Oracle, MSSQL Server y Mysql están bien documentadas sus formas de explotación. ● Postgresql, la gran duda documentado o más seguro ? ● ¿ poco Nuestro código en el servidor Inclusión de archivos Una mala programación puede llevar a la inclusión de archivos con código tanto local como remota. ● Este tipo de ataque es el más peligroso. ● Permite inclusión de archivos de sistema con información relevante, si está al alcance del usuario del proceso. ● Inclusión de archivos 2 tipos de inclusión Local : Se pueden incluir archivos de sistema u otros como los que contienen información sobre db, usuarios, etc. ● Remota : Involucra la inclusión de archivos externos al servidor, probablemente programados por el atacante. ● Ejecución de comandos Ataque producido por mal saneamiento en los datos introducidos por el usuario y que pasan a ser parte de comandos al sistema. ● No sólo referente a PHP, cualquier lenguaje web que tenga acceso al sistema y antes visto en cgi-bins. ● Nuestro código en el servidor Vamos a estirar los dedos :) Ataques Nueva Generación Cross-Site Request Forgery CSRF se aprovecha de la autenticación de la víctima en un sitio para efectuar peticiones sin conocimiento de esta. ● Estas peticiones son de acuerdo a las acciones que el usuario puede hacer en el sitio ( comprar, agregar, pagar, etc) . ● http://sitio.com/vender.php?id=1000&usuario=87 Cross-Site Request Forgery Feed Injection Los lectores de feed también son vulnerables a ataques XSS y CSRF. Actúan de diferente manera: Lectores tratan '<' y '>' como literales. ● Lectores cambian entidades html a sus valores reales. Ademas copian en disco. ● Lectores evaden un tipo de feed, pero caen en otro. ● Blind SQL Injection Usa la misma vulnerabilidad de SQL Injection simple. ● En vez de ir recopilando información de los errores, compara la respuesta de la db frente a dos peticiones. ● Útil cuando el servidor no entrega información. ● Su lógica es preguntar al servidor y de acuerdo a la respuesta tomar caminos diferentes. ● Otros nuevos muchachos ● Xpath Injection ● LDAP Injection Previniendo .. Previniendo .. Cross-Site Scripting (XSS) Caracteres no alfanúmericos no interpretarlos (entidades html). ● Para la validación, aceptar lo que concuerda con el patrón y lo demás negarlo ( white-listing ). ● Validar input y sobre todo output. ● Como usuario, desactivar la carga de scripts no provenientes de la página que visitamos. ● Fijarnos a lo que lleva cada link o imagen. ● Previniendo .. Inyección SQL Validación correcta de las variables que serán parte de la consulta. ● Ocupar funciones destinadas a cada motor de base de datos. ● Ser cauteloso con la salida de errores. ● Privilegios mínimos del usuario que accede a la bd. ● Uso de consultas parametrizadas. ● Previniendo .. Inclusión de Archivos No llamar archivos de sitios de terceros. ● Si las páginas son llamadas por GET, hacer una contravalidación eficiente. ● Preferir el uso de constantes que de variables. ● Funciones como basename() previenen inclusiones locales (Divergencia entre SO). ● Previniendo .. Ejecución de comandos Ocupar funciones que provee PHP para prevenir comandos no deseados. ● Limitar uso de recursos para no consumir al servidor. ● Limitar comandos al uid de Apache( mediante PATH o permisos) ● Previniendo .. Cross-Site Request Forgery (CSRF) ● ● ● ● Uso de token especial CAPTCHA Redirección POST sobre GET Previniendo .. Generalidades Cuidado con los errores (Path Disclosure, XSS, etc). ● No confiar 100% en herramientas externas. ● Estar al tanto de nuevos vectores de ataque. ● Tener claro que funciones son peligrosas de usar y evitar su uso. ● Medidas en el servidor Medidas en el servidor Apache Denegar acceso a archivos fuente (*.inc, *.phps, *.bak, etc). ● Buena configuración de timeouts y conexiones para evitar DoS. ● Medidas en el servidor PHP Modo seguro (safe_mode). ● No permitir páginas de terceros (allow_url_fopen). ● No variables globales. ● No magic_quotes_gpc. ● Cuidado con llamadas a sistema. ● Cuidado uploads. ● Guardar información delicada en el servidor y no en archivos (db info). ● Medidas en el servidor Postgresql Configurar permisos claros para los usuarios. ● Si no es necesario, bloquear conexión remota a la bd. ● Medidas en el servidor A tener en cuenta .. Restringir Google Hacking. ● Usar otra capa de seguridad (mod_security, grasp core, suhosin). ● Entre hosting dedicado y compartido, dedicado. ● Estar al tanto de nuevas versiones del software ocupado. ● Tener conciencia de seguridad. ● Medidas en el servidor A tener en cuenta .. Restringir Google Hacking. ● Usar otra capa de seguridad (mod_security, grasp core, suhosin). ● Entre hosting dedicado y compartido, dedicado. ● Estar al tanto de nuevas versiones del software ocupado. ● Tener conciencia de seguridad. ● Links ● ● ● ● ● ● ● ● ● http://www.securityfocus.com http://blog.php-security.org http://www.milw0rm.com http://www.kriptopolis.org http://ha.ckers.org http://www.seguridad-informatica.cl http://www.insecuremag.com http://www.owasp.org http://www.honeypot.org Preguntas ?