Seguridad en Las Aplicaciones Web

Seguridad en Sistemas Informticos e Internet

Seguridad en las Aplicaciones Web

LabIS2http://www.lsi.us.es/~quivirDpto. Lenguajes y Sistemas InformticosUniversidad de Sevilla


ContenidoIntroduccinSeguridad en el ClienteSeguridad en el ServidorSeguridad en la AplicacinSeguridad en la Comunicacin


ContenidoIntroduccinAplicaciones WebCunta seguridad es necesaria?Amenazas ms importantes a las aplicaciones webGuas de seguridadSeguridad en el ClienteSeguridad en el ServidorSeguridad en la AplicacinSeguridad en la Comunicacin


ContenidoIntroduccinSeguridad en el ClienteCdigo mvilLenguajes de Macro: VBALenguajes de Script: JavaScript y VBScriptApplets JavaControles ActiveXSeguridad en el ServidorSeguridad en la AplicacinSeguridad en la Comunicacin


ContenidoIntroduccinSeguridad en el ClienteSeguridad en el ServidorServidor WebServidor de Bases de DatosLenguajes de servidorSeguridad en la AplicacinSeguridad en la Comunicacin


ContenidoIntroduccinSeguridad en el ClienteSeguridad en el ServidorSeguridad en la AplicacinControl de accesoValidacin de datos de entradaProgramacin seguraSeguridad en la Comunicacin


ContenidoIntroduccinSeguridad en el ClienteSeguridad en el ServidorSeguridad en la AplicacinSeguridad en la ComunicacinSSL


Programacin


IntroduccinAplicaciones WebCunta seguridad es necesaria?Amenazas ms importantes a las aplicaciones webGuas de seguridad


IntroduccinAplicaciones WebAplicaciones cliente/servidor que utilizan el protocolo HTTP para interactuar con los usuarios u otros sistemasEl cliente utilizado por los usuarios es habitualmente un navegadorLos 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


IntroduccinCunta seguridad es necesaria?La seguridad supone un coste econmico y de eficiencia. Hay que disponer de la adecuada, ni ms ni menosPara ello hay que tener en cuenta tres reglas:El riesgo cero no es prcticoHay diversas formas de mitigar el riesgoNo se puede gastar un milln para proteger un cntimo


IntroduccinAmenazas ms importantes: Top 10The Open Web Application Security Project (OWASP) The Ten Most Critical Web Application Security Vulnerabilities www.owasp.org/documentation/topten


IntroduccinTop Ten de amenazasEntrada no validadaControl de acceso rotoAdministracin de sesin y autentificacin rotaFallos de Cross Site Scripting (XSS)Desbordamiento del bufferFallos de inyeccinManejo inadecuado de erroresAlmacenamiento inseguroNegacin de servicioAdministracin de configuracin insegura


IntroduccinGuas de seguridadEs conveniente tener en cuenta unos principios de alto nivel al disear aplicaciones web:Validar la entrada y la salidaFallar con seguridadMantener un esquema de seguridad simpleUtilizar componentes de confianzaLa seguridad a travs de la oscuridad no funcionaMantener los privilegios al mnimo y separados


Seguridad en el ClienteCdigo mvilLenguajes de Macro: VBAJavaScriptVBScriptApplets JavaControles ActiveX


Seguridad en el ClienteCdigo mvilCdigo que circula por la red y se ejecuta en una mquina remotaAparece incrustado en un documento HTML. Un cliente de correo o un navegador que carguen el documento lo ejecutarn en la mquina clientePotencia 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


Seguridad en el ClienteCdigo mvilPuede estar incrustado directamente en el documento, caso de los lenguajes de script como JavaScript y VBScriptTambin puede residir en un servidor y ser invocado mediante una referencia en el documento, caso de las applets de Java o los controles ActiveXEl 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


Seguridad en el ClienteCdigo mvilHay cuatro tipos bsicos de cdigo mvil:Lenguajes de macro como Visual Basic for Applications (VBA)Scripts como JavaScript y VBScriptApplets de JavaControles ActiveXUn mtodo de proteccin comn es tener siempre actualizado el software


Seguridad en el ClienteLenguajes de Macro: VBAEs un lenguaje de macro propio de Microsoft Office, aunque otras aplicaciones lo han adoptadoPermite el acceso a todas las funciones de la aplicacin, incluyendo el acceso a discoLa macro est incrustada en el documento


