Universidad del Norte. Pallares. CSRF.

Pallares, Daniel.
dpallares_78@hotmail.com
Universidad del Norte

Vulnerabilidad CSRF: Revisin

ResumenCSRF (por sus siglas en ingls) es una

vulnerabilidad web que le permite a un atacante, utilizando las
credenciales de un usuario cualquiera de una aplicacin web,
realizar acciones sobre la aplicacin sin el conocimiento del
usuario. Es una de las vulnerabilidades con mayor prevalencia
segn OWASP y presenta serios riesgos para la seguridad de
las aplicaciones de internet. En este documento se hace una
revisin a los ataques CSRF, las vulnerabilidades que los
posibilitan y las medidas de seguridad para prevenirlos.

ndice de TrminosCSRF, navegador web, seguridad

web, vulnerabilidad.

I. INTRODUCCIN
El creciente uso de Internet y las tecnologas web
como plataforma para todo tipo de aplicaciones,
tanto corporativas como de uso pblico ha trado
consigo el problema de la poca madurez de estas
tecnologas para la seguridad de las aplicaciones,
con un sinnmero de vulnerabilidades que aparecen
a un ritmo alarmante y que de inmediato son
aprovechadas para realizar actos maliciosos. Una de
estas vulnerabilidades es llamada Falsificacin de
peticiones en sitios cruzados, abreviada CSRF o
XSRF por sus siglas en ingls. Esta vulnerabilidad
se conoce desde el ao 2001 [1] y debido a la
facilidad con que puede ser explotada se ha vuelto
un problema de seguridad muy importante. En
palabras sencillas, con CSRF un atacante puede
realizar acciones sobre un sitio web, utilizando la
autenticacin de un usuario vlido del sitio. Esto lo
consigue engaando al usuario para que ejecute
cdigo malicioso (escondido en enlaces, etiquetas
de imgenes y correos electrnicos entre otros) que
enva peticiones al servidor de la aplicacin desde el
computador del usuario vlido. Estas peticiones son
aceptadas por la aplicacin ya que provienen de un
navegador confiable, ejecutando las acciones
requeridas.

Lo que un atacante puede conseguir depende de

las funcionalidades que permita el sitio. Segn el
tipo de aplicacin sera posible realizar acciones
como borrar datos de usuario, ejecutar transacciones
en lnea, enviar correo basura, cambiar
configuraciones de sistema y de red o hasta abrir un
firewall [2]. Es claro que todas estas acciones
pueden impactar de gran manera una organizacin
o a una persona ya que se pueden presentar
problemas jurdicos (fraude), impacto negativo
sobre la reputacin, prdida de datos sensibles o
hasta cada total del sitio por mencionar algunos.

II. DESCRIPCIN DE UN ATAQUE CSFR

Una de las mltiples maneras en que se puede

explotar una vulnerabilidad CSRF se explica a
continuacin. En la figura 1 se muestra un ejemplo
[3] de una pgina de banca en lnea que permite
realizar transferencias de fondos. Se selecciona la
cuenta origen de los fondos en la casilla From, la
cuenta destino en la casilla To y la cantidad en la
casilla Amount. Al dar clic en Continue, el
navegador web realiza una peticin HTTP (Figura
2) al servidor web ejecutando el proceso. El tipo de
peticin mostrada es POST e incluye la cookie en
los encabezados. Si la peticin es exitosa, se
transfieren $5000 de la cuenta 314159265 a la
cuenta 01123581. Algunas aplicaciones no
distinguen entre una peticin con el mtodo POST
de una con el mtodo GET. En la figura 3 se
muestra la misma peticin con el mtodo GET.

Universidad del Norte. Pallares. CSRF.

legtimas y no se verifica si son disparadas desde un

origen diferente al del propio sitio web [4]. Esto le
permite al atacante generar peticiones a travs de
cualquier medio posible como por ejemplo,
formularios auto-ejecutables, correos electrnicos
HTML, enlaces llamativos, etc.

Figura 1. Formulario web de transferencia de

fondos.

Figura 2. Peticin POST de transferencia de fondos.

B. Etiquetas HTML
Muchos de los ataques CSFR se generan
insertando URLs con comandos especficos en
etiquetas HTML que tienen una funcin distinta,
pero que son explotadas debido a que generan
peticiones automticas al servidor web, las cuales
no son verificadas en su contexto. Ejemplos de estas
etiquetas son img, body, input, link, script, table,
etc. Un ejemplo utilizando la etiqueta img se
muestra abajo. Se puede observar que el enlace no
apunta a una imagen sino a una aplicacin.
<img src=https://b2b.tld/app/del?item=123>

Figura 3. Peticin GET de transferencia de fondos.

Si el usuario de la aplicacin, visita otro sitio
mientras se mantiene logueado en la aplicacin,
podra llegar a hacer clic en un enlace como el de la
figura 4. La etiqueta IMG del cdigo HTML no
apunta a una imagen sino que ejecuta una operacin
similar a la GET anterior pero con una cuenta de
destino diferente. De esta manera el usuario ha
ejecutado de forma involuntaria un proceso en la
aplicacin utilizando su identidad (cookie) por lo
que el servidor web la acepta como vlida y en
nombre del usuario.

III. VULNERABILIDADES CSFR

Los factores que facilitan los ataques CSFR son

