04-Clase 04 Xss Rfi Lfi

Programación Segura:
XSS – RFI y LFI

Encargado: Ing. Raúl B. Ne.o, Mg.
Junio - 2021
Tabla de Contenidos
ü Cross Site Scripting (XSS)
ü Otras vulnerabildades web: Cross Site Request Forgery
(CSRF)
ü Ejecución remota de código (RCE).
ü Inyección de comandos.
ü Remote File Inclusion (RFI) y Local File Inclusion (LFI).
ü Path Traversal.
Programación Segura
Seguridad a Nivel del Cliente Web

Cross-site Scripting (XSS)
Es una forma generalizada de ataques, cuya dificultad es moderada y que
puede tener un impacto medio a grave.
Permite inyectar código JavaScript u otro lenguaje similar del lado del cliente
en una web tal que cuando la vícAma ingrese a la página o al enlace que
conAene el código inyectado, éste se ejecute.
Explota la confianza que el usuario Aene en el siAo web.
Con la llegada de Web 2.0 y tecnologías como AJAX, XSS es más diJcil de
detectar.
Cross-site Scripting (XSS) - Tipos
• Reflejado – indirecto
• Almacenado persistente
Cross-site Scripting (XSS) - Reflejado (indirecto)
• El código inyectado se ejecuta de manera transitoria o no persistente, no se
almacena en el servidor.
• El código generalmente se inyecta en los parámetros de un enlace; cuando la
víctima hace click en el enlace que contiene la inyección, ésta se ejecuta y se
refleja en su navegador
• Impacto medio
Con XSS reflejado, el atacante podría

robar las cookies para luego robar la
identidad, pero para esto, debe
lograr que su víctima ejecute un
determinado comando dentro de su
dirección web. Para esto, los
atacantes suelen enviar correos
engañosos para que sus víctimas
hagan clic en un enlace disfrazado y
así se produzca el robo.
Ejemplo de XSS reflejado
$name = $_GET['name'];
echo "Welcome $name<br>";
Inyección:
name → <script>alert('attacked')</script>
<html> ...
Welcome
<script>alert('attacked')</script><br>
Cross-Site Scripting (XSS) - Almacenado (persistente)
ü El código inyectado se almacena en el servidor (generalmente en la base de datos)
y cuando el usuario visita la web donde está alojado, éste se recupera y ejecuta.
ü Se le denomina persistente, ya que las acciones derivadas de la ejecución del
código malicioso son persistentes en el servidor.
ü Impacto alto, funciona localizando puntos débiles en la programación de los filtros
de HTML si es que existen, para publicar contenido (como blogs, foros, etc.).
Normalmente el atacante tratará de insertar

tags como <iframe>, o <script>, también el
atacante puede tratar de poner tags que casi
siempre están permitidas y es poco conocida
su capacidad de ejecutar código. De esta
forma el atacante podría ejecutar código
malicioso.
Ejemplo de XSS almacenado
fwrite($file,
"Comment:\n".stripslashes($_REQUEST["comments"]));
Inyección:
El script se guarda como comentario. Cuando un visitante entre a la página

de comentarios, el script aparecerá en el HTML y se ejecutará
automáticamente.
Como se da un ataque XSS?
Código Javascript que procesa un campo de texto para ingreso de Tarjeta

de Crédito
Código HTML con un valor esperado

El atacante, en lugar de ingresar un número como: 1234 1234 1234, ingresa

el siguiente código:
El código ingresado en el input genera lo siguiente:
Que produce?
El código dado carga una cookie para el dominio, en el que se encuentra la página
web atacada,
La cookie se envía a un servidor (bz.com) a menudo bajo el control del atacante,
Si la cookie se usa para la autenticación, el atacante puede intentar hacerse pasar
por el usuario y no necesita saber su contraseña.
Caso real
Samy (también conocido como JS.Spacehero) es un gusano XSS que fue
diseñado para propagarse a través de la red social MySpace escrito por Samy
Kamkar. Apenas 20 horas después de su lanzamiento el 4 de octubre de 2005,
más de un millón de usuarios habían ejecutado la carga útil, lo que convirtió a
Samy en el virus de propagación más rápida de todos los tiempos.
El gusano en sí era relativamente inofensivo, llevaba una carga útil que
mostraba la cadena "pero, sobre todo, Samy es mi héroe" en la página de
perfil de MySpace de la víctima. Cuando un usuario veía esa página de perfil,
la carga útil se replicaba y se plantaba en su propia página de perfil
continuando la distribución del gusano.
DEMO – DVWA I
http://localhost/vulnerabilities/xss_s/
Low Level
• Simple alert
• Usar iframe
• Re-dirigir
• Ver los cookies
Medium Level
• Simple Alert
Riesgos de un ataque XSS
• Leer las cookies (que no están protegidas por el tag HttpOnly), incluidas las
cookies de sesión. Al hacerlo, un atacante podría hacerse cargo de la sesión.
• Ver cualquier cosa que vea el usuario y robar información confidencial.