Seguridad en el ClienteLenguajes de Macro: VBALas 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 perjuiciosAl ejecutarse podra copiarse en la plantilla normal, con lo que aparecera en cualquier documento creado con la aplicacin y se expandira al compartirse los documentosEjemplo: Melissa (1999), creado con VBA en un documento Word. Se reenviaba a los primeros 50 contactos de Outlook


Seguridad en el ClienteLenguajes de Macro: VBAPara 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


Seguridad en el ClienteJavaScriptFue diseado para aadir interactividad a una pgina webUn cdigo JavaScript tiene acceso nicamente a la informacin contenida en la pgina en la que est incrustadoEs 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


Seguridad en el ClienteJavaScriptEl nico problema serio est relacionado con los servicios de correo WebSi 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 tareasApareci por primera vez en Hotmail y provoc que los servicios de correo web decidieran neutralizar el cdigo JavaScript de los mensajes recibidos


Seguridad en el ClienteJavaScriptOtra 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 tieneLa 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 pesadoNetscape permite deshabilitar JavaScript de forma independiente para navegador y lector de correo


Seguridad en el ClienteVBScriptSlo funciona con Internet Explorer y Outlook, por lo que no es tan popular como JavaScriptOfrece una funcionalidad similar pero con una notable excepcin: puede interactuar con los controles ActiveX instalados en la mquinasta es la principal fuente de problemas, ya que carece de operaciones potencialmente peligrosasLos controles ActiveX pueden ser marcados como safe o unsafe for scripting de forma que se impida a los scripts acceder a ellos


Seguridad en el ClienteApplets JavaNormalmente 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 maliciosoExcepcin: 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 navegadorEfecto ms negativo: el applet crea hilos que consumen mucha memoria y/o CPU haciendo ms lento el sistema y llegando incluso a colapsarlo


Seguridad en el ClienteControles ActiveXSon la respuesta de Microsoft a las applets de JavaSlo funcionan bsicamente con Internet Explorer y OutlookLa seguridad de los controles ActiveX se basa en los certificados digitales. Los controles estn firmados digitalmente para garantizar su autenticidadAl 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


Seguridad en el Cliente


Seguridad en el ClienteControles ActiveXEl problema se da cuando un control est mal construido, proporcionando agujeros de seguridad a los atacantesUn 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 usuarioCuando 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


Seguridad en el ClientePrctica 1: Cdigo mvilCreacin de un formularioValidacin de datos con JavaScriptFormas de saltarse la validacin JavaScript


Seguridad en el ServidorServidor WebServidor de Bases de DatosLenguajes de servidor


Seguridad en el ServidorEl 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 actualizadasConfiguraciones por defecto inadecuadasActivacin de cuentas por defectoLas herramientas deben estar actualizadas y bien configuradas para impedir ataques a la aplicacin


Seguridad en el ServidorServidor WebProporciona muchos servicios y es muy probable que algunos de ellos no sean necesarios para el funcionamiento de la aplicacin webEn tal caso es conveniente deshabilitarlosPara ello el servidor dispone de mltiples opciones de configuracin que es conveniente adaptar a las circunstancias concretas de la aplicacin web


Seguridad en el ServidorServidor WebPrecauciones 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 sensibleSeguimiento de enlaces simblicos. Peligroso si se enlazan ficheros externos al rbol de documentos


Seguridad en el ServidorServidor WebPrecauciones a tener en cuenta (cont):Ejecucin de CGI. Slo debe permitirse a usuarios de confianza y restringirlo a un directorio especialServer 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


Seguridad en el ServidorServidor WebEjercicio: Configuracin de Apache


Seguridad en el ServidorServidor WebEs muy conveniente revisar peridicamente los ficheros de log (access_log y error_log en Apache) para detectar posibles ataques al servidor


Seguridad en el ServidorServidor WebEjercicio: Ficheros de log en Apache


Seguridad en el ServidorServidor de Bases de DatosProporciona 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 datosModificacin 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


Seguridad en el ServidorServidor de Bases de DatosHay que vigilar la configuracin por defecto del servidor, que puede incluir bases de datos y usuarios predefinidos que conviene eliminarAlgunas recomendaciones:No ejecutar el servidor como rootNo dar a ningn usuario salvo al root permiso de acceso a la tabla de usuariosAsegurarse de que el root tiene un passwordRestringir el acceso remoto al servidorNo dar a un usuario ms permisos que los estrictamente necesariosAlmacenar los datos sensibles de forma encriptada


