Web : Ataque y Defensa. - csrg

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 ?