• Cambiar lo que ve el usuario y manipular la información.
• Básicamente, hacer todo lo que un usuario normal podría hacer, ya que el

atacante puede ver y cambiar cualquier cosa presentada al usuario. Para
ponerlo en contexto; Si el atacante engaña con éxito a un administrador para
que ejecute el XSS, puede hacer todo lo que un administrador podría hacer.
• Hacer cosas a las que tenga acceso el dominio vulnerable, que puede ser el
acceso a la cámara web, el micrófono o la ubicación del usuario.
XSS: Prevenciones I
¿Cómo prevenirlo?
• Limitar los caracteres de entrada.
• Limitar los input types en lo posible.
• Sanear los datos.
• Escapar los datos.
• NUNCA confiar en los datos que vienen de usuarios o de
cualquier otra fuente externa.
XSS: Prevenciones II
Medidas de prevención contra (XSS)

HttpOnly Flag: es un indicador adicional incluida en un encabezado de respuesta
HTTP Set-Cookie. El uso de la bandera HttpOnly cuando se genera una cookie ayuda a
mitigar el riesgo de script del lado del cliente que accede a la cookie protegida (si el
navegador lo soporta).
Si la bandera HttpOnly está incluida en el encabezado de respuesta HTTP, la cookie no

se puede acceder a través de script del lado del cliente (de nuevo si el navegador es
compatible con esta bandera). Como resultado, incluso si existe un XSS, falla, y un
usuario accede accidentalmente a un enlace que explota esta falla, el navegador
(principalmente Internet Explorer) no revelan la cookie a un tercero.
XSS: Prevenciones III
• Controlar los caracteres de escape correctamente.
• Usar whitelisting/blacklisting.
Lista negra: no permitir ciertos caracteres predeterminados en la
entrada del usuario
Lista blanca: solo permitir caracteres buenos conocidos (es un mejor
método para prevenir ataques XSS y SQLi)
• Sanitizar (desinfectar) los datos de entrada del usuario. La

desinfección de datos es una defensa sólida, pero no debe usarse
sola para combatir los ataques XSS.
La desinfección de la entrada del usuario es especialmente útil en los
sitios que permiten el marcado HTML, para garantizar que los datos
recibidos no puedan dañar a los usuarios, así como a su base de datos,
eliminando los datos de marcas potencialmente dañinas, cambiando la
entrada inaceptable del usuario a un formato aceptable.
DEMO con segurilock.com
1) Explotar XSS
Ejemplo de ataque CSRF
1. http://www.example1.com posee un sistema de administración de

usuarios.
2. Un usuario que se encuentra logueado, es decir, con una sesión abierta
válida
3. El atacante le induce, de alguna manera, a hacer click en el siguiente
enlace: http://example1.com/accion.php?transferir=1000.
4. La petición se envía en el marco de la sesión del usuario, al sitio.
5. La aplicación, confiando en que el usuario lo ejecutó voluntariamente,
procesa la acción
DEMO – CSRF - DVWA
• Fake Form
• http://localhost/vulnerabilities/csrf/
Path Traversal
• Vulnerabilidad que permite, a través de la inyección de datos manipulados, acceder
a archivos y directorios que están fuera del directorio raíz del servidor web.
• fopen(‘/var/www/files/../../../etc/passwd’);
• fopen(‘/etc/passwd’);
Ejemplo de LFI
DEMO - LFI
• http://localhost/vulnerabilities/fi/?page=include.php
Ejemplo de RFI
Ejecución Remota de Código
Vulnerabilidad permite inyectar y ejecutar comandos que son utilizados por
el lenguaje de programación del lado del servidor (PHP, JSP, ASP, etc.)
eval($_GET['code']);
Inyección:
code → phpinfo();
eval(phpinfo(););
Inyección de Comando
Vulnerabilidad permite inyectar y ejecutar comandos arbitrarios de sistema.
$file=$_GET['filename'];
system("rm $file");
Inyección:
filename → junk.txt; id
system("rm junk.txt; id")