principalmente los siguientes:
A. Manejo inapropiado de credenciales.
La mayora de sitios web confan en que una vez
que un usuario se haya logueado, todas las
peticiones que provengan del navegador son

C. Uso de mtodos POST y GET para envo de

formularios
La informacin de los formularios se enva al
servidor por medio de los mtodos GET y POST. Se
sugiri utilizar el mtodo POST solamente ya que
GET enva toda la informacin en la URL de
manera visible permitiendo a un atacante obtener
datos importantes para planear sus ataques. Pero el
mtodo POST no evita el riesgo de CSFR ya que
una vez que se tengan todos los campos del
formulario, estos se pueden enviar por medio de una
funcin JavaScript que se ejecuta en el evento
onload de la pgina web del atacante [4].
D. Poltica del mismo origen SOP
La poltica de seguridad SOP (Same Origin
Policy), la cual fue una de las primeras que se
implementaron en los navegadores web prohbe el
intercambio de datos entre orgenes diferentes
basado en tres factores: host, protocolo y puerto.
Por
ejemplo
si
se
abre
el
sitio
http://example.com/index.htm,
la
SOP
del
navegador aceptara o rechazara accesos a script y
datos de las siguientes fuentes:
http://example.com/about.htm (puerto 80):
aceptado, mismo host

Universidad del Norte. Pallares. CSRF.

https://example.com/doc.html (puerto 443):

rechazado
http://google.com/search.php (puerto 80):
rechazado
http://dev.example.com/more.htm (puerto 80):
rechazado

En principio, la SOP fue una buena medida de

seguridad ya que permita proteger la integridad de
los datos y la confidencialidad pero no se mantuvo a
la altura de los cambios en la tecnologa que con la
llegada de JavaScript, Ajax y servicios web se
requera del intercambio de datos entre diferentes
servidores para poder accesar toda la informacin
que utilizan las pginas web y aplicaciones de la
web 2.0. Como la poltica de seguridad no
evolucion, los desarrolladores tuvieron que
encontrar maneras de lograr ese intercambio de
informacin y lo hicieron a partir de JavaScript y
Ajax, pero a expensas de un debilitamiento en la
seguridad que facilita los ataques CSFR [6].
IV. MEDIDAS DE PREVENCIN

En general se han sugerido muchas medidas de

prevencin a los ataques CSFR (ventanas de
confirmacin, uso de POST, verificacin del
encabezado referer), pero algunas se han probado
no efectivas [8], [9]. Las soluciones ms aceptadas
como efectivas contra la vulnerabilidad tienen que
ver con el uso de tokens aleatorios, ocultos, que no
se enven en la URL y con un tiempo de vida corto
que no le permitan al atacante adivinar fcilmente
las credenciales de un usuario y que no le den
tiempo suficiente para ejecutar sus acciones.
Tambin se proponen algoritmos de proteccin que
identifican y filtran las peticiones cruzadas para
detectar si son relacionadas [10]. Finalmente
muchos frameworks vienen con medidas de
proteccin integradas contra CSFR.
V. CONCLUSIN

A pesar de haber bajado en prevalencia en el top

10 de OWASP, CSFR contina siendo una

vulnerabilidad muy comn en las aplicaciones web.
La mayora de los desarrolladores no la incluyen en
sus polticas de seguridad por lo que muchas de
ellas siguen sufriendo este tipo de ataques. Debido
al alto potencial de dao que tienen los ataques
CSFR es muy importante que las aplicaciones
implementen medidas de seguridad efectivas para
proteger sus recursos e informacin y los usuarios
empleen medidas tan sencillas como desconectarse
cuando no se utiliza la aplicacin o no navegar en
sitios desconocidos en el mismo computador que se
utiliza para tareas administrativas o relacionadas
con el trabajo.
REFERENCIAS

[1] Burns, Jesse. 'Cross Site Request Forgery: An

Introduction To A Common Web Weakness'. Information
Security Partners, LLC, 2005.
[2] T. Schreiber. 'Session Riding: A Widespread Vulnerability
in Todays Web Applications'. SecureNet GmbH, 2004.
[3] J. Grossman. 'Cross-Site Request Forgery: The Sleeping
Giant'. WhiteHat Security, 2004.
[4] R. Kombade and B. Meshram, 'CSRF Vulnerabilities and
Defensive Techniques', International Journal of
Computer Network and Information Security, vol. 4, no.
1, pp. 31-37, 2012..
[5] Cgisecurity.com, 'The Cross-Site Request Forgery
(CSRF/XSRF) FAQ', 2015. [Online]. Available:
http://www.cgisecurity.com/csrf-faq.html. [Accessed: 04May- 2015].
[6] Saiedian, H., & Broyle, D. 'Security vulnerabilities in the
same-origin policy: Implications and alternatives'.
Computer, 44(9), 29-36, 2011.
[7] Khant, A. 'A Most-Neglected Fact about Cross Site
Request Forgery'. Security Article Collection. YGN
Ethical Hacker Group, 2010.
[8] Blatz, J. 'CSRF: Attack and Defense'. McAfee
Foundstone Professional Services, White Paper, 2007.
[9] Desmet, Lieven. 'CSRF: the nightmare becomes reality? '.
status: published, 2009.
[10] De Ryck, Philippe, et al. 'Automatic and precise clientside protection against CSRF attacks'. Computer
SecurityESORICS 2011. Springer Berlin Heidelberg,
2011. 100-116.