Seguridad en el ServidorServidor de Bases de DatosEn el cdigo de la aplicacin hay que tener, entre otras, las siguientes precauciones:Validar las instrucciones SQL antes de enviarlas al servidorNo 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


Seguridad en el ServidorServidor de Bases de DatosEjercicio: Configuracin de MySQL


Seguridad en el ServidorLenguajes de servidorASP, JSP, PHPAumentan 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 datosEsta 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


Seguridad en el ServidorLenguajes de servidorHay 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 datosUna medida razonable consiste en sacar el cdigo fuente sensible fuera de la raz de la web


Seguridad en el ServidorLenguajes de servidorEjercicio: Errores en cdigo PHP


Seguridad en la AplicacinControl de accesoValidacin de datos de entradaProgramacin segura


Seguridad en la AplicacinControl de accesoUn aspecto muy importante de una aplicacin web es el control de acceso de los usuarios a zonas restringidas de la aplicacinAqu intervienen dos conceptos:AutentificacinAutorizacin


Seguridad en la AplicacinAutentificacinEs el proceso de determinar si un usuario es quien dice serEsto se puede hacer de varias maneras. Algunas de ellas son:Autentificacin HTTP bsicaAutentificacin basada en la aplicacin


Seguridad en la AplicacinAutentificacin HTTP bsicaCuando 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 contraseaCuando se pulsa el botn de envo estos datos llegan al servidor que comprueba si son correctos y en caso afirmativo sirve el recurso solicitado


Seguridad en la Aplicacin


Seguridad en la AplicacinAutentificacin HTTP bsicaVentajas:Es muy simple de implementarSe pueden fijar restricciones de acceso por usuario y contrasea o por otros conceptos como por ejemplo el dominio o direccin IP de la mquinaInconvenientes: Los datos viajan por la red sin encriptarNo se puede hacer logout, la nica forma es cerrar el navegadorNo hay control sobre el diseo de la ventana de dilogo


Seguridad en la AplicacinAutentificacin HTTP bsicaEjercicio: proteccin de un directorio del servidor


Seguridad en la AplicacinPrctica 2: Autentificacin HTTP bsicaCreacin de una pgina webCreacin de un usuarioCreacin de un fichero .htaccessConfiguracin del servidor web Apache


Seguridad en la AplicacinAutentificacin basada en la aplicacinLa 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 stasEs ms costosa pero ms flexible ya que permite establecer diferentes permisos y niveles de acceso en funcin del usuario que solicita la autentificacin


Seguridad en la AplicacinPasswordsSiempre 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 atacantesAlmacenar los passwords de forma segura, protegiendo el acceso a la base de datosSeguir reglas de seguridad para su eleccinBloquear una cuenta cuando se detecta un nmero determinado de intentos de acceso incorrectosActualizar los passwords peridicamente y mantener un histrico para evitar repeticiones


Seguridad en la AplicacinPasswordsCualquier sistema que requiera autentificacin debe tener una poltica de recuperacin de passwords en caso de olvido del usuarioEsto se puede hacer de dos formas:AutomticamenteA travs de tcnicos de soporte


Seguridad en la AplicacinPasswordsEn el caso automtico hay varias estrategias:Plantear durante el registro del usuario varias preguntas a las que slo l puede responderEnviar el password por correo electrnico. Es recomendable que tenga fecha de expiracin y se pida su cambio cuando el usuario se conecteComunicar el password por telfono al usuario a requerimiento del mismoDeben registrarse todos los intentos de recuperacin y fijar un lmite de tiempo pasado el cual sera preciso recurrir al tcnico


Seguridad en la AplicacinPasswordsEn el caso del tcnico hay que prever el servicio a personas de diferentes pases con lenguas diferentesLa intervencin humana da mayor seguridad, pero es ms costosa y ms molesta para el usuarioUna alternativa a la presencia fsica puede ser el uso del fax para enviar la documentacin que certifique la identidad del usuario


Seguridad en la AplicacinSesionesUna vez que el usuario se ha autentificado introduciendo su nombre de usuario y su clave, es preciso mantener esta autentificacin en cada conexin subsiguientePara 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