DEMO – Command Injection
• http://localhost/vulnerabilities/exec/#
Ataques y explotación de vulnerabilidades
● Defacement
● Alojamiento de archivos maliciosos:
ü Sitios de phishing
ü Distribución de malware
● Compromiso del servidor:
ü Webshells y backdoors
ü Scripts, malware, rootkits
• DDoS, spam, minería de bitcoins, ...
● Inyección de Exploit kits
ü Inyección de iframe
ü Inyección de Js (externo o local)
● Robo de información sensible
ü Base de datos
ü Sistema de archivos
● Pivoting en la red
Ejemplo de inyección - Exploit Kit
DEMO – Webshell
• weevely - https://github.com/epinna/weevely3
Bibliografía
ü OWASP Top 10, OWASP Foundation. 2017 https://owasp.org/www-pdf-archive/OWASP_Top_10-
2017_%28en%29.pdf.pdf
ü HTTP/Estado y Seguridad/Cookies HttpOnly - Wikilibros. (2020).

https://es.wikibooks.org/wiki/HTTP/Estado_y_Seguridad/Cookies_HttpOnly
ü OWASP Top 10, OWASP Patagonia Chapter, Gastón Toth https://csirt-nqn.neuquen.gov.ar/wp-

content/uploads/2019/06/Charla-OWASP-TOP10-Nqn.pdf
ü 3 ways to prevent XSS, Sarah Vonnegut. 2017

https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/
Bibliogra+a
ü Security and Secure programming - Security of Web Applica7on., Ing. Tomáš Zahradnický, EUR ING,
Ph.D., Czech Technical University in Prague, Faculty of Informa7on Technology, Department of
Computer Systems.
ü OWASP Top 10 - Cross Site Scrip7ng, Detec7fy Blog, 2016.

https://blog.detectify.com/2016/05/13/owasp-top-10-cross-site-scripting-3/
ü Presentación “Seguridad en Aplicaciones” Módulo 3 – Ing. Gabriela RaZ
ü Presentación “OWASP, SQL Injec7on y XSS” – Materia: Seguridad Informá7ca – Carrera Ing.
Informá7ca – Univ. Nacional de Itapua – Mayo 2021 – Ing. Raúl B. Neao
ü haps://stackoverflow.com/ques7ons/5741187/sql-injec7on-that-gets-around-mysql-real-escape-
string
Gracias por su atención J
Preguntas?
Contactos: raulbeni@gmail.com

04-Clase 04 Xss Rfi Lfi

Cargado por

Copyright:

Formatos disponibles

04-Clase 04 Xss Rfi Lfi

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

04-Clase 04 Xss Rfi Lfi

Cargado por

Copyright:

Formatos disponibles

Programación Segura:

XSS – RFI y LFI

Seguridad a Nivel del Cliente Web

Con XSS reflejado, el atacante podría

Normalmente el atacante tratará de insertar

El script se guarda como comentario. Cuando un visitante entre a la página

Código Javascript que procesa un campo de texto para ingreso de Tarjeta

Código HTML con un valor esperado

El atacante, en lugar de ingresar un número como: 1234 1234 1234, ingresa

• Ver cualquier cosa que vea el usuario y robar información confidencial.

• Básicamente, hacer todo lo que un usuario normal podría hacer, ya que el

Medidas de prevención contra (XSS)

Si la bandera HttpOnly está incluida en el encabezado de respuesta HTTP, la cookie no

• Sanitizar (desinfectar) los datos de entrada del usuario. La

1. http://www.example1.com posee un sistema de administración de

system("rm junk.txt; id")

ü HTTP/Estado y Seguridad/Cookies HttpOnly - Wikilibros. (2020).

ü OWASP Top 10, OWASP Patagonia Chapter, Gastón Toth https://csirt-nqn.neuquen.gov.ar/wp-

ü 3 ways to prevent XSS, Sarah Vonnegut. 2017

ü OWASP Top 10 - Cross Site Scrip7ng, Detec7fy Blog, 2016.

ü Presentación “Seguridad en Aplicaciones” Módulo 3 – Ing. Gabriela RaZ

También podría gustarte