web ataque y defensa 112007
Post on 11-Dec-2015
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
Claudio SalazarEstudiante Ing. Civil Informática UTFSM
Pinguinux Team
Web : Ataque y Defensa.
Temario
1. Introducción2. Cross Site Scripting (XSS)3. Inyección SQL4. Nuestro código en el servidor5. Ataques NG 6. Previniendo ..7. 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=meechematehttp://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 ¿ poco documentado o más seguro ?
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 ?
top related