Seguridad en la AplicacinSesionesEl mecanismo es el siguiente:Una vez autentificado, al usuario se le asigna un identificador de sesinEste identificador acompaar invisiblemente a cada peticin del usuario, con lo cual se garantizar que la peticin proviene de un usuario previamente autentificadoEl identificador de sesin se suele almacenar en la propia mquina del cliente, mediante una cookieSlo se debe almacenar el identificador de la sesin; cualquier otro dato del usuario se almacenar en el servidor


Seguridad en la AplicacinSesionesLa gestin de las sesiones es responsabilidad del programador. Normalmente los lenguajes de servidor disponen de funciones diseadas especficamente para elloEn PHP se dispone de las siguientes funciones:session_startsession_registersession_is_registeredsession_unregistersession_destroy


Seguridad en la AplicacinSesionesUn buen sistema de gestin de sesiones debe:Establecer un tiempo lmite de vida para la sesinRegenerar el identificador de sesin cada cierto tiempoDetectar intentos de ataque de fuerza bruta con identificadores de sesinRequerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importanteProteger los identificadores de sesin durante su transmisinDestruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico


Seguridad en la AplicacinSesionesEjercicio: sesiones en PHP


Seguridad en la AplicacinAutorizacinEs 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


Seguridad en la AplicacinAutorizacinDisear el mecanismo de control de acceso exige:Determinar la informacin que ser accesible por cada usuarioDeterminar el nivel de acceso de cada usuario a la informacinEspecificar un mecanismo para otorgar y revocar permisos a los usuariosProporcionar 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


Seguridad en la AplicacinAutorizacinModelos 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 discrecinControl 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 informacinControl de Acceso Basado en Roles: cada usuario tiene un rol dentro de la organizacin y en funcin de l unos permisos de acceso


Seguridad en la AplicacinAutorizacinPara la implementacin del mecanismo de control de acceso en la aplicacin suele recurrirse al uso de bases de datos


Seguridad en la AplicacinPrctica 3: Control de accesoDisear un mecanismo de control de accesoDefinir usuariosEspecificar nivel de acceso de los usuarios


Seguridad en la AplicacinValidacin de datos de entradaEl problema ms frecuente que presentan las aplicaciones web es no validar correctamente los datos de entradaEsto da lugar a algunas de las vulnerabilidades ms importantes de las aplicaciones, como la Inyeccin SQL, el Cross-Site Scripting y el Buffer OverflowVeamos los siguientes aspectos:Fuentes de entradaInyeccinEstrategias de proteccinVulnerabilidades especficas


Seguridad en la AplicacinFuentes de entradaLos datos de entrada pueden provenir de cuatro fuentes diferentes:Cadenas URLCookiesCabeceras HTTPCampos de formularios


Seguridad en la AplicacinFuentes de entrada cadenas URLCuando 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=12345Es muy fcil modificar esta cadena:http://www.victim.com/example?accountnumber=67891


Seguridad en la AplicacinFuentes de entrada cadenas URLLa 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 URLEste problema se da tambin en los hipervnculos que incluyen parmetrosSiempre 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


Seguridad en la AplicacinFuentes de entrada - cookiesEs 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 cookieCookie: 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


Seguridad en la AplicacinFuentes de entrada - cabecerasLas cabeceras HTTP contienen informacin de control enviadas entre el cliente y el servidor. Por ejemplo,Host: www.someplace.orgPragma: no-cacheCache-Control: no-cacheUser-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14Referer: http://www.someplace.org/login.phpContent-type: application/x-www-form-urlencodedContent-length: 49


Seguridad en la AplicacinFuentes de entrada - cabecerasSi 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 verificadasPor ejemplo, sea la siguiente cabecera:Accept-Language: esSi 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


Seguridad en la AplicacinFuentes de entrada - formulariosLos 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:

Este elemento podra modificarse as:

con el consiguiente riesgo para la aplicacin si el valor no se chequea adecuadamente


Seguridad en la AplicacinFuentes de entrada - formulariosLos campos ocultos (HIDDEN) tambin son vulnerables a este ataque, por lo que no deben utilizarse para almacenar informacin sensibleEs mucho ms seguro utilizar sesiones y almacenar la informacin sensible en el servidorEjemplos de campos ocultos vulnerables:


Seguridad en la AplicacinFuentes de entrada - formulariosEjercicio: validacin de datos de formularios con la herramienta WebGoatDescarga e instalacin de WebGoatEjercicio: hidden field tamperingEjercicio: unchecked emailEjercicio: JavaScript validation


