Tipo de artículo: Artículo original Temática: Seguridad informática
Recibido: 25/08/2019 | Aceptado: 10/09/2019 | Publicado: 22/09/2019
Estudio de ciberataques basados en la modificación del campo de
encabezado de petición http referer
Study of cyber attacks based on the modification of the http referer
request header field
Dairis Almaguer Pérez1*, Henry Raúl González Brito 2
1 Dirección de Seguridad Informática, Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, Km. 2 ½. Torrens, municipio de La Lisa. La Habana, Cuba. [email protected]
2 Dirección de Seguridad Informática, Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, Km. 2 ½. Torrens, municipio de La Lisa. La Habana, Cuba. [email protected]
* Autor para correspondencia: [email protected]
Resumen
Las aplicaciones web representan una gran parte de los servicios informáticos disponibles en la sociedad moderna. Por este motivo, se incrementa la necesidad de garantizar niveles de seguridad apropiados en ellas. Dentro de los principales vectores de ciberataques utilizados contra las aplicaciones web se encuentra la modificación del campo de encabezado de petición HTTP Referer. Desafortunadamente, las vulnerabilidades y problemas de seguridad asociados al Referer se tratan de forma separada en la literatura, lo que impide que desarrolladores y otros interesados, dispongan de todos los elementos para mitigar y resolver los problemas de seguridad vinculados al mismo. El objetivo del trabajo, por tanto, se enfocó en realizar un estudio de los principales ciberataques y problemas de seguridad que involucran al Referer y proponer medidas para su contención. Se utilizaron para la investigación, los métodos histórico-lógicos, análisis-síntesis y el experimento. Se concluye que deben aplicarse métodos sistemáticos, tanto en el desarrollo como en la administración de las aplicaciones web, para resolver los problemas de seguridad asociados a la gestión del Referer.
Palabras clave: Referer, Ciberseguridad, SEO spam.
Abstract
developers and other stakeholders from having all the elements to mitigate and resolve security issues related to it. The objective of the work was therefore to carry out a study of the main cyber attacks and security problems involving the Referer and propose measures for their containment. They were used for research, historical-logical methods, analysis-synthesis and experiment. It is concluded that systematic methods, both in the development and administration of web applications, must be applied to solve the security problems associated with the management of the Referer
Keywords: Referer, Cybersecurity, SEO spam.
Introducción
Las aplicaciones web representan una gran parte de los servicios informáticos disponibles en la sociedad moderna. Por este motivo, se incrementa la necesidad de garantizar niveles de seguridad apropiados en ellas, las cuales, por causa de su crecimiento, son el blanco preferido de los ciberdelincuentes (Kent, Tanner, & Kabanda, 2016; Vasek, Wadleigh, & Moore, 2016). Las vulnerabilidades son la principal causa de que las aplicaciones web puedan ser atacadas con éxito. Reportes de organizaciones y gobiernos alrededor de todo el mundo coinciden en este hecho (Garais & Enaceanu, 2016; Jerković, Vranešić, & Dadić, 2016; OWASP, 2013).
Los ciberataques se clasifican de diversas maneras, según sus efectos, vectores de intrusión utilizados o vulnerabilidades explotadas (OWASP, 2013; Salini & Shenbagam, 2015). Dentro de estas se encuentran las secuencias de comandos en sitios cruzados (XSS), los secuestros de clic y de sesiones, las inyecciones de código, la falsificación de peticiones en sitios cruzados (CSRF), entre otros.
Ataques del tipo Referer spam (Chandra & Suaib, 2014), CSRF (Chaudhari & Tijare, 2016), XSS (Hydara, Sultan, Zulzalil, & Admodisastro, 2015), Phishing (Tewari, Jain, & Gupta, 2016) y los que atentan contra la privacidad personal (Malandrino et al., 2013) tiene en todas o muchas de sus variantes un componente fuerte en la manipulación del campo de encabezado de petición HTTP Referer.
Materiales y métodos o Metodología computacional
Para la realización del trabajo se emplearon los siguientes métodos de investigación:
Histórico-lógico: Se utilizó para el estudio de la evolución de los problemas de seguridad y ciberataques asociados al campo de encabezado de petición HTTP Referer.
Análisis-Síntesis: Se empleó para extraer las características principales y comparar los diferentes ciberataques y determinar los puntos comunes, así como los principales métodos de mitigación de los ciberataques.
Experimentos: Se realizaron, en el entorno controlado del Laboratorio de Hacking Ético de la UCI, varios experimentos para simular estos ciberataques y comprobar las soluciones para su mitigación.
Resultados y discusión
Campo de Encabezado de Petición HTTP Referer
El campo de encabezado de petición HTTP Referer contiene la URI del recurso A desde el cual se realizó el vínculo al recurso solicitado B (Group, 1999). Esta información es enviada por el Agente de Usuario (AU) que normalmente es un navegador web, pero pudiera ser también programas como cURL o Wget, entre otros. El envío de esta referencia por el AU permite que el servidor de aplicaciones Web conozca desde donde está enlazando sus recursos con el objetivo de hacer comprobaciones de autenticación, cachés, elaboración de estadísticas de acceso, etc.
En la RFC 2616, sección 14.36, se encuentra la descripción del campo Referer y en la sección 15.1.3 se abordan consideraciones de seguridad que deben cumplir los AU, como por ejemplo no incluir el Referer cuando se pase de HTTPS a HTTP por los problemas de exposición de información sensible.
La forma correcta de nombrar el campo es Referer pues así es como aparece en la RFC 2616. Fue incluido de este modo por una equivocación ortográfica, pero es como se implementó en el protocolo. Los otros elementos Referrer (metadato y property del DOM) aparecieron después y se nombraron por la W3C de otro modo. A continuación, se analizarán los principales ataques y problemas que presentan el Referer.
Referer Spoofing
El envenenamiento del Referer, más conocido por su denominación en inglés como Referer Spoofing, es una práctica que consiste en modificar su valor para distintos fines. Como todo campo de encabezado de petición HTTP, este puede ser modificado desde el AU.
información enviada por el AU es totalmente fiable y realmente es falso. El Referer Spoofing por tanto, es la base para el lanzamientos de ataques contra el Referer y comprender esto es el primer paso para evitar los efectos.
Referer y la privacidad de los usuarios
Desde hace varios años se viene denunciando la utilización del Referer para la recolección indiscriminada de información personal (figura 1). En los servidores Web queda registrada la información de la página web donde estaba el usuario navegando previamente. Suficientes datos recolectados de este modo pueden llevar a la creación de un perfil de navegación que posibilita distinguir, solamente con analizar las trazas de navegación web, a una persona específica (Fett, Küsters, & Schmitz, 2015; Malandrino et al., 2013).
Los debates alrededor del uso del Referer como medio de seguimiento de los cibernautas han hecho posible que los AU tengan sencillos mecanismos para enmascarar (spoof) el Referer. En la actualidad hay extensiones (plugins o componentes) que permiten que los usuarios puedan eliminar el Referer de las peticiones que se envían al servidor. Una búsqueda de extensiones en navegadores como Firefox, Chrome, Opera y otros, arroja varios resultados que permiten modificar o eliminar el Referer. A nivel de navegador, por tanto, puede ser solucionado este problema en el caso de usuarios preocupados por mantener ciertos niveles de privacidad.
Figura 1. Registro de una petición de usuario conteniendo los datos de la búsqueda que realizó en Internet.
Elaboración propia.
Ciberataques contra el posicionamiento SEO
El posicionamiento SEO (Search Engine Optimization) tiene como objetivo situar una aplicación web en los primeros puestos de los resultados que muestran los buscadores de Internet como Google, Yahoo, Bing, Altavista, entre otros. Los enlaces que aparecen al principio de las listas de resultados, tienen más posibilidades que sean visitadas que las últimas. Se han hecho estudios que demuestran que los usuarios normalmente no pasan de la primera página de resultados de Google (Liao et al., 2016).
es un componente fundamental para que los algoritmos de los buscadores prioricen los enlaces. A continuación, se analizará cómo se manifiesta este problema:
Referer spam básico para mejorar el posicionamiento SEO
Existen aplicaciones web y servicios vinculados que se encargan de facilitar a los internautas información sobre los vínculos que reciben de otras aplicaciones en Internet. Esto se hace con propósitos de reconocimiento, publicidad y también para mejorar el posicionamiento SEO. Para extraer esta información se analizan automáticamente los registros de acceso (logs) a la aplicación web y se extraen los Referer correspondiente, que luego serán publicados, también automáticamente.
Turbias empresas consultoras de posicionamiento SEO conocen esto y aprovechan la técnica de Referer spoofing para bombardear a las aplicaciones web con falsos Referer con la esperanza de que los webmaster y otros responsables, visiten estos enlaces para comprobarlas (Mansoori, Hirose, Welch, & Choo, 2016).
Un ejemplo de ello puede verse en la figura 2, donde aparece una sección de reporte automático que está emitiendo hacia Internet una institución educativa real de Asia. En color rojo se marcan los Referer falsos. Puede apreciarse además como se concentran estos Referer falsos en las primeras posiciones en detrimentos de los reales.
Figura 2. Referers falsos en un informe basado en Webalizer. Elaboración propia a partir de Internet.
Los administradores de aplicaciones web muchas veces visitan estos enlaces para comprobarlos y en este momento se generan el tráfico esperado por los ciberdelincuentes. En ocasiones, se utilizan bot propios para automatizar el proceso de comprobación de los Referer y también se genera tráfico, pero quizás no tan valioso como el que pueden producir otras técnicas, desafortunadamente, más efectivas que veremos a continuación:
Referer spam con Google Analytic para mejorar el posicionamiento SEO
de seguimiento llamado Universal Analytic (UA) por cada aplicación Web y un script que se debe colocar en cada página que se quiera registrar las estadísticas de acceso. A través del código de seguimiento de UA, se envía una notificación a Google cada vez que es accedido el recurso supervisado. En la figura 3 se muestra un ejemplo del script de código UA:
Figura 3. Código script que provee Universal Analytic para el registro de peticiones a los recursos de las
aplicaciones web. Tomado de Google Analytic.
El objetivo es el mismo, poblar las estadísticas de tráfico de la aplicación web con referencias falsas realizadas por bot, afectando el análisis de la situación real de la aplicación web (Fetterly, Manasse, & Najork, 2004). En este caso, las trazas o log son gestionadas por Google y deben ser analizadas para evitar que la aplicación web se asocie a otras de reprobable reputación (figura 4).
Figura 4. Ejemplo de reportes de Google Analytic contaminados con Referer spam. Tomado de Internet.
enviar los datos directamente. Uno de los métodos más efectivos para evitar estos ataques, es el bloqueo de los dominios detectados como dominios spam.Listas como las de Perishablepress.comy Piwik(https://github.com/piwik/) se actualizan periódicamente y pueden servir para estos propósitos.
En el caso de los de Ghost Referral, la única solución actualmente es configurar filtros efectivos en Google Analytic para que descarten estas referencias en los reportes visualizados.
Debe evitarse por todos los medios posibles, publicar información de accesos a la aplicación de manera automática, sobre todo aquellos elementos técnicos como el Referer o el AU. Si es necesario publicar estadísticas, estas deben ser generadas directamente por el sistema, por ejemplo, el país de origen de la petición a partir de la dirección IP o la hora registrada por el servidor web.
Referer spam para atacar el posicionamiento SEO alcanzado por una aplicación web.
El posicionamiento SEO está dirigido a las personas (SEO orgánico o natural), por ese motivo, la utilización de técnicas fraudulentas y basadas en bot para mejorar este posicionamiento esrechazado por todos y los buscadores penalizan estas acciones, colocando en listas negras a los dominios y aplicaciones web que se dediquen a estos ciberataques.
Como parte de ilegales prácticas comerciales y otros propósitos, ciberatacantes se hacen pasar por aplicaciones web legítimas para invadir de Referer spam los servidores y servicios como Google Analytic con el objetivo de que estas aplicaciones web sean reportadas y bloqueadas del ranking de los buscadores.
Malas prácticas de programación
Las malas prácticas de programación son frecuentemente y muchas veces son causadas por carencias de conocimientos sobre programación segura. Las que más contribuyen a la aparición de vulnerabilidades que son aprovechadas por los ciberatacantes para explotar el campo Referer son:
Aplicaciones web que pasan los ID de sesión como parámetros de la URL: El ID de sesión y otros datos
viajan como parte del Referer a otro servidor Web. Un ejemplo muy sencillo puede ser una aplicación web para gestionar correos electrónicos. Cuando el usuario visita el enlace contenido en un correo, como este enlace se abrió con la aplicación web de correo electrónico, todos los datos que aparecen en la URL se transmiten en el Referer en texto plano por supuesto y queda registrado entonces en las trazas de la aplicación web visitada.
Inyección de código dañino para la realización de ataques XSS (entre otros): Como el Referer apenas se
Utilización del Referer para controles de seguridad: El Referer nunca se implementó para garantizar la
seguridad de las aplicaciones web, sin embargo, muchos desarrolladores quieren usarlo para este propósito. Por ejemplo, proveer determinadas funcionalidades si la petición es enlazada desde cierta página o dominio o evitar ataques de clickjacking o CSRF. Esto es una práctica peligrosa y muy vulnerable.
Para evitar estos errores y malas prácticas de programación, debe considerarse siempre como inseguro, todos los elementos contenidos en una petición HTTP pues todos pueden ser manipulado y falseados.
Conclusiones
En la actualidad, el Referer es objeto de diversas manipulaciones por parte de atacantes para realizar sobre todo ejecución de ciberataques de SEO Spam en todas de sus variantes. Las malas prácticas de programación, son una de las mayores dificultades con las que se enfrentan los especialistas y consultores de seguridad.
En el trabajo se realizó un análisis de los principales problemas de ciberseguridad que están vinculados a la manipulación del Referer y se brindaron elementos que contribuyen a su solución. Como trabajo futuro, se publicará un estudio del comportamiento de estos ataques en el entorno nacional.
Referencias
1. Chandra, A., & Suaib, M. (2014). A Survey on Web Spam and Spam 2.0. International Journal of
Advanced Computer Research, 4(2), 634.
2. Chaudhari, K., & Tijare, M. M. (2016). Prevention of CSRF Attack using STG pattern and JSED.
International Journal of Applied Engineering Research, 11(7), 4934-4938.
3. Fett, D., Küsters, R., & Schmitz, G. (2015). SPRESSO: A secure, privacy-respecting single sign-on
system for the Web. Paper presented at the Proceedings of the 22nd ACM SIGSAC Conference on
Computer and Communications Security.
4. Fetterly, D., Manasse, M., & Najork, M. (2004). Spam, damn spam, and statistics: Using statistical
analysis to locate spam web pages. Paper presented at the Proceedings of the 7th International
Workshop on the Web and Databases: colocated with ACM SIGMOD/PODS 2004.
5. Garais, G. E., & Enaceanu, A.-S. (2016). Open Source Servers And Website Platforms Security.
Journal of Information Systems & Operations Management, 503.
6. Group, N. W. (1999). RFC 2616: Hypertext Transfer Protocol--HTTP. R. Fielding, J. Gettys, J.
7. Hydara, I., Sultan, A. B. M., Zulzalil, H., & Admodisastro, N. (2015). Current state of research on cross-site scripting (XSS)–A systematic literature review. Information and Software Technology, 58, 170-186.
8. Jerković, H., Vranešić, P., & Dadić, S. (2016). Securing web content and services in open source
content management systems. Paper presented at the Information and Communication Technology,
Electronics and Microelectronics (MIPRO), 2016 39th International Convention on.
9. Kent, C., Tanner, M., & Kabanda, S. (2016). How South African SMEs address cyber security: The
case of web server logs and intrusion detection. Paper presented at the Emerging Technologies and
Innovative Business Practices for the Transformation of Societies (EmergiTech), IEEE International Conference on.
10.Liao, X., Liu, C., McCoy, D., Shi, E., Hao, S., & Beyah, R. (2016). Characterizing long-tail seo
spam on cloud web hosting services. Paper presented at the Proceedings of the 25th International
Conference on World Wide Web.
11.Malandrino, D., Petta, A., Scarano, V., Serra, L., Spinelli, R., & Krishnamurthy, B. (2013). Privacy
awareness about information leakage: Who knows what about me? Paper presented at the
Proceedings of the 12th ACM workshop on Workshop on privacy in the electronic society.
12.Mansoori, M., Hirose, Y., Welch, I., & Choo, K.-K. R. (2016). Empirical Analysis of Impact of
HTTP Referer on Malicious Website Behaviour and Delivery. Paper presented at the Advanced
Information Networking and Applications (AINA), 2016 IEEE 30th International Conference on. 13.OWASP, T. (2013). Top 10–2013. The Open Web Application Security Project.
14.Salini, P., & Shenbagam, J. (2015). Prediction and Classification of Web Application Attacks using Vulnerability Ontology. International Journal of Computer Applications, 116(21).
15.Tewari, A., Jain, A., & Gupta, B. (2016). Recent survey of various defense mechanisms against phishing attacks. Journal of Information Privacy and Security, 12(1), 3-13.
16.Vasek, M., Wadleigh, J., & Moore, T. (2016). Hacking is not random: a case-control study of webserver-compromise risk. IEEE Transactions on Dependable and Secure Computing, 13(2), 206-219.