Seguridad en la AplicacinInyeccinConsiste en inyectar en la aplicacin datos introducidos por el usuario. Esto es muy habitual y de por s no es peligroso


Seguridad en la AplicacinInyeccin de datosEjemplo: 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 "Bienvenido/a, $username.";Una vez identificado el usuario se convierte en:print "Bienvenido/a, Antonio.";


Seguridad en la AplicacinConectores y payloadIdea: suministrar datos que al ser inyectados en la aplicacin causen un efecto particularEl ataque est completamente contenido en los datos suministrados por el atacante, que se pueden dividir en tres partes:Conector de prefijoPayloadConector de sufijoEl ataque est contenido en el payload y los conectores lo encajan en la aplicacinPara elegirlos es preciso un amplio conocimiento del lenguaje, las herramientas y las tcnicas utilizadas en la aplicacin


Seguridad en la AplicacinConectores y payloadEjemplo: consulta SQL para una interfaz de identificacin de usuariosql = "SELECT * FROM tablausuarios WHERE login = '$userLogin' AND password = '$userPassword';Si inyectamos un ataque en el campo userLogin con los siguientes componentes:

prefijopayloadsufijoOR1=1OR login=


Seguridad en la AplicacinConectores y payloadobtendremos la consulta SQL:SELECT * FROM tablausuarios WHERE login = '' OR 1=1 OR login ='' AND password = ''que nos devolver todos los usuarios de la tabla


Seguridad en la AplicacinConectores y payloadCon un mayor conocimiento podemos modificar el ataque para reducir el nmero de caracteres empleados, que podra estar limitado. Por ejemplo, el ataque

producira la consulta SQL:SELECT * FROM tablausuarios WHERE login = '' OR '1'='1' AND password = ''


Seguridad en la AplicacinConectores y payloadLa eleccin de los conectores puede verse facilitada por factores como acceso al cdigo fuente o mensajes de error detalladosMs importante que esto es el hecho de utilizar tcnicas de programacin conocidas en el desarrollo de las aplicaciones


Seguridad en la AplicacinEstrategias de proteccinExisten tres modelos posibles a la hora de disear una estrategia de validacin de datos:Aceptar nicamente datos vlidos conocidosRechazar datos no vlidos conocidosSanear todos los datos


Seguridad en la AplicacinEstrategias de proteccinAceptar 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


Seguridad en la AplicacinEstrategias de proteccinAceptar nicamente datos vlidos conocidos. En general hay que chequear lo siguiente:Tipo de datoLongitud mxima y mnimaDatos obligatoriosSi hay una lista enumerada de posibles valores, comprobar que est en ellaSi hay un formato o plantilla especfico, comprobar que lo cumpleSi es texto libre, que slo contiene caracteres vlidosSi se permiten caracteres peligrosos, sanearlosDeben considerarse los valores por separado pero tambin teniendo en cuenta que pueden unirse para formar, por ejemplo, una consulta SQL


Seguridad en la AplicacinEstrategias de proteccinRechazar datos no vlidos conocidos. Implica conocer todos los posibles datos peligrosos, lo cual es muy difcilSanear 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

Seguridad en la AplicacinEstrategias de proteccinNunca 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 servidorConceptos errneos sobre la validacin en el cliente:El atributo MAXLENGTH limitar los caracteres que el usuario puede introducirEl atributo READONLY evitar que el usuario pueda modificar un valorLos campos de tipo HIDDEN no se pueden modificarLas cookies no se pueden modificarLas listas desplegables o botones de radio limitan los valores de entradaTodos los campos del formulario sern enviadosSlo los campos del formulario sern enviados


Seguridad en la AplicacinPrctica 4: Validacin de datosValidacin de datos en el servidorCreacin de un formulario en PHP con validacin de los datos de entradaUso de expresiones regulares para validar los datos de entrada


Seguridad en la AplicacinVulnerabilidades especficasLas vulnerabilidades comunes ms peligrosas que resultan de una falta de proteccin adecuada ante los datos de entrada son:Inyeccin SQLInyeccin de rdenes del SOInyeccin HTML (Cross-site Scripting o XSS)Path TraversalBuffer Overflow


Seguridad en la AplicacinInyeccin SQLConsiste 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 = 23Si el valor es 23; DROP TABLE users la consulta es:SELECT titulo FROM libros WHERE codigo = 23; DROP TABLE usersque destruira la tabla de usuarios de MySQL


Seguridad en la AplicacinInyeccin SQLSea 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


Seguridad en la AplicacinInyeccin SQLSe 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


Seguridad en la AplicacinInyeccin SQLLa inyeccin SQL puede utilizarse para:Cambiar valores de las consultasConcatenar varias consultasAadir llamadas a funcin y procedimientos almacenados a una consultaPara 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


Seguridad en la AplicacinInyeccin SQLEjercicio: inyeccin de una orden SQL desde un formulario


Seguridad en la AplicacinInyeccin de rdenes del SOCasi todos los lenguajes de programacin disponen de funciones que permiten la ejecucin de rdenes del Sistema OperativoEn 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 ejecutadasAlterar los parmetros pasados a las rdenes del sistemaEjecutar rdenes adicionales


Seguridad en la AplicacinInyeccin de rdenes del SOSea, 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 ordenls /tmp; cat /etc/passwd


Seguridad en la AplicacinInyeccin de rdenes del SOUna 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 serals /tmp; cat /etc/passwd


Seguridad en la AplicacinInyeccin de rdenes del SOLa mejor proteccin contra este ataque es limitar toda informacin pasada a las rdenes del sistema nicamente a valores conocidosSi 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 rdenesTambin, y en la medida de lo posible, deben utilizarse las funciones de biblioteca en lugar de invocar rdenes del SO


Seguridad en la AplicacinInyeccin de rdenes del SOEjercicio: inyeccin de una orden del sistema operativo desde un formulario


Seguridad en la AplicacinInyeccin 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?alert(document.cookie)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:document.write('

Seguridad en la AplicacinInyeccin HTML (Cross-site Scripting)Hay varios tipos de cosas que se pueden insertar en el cdigo HTML de esta manera:Marcas HTML, como , , o . El efecto se produce cuando el texto se visualiza en el navegador de otro usuarioEventos, como ONCLICK, asociados habitualmente a elementos de formulario


Seguridad en la AplicacinInyeccin HTML (Cross-site Scripting)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()


Seguridad en la AplicacinInyeccin HTML (Cross-site Scripting)Ejemplo: el siguiente cdigo muestra el campo mensaje de un registro recuperado de una tablaprint ;print $fila[mensaje];print ;Si el mensaje contiene caracteres HTML puede ser peligroso. Para solucionarlo se modifica el cdigo:print ;print htmlspecialchars($fila[mensaje]);print ;


Seguridad en la AplicacinInyeccin HTML (Cross-site Scripting)Esta solucin no siempre es vlida. En el cdigo//llamada: pag.php?imagen=javascript:alert(document.cookie);print ;// resultado: 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 ;


Seguridad en la AplicacinInyeccin HTML (Cross-site Scripting)Ejercicio: almacenamiento de un script en el servidor y posterior visualizacin del mismo


Seguridad en la AplicacinPath TraversalUna 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/passwdPara 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


Seguridad en la AplicacinPath TraversalSea 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


Seguridad en la AplicacinPath TraversalPara evitar estos ataques hay que utilizar las funciones de normalizacin de rutas que suelen tener los lenguajesEn 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);


Seguridad en la AplicacinPath TraversalOtra defensa contra los nombres de ficheros incorrectos en PHP es la directiva de configuracin open_basedir:open_basedir = /alguna/ruta // en php.iniPHP limitar las operaciones sobre ficheros al directorio especificado y sus subdirectorios. As, por ejemplo,include (/alguna/ruta/lib.php); // permitidoinclude (/otra/ruta/lib.php); // da un error // de ejecucin


Seguridad en la AplicacinPath TraversalEjercicio: acceso a ficheros del sistema


Seguridad en la AplicacinBuffer OverflowEste ataque consiste en corromper la pila de ejecucin de una aplicacin enviando unos datos de entrada especialmente preparados con tal finEl objetivo es conseguir la ejecucin de un cdigo enviado por el atacante y tomar el control de la mquinaEstas vulnerabilidades no son fciles de detectar y, de hacerse, son muy difciles de explotar


Seguridad en la AplicacinBuffer OverflowLas 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 herramientasTambin 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


Seguridad en la AplicacinProgramacin seguraPara 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 variablesGestin de erroresProteccin de informacin


Seguridad en la AplicacinInicializacin de variablesSea el siguiente cdigo:if (comprueba_privilegios())$superuser = true;Una llamada de la forma pagina.php?superuser=1permitira obtener privilegios de superusuario. Este problema se soluciona dando un valor inicial a la variable $superuser:$superuser = false;if (comprueba_privilegios())$superuser = true;


Seguridad en la AplicacinInicializacin de variablesEn general es recomendable inicializar todas las variables antes de usarlasEn 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


Seguridad en la AplicacinInicializacin de variablesTambin se puede deshabilitar register_globals en el fichero php.iniLa directiva register_globals establece si se admite o no la creacin automtica de variables globalesA partir de PHP 4.2.0 el valor por defecto de esta directiva es off, que es el valor recomendablePara acceder a las variables globales se deben utilizar los arrays globales $_SERVER, $_ENV, $_REQUEST, $_GET, $_POST, $_COOKIE, $_FILES, $_SESSION y $_GLOBALS


Seguridad en la AplicacinInicializacin de variablesPHP 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 ESEn 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


Seguridad en la AplicacinInicializacin de variablesEjercicio: error en la autentificacin de usuarios


Seguridad en la AplicacinGestin de erroresLos mensajes de error son una fuente de informacin muy importante para los atacantes. Pueden proporcionar informacin sensible que les permita refinar sus ataquesEn 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 = offlog_errors = onerror_log = /var/log/php_errors.logLos errores irn al fichero especificado en lugar de mostrarse en la pantalla


Seguridad en la AplicacinGestin de erroresEjercicio: localizacin de pginas con errores


Seguridad en la AplicacinProteccin de informacinToda 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 URLEn 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/myappDe esta forma, aunque se revele el cdigo fuente de los programas, no se mostrar informacin que comprometa al sistema


Seguridad en la AplicacinProteccin de informacinDebe 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 aplicacinHay que suprimir las rdenes de depuracin colocadas en el cdigo durante su desarrolloDeben 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


Seguridad en la AplicacinProteccin de informacinEjercicio: revelacin de informacin en el cdigo fuente


Seguridad en la ComunicacinSSLSSL (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 webPodemos reconocer una conexin HTTP sobre SSL porque aparece el prefijo https en lugar de http en la URL


Seguridad en la ComunicacinSSLLa 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


Seguridad en la ComunicacinSSLSSL no es un protocolo simple sino que tiene dos niveles de protocolosEl protocolo Record proporciona servicios de seguridad bsica a varios protocolos de nivel ms alto, entre ellos HTTP


Seguridad en la ComunicacinSSLSSL 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


Seguridad en la ComunicacinSSL


Seguridad en la AplicacinPrctica 5: SSL en ApacheCreacin de un certificado digitalConfiguracin de Apache para utilizar el certificado en una conexin SSL


Configuraciones por defecto inadecuadas: ficheros de ejemplo, visualizacin de mensajes de errorActivacin de cuentas por defecto: admin., system, test, guest, demoNo ejecutar el servidor como root: crear un usuario especial para elloRequerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importante (por ejemplo una transferencia de dinero)Destruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico (por ejemplo un quiosco web)Para evitar perjuicios al dueo de la cuenta se puede levantar el bloqueo al cabo de unas horasPara recuperar el password el usuario deber responder a las preguntas correctamenteComunicar el password por telfono al usuario a requerimiento del mismo. Es ms seguro y puede ser registradoPara recuperar el password el usuario deber responder a las preguntas correctamenteComunicar el password por telfono al usuario a requerimiento del mismo. Es ms seguro y puede ser registradoRequerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importante (por ejemplo una transferencia de dinero)Destruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico (por ejemplo un quiosco web)Requerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importante (por ejemplo una transferencia de dinero)Destruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico (por ejemplo un quiosco web)Especificar un mecanismo para otorgar y revocar permisos a los usuarios (manual, automtico, mediante una herramienta de administracin)El propietario de una informacin puede cambiar sus permisos a su discrecin, con lo cual el control se escapa un tanto de los administradoresEl propietario de una informacin puede cambiar sus permisos a su discrecin, con lo cual el control se escapa un tanto de los administradoresRequerir una nueva autentificacin del usuario cuando vaya a realizar una operacin importante (por ejemplo una transferencia de dinero)Destruir la cookie al finalizar la sesin para evitar el acceso de otro usuario en un entorno pblico (por ejemplo un quiosco web)

Seguridad en Las Aplicaciones Web

Documents

Transcript of Seguridad en Las Aplicaciones Web