Más vulnerabilidades: XSS e ¿Inyección de SQL? en WordPress

Esto es de nunca acabar, se siguen reportando más vulnerabilidades XSS en WordPress, el siguiente ejemplo funciona en todas las versiones 2.x de WordPress (incluyendo la versión en desarrollo).

code:
http://wordpress/wp-admin/page-new.php?saved="><script>alert(123)</script>

Para solucionar este problema, apliquen la función attribute_escape a la dirección URL que retorna de get_page_link (línea 13 de wp-admin/page-new.php en 2.1.2).

php:
<?php echo attribute_escape(get_page_link( isset($_GET['posted']) ? $_GET['posted'] : $_GET['saved'] )); ?>

Por otro lado, la persona que reportó esa vulnerabilidad, también me comentó que existe una vulnerabilidad de Inyección de SQL que afecta a todas las versiones de este popular y últimamente bastante inseguro CMS.

La siguiente cita es parte del mail que recibí hoy en la mañana:

But there is another XSS:
wp-admin/page-new.php?saved="><script>alert(123)</script>

There is also an SQL Injection Vulnerability in combination with PHP 4.3.9 It is Possible to spy out any data. The vulnerability exists in all versions, incl. svn trunk

SQL Injection Cheat Sheet

A través de una entrada en el blog de RSnake, he llegado a una interasante colección de ejemplos de SQL Injection que Ferruh Mavituna ha preparado, estos ejemplos están principalmente basados en bases de datos MySQL, Sql Server y Oracle.

La página mencionada muestra referencias a funciones y características que pueden resultar útiles al momento de encontrar y explotar este tipo de vulnerabilidades.

Otro recurso, igual de importante e útil que el anterior, es el que realizó Jungsonn -asiduo participante de los foros sla.ckers.org.

Administrar comillas utilizando el método Replace de la clase String

El título hace referencia a un artículo -bastante preocupante por cierto- publicado en el sitio web de El Guille, en el que se presenta una función para evitar el problema con las comillas simples cuando se concatenan sentencias SQL.

En este ejemplo veremos cómo utilizar el método Replace de la clase String. Este ejemplo reemplaza comillas simples entre dos comillas simples adyacentes para asegurarse de que los datos tienen el formato correcto cuando se concatenan valores para una instrucción SQL.

El código que se muestra es el siguiente (en mi opinión, código candidato para WTF):

csharp:
public string QuitarApostrofe(string vCadena)
{
    vCadena = vCadena.Replace("'", "''");
    return vCadena;
}

public void e50factu()
{
    //Cadena a la cual se le va a sustituir la comilla.
    string MiCadena = QuitarApostrofe("WARNER'S DE MEXICO SA DE CV ");
    //Abro la conexion
    ConecServer.Open();
    OleDbCommand mycmd = ConecServer.CreateCommand();
    OleDbTransaction Trans;
    Trans = ConecServer.BeginTransaction(IsolationLevel.ReadCommitted);
    mycmd.Connection = ConecServer;
    mycmd.Transaction = Trans;
    try
    {
        strSQL = "INSERT INTO e50factu(serie50,numero50,descri50) " +
            "VALUES ('" + clsVariables.vSerie + "'," + 20356 + ",'" + MiCadena + "')";
        mycmd.CommandText = strSQL;
        mycmd.ExecuteNonQuery();
        strSQL = "INSERT INTO A50COTI(folio,factura,usuario,hora,serie)" +
            "VALUES(" + 1 + "," + 20356 + "," + "evallejo" + ",'" + "12:00" + "','" + "B" + "')";
        mycmd.CommandText = strSQL;
        mycmd.ExecuteNonQuery();
        Trans.Commit();
    }
    catch (System.Exception error)
    {
        try
        {
            Trans.Rollback();
            MessageBox.Show("Ocurrio un error, no se realizo ningún cambio en la base de datos" +
                error.Message,
                "Guardar Factura", MessageBoxButtons.OK, MessageBoxIcon.Error);
        }
        catch (OleDbException ex)
        {
            if (Trans.Connection != null)
            {
                MessageBox.Show("Ha ocurrido una excepción grave de tipo " + ex.GetType());
            }
        }
    }
    finally
    {
        ConecServer.Close();
    }
}

Personalmente creo que el hecho de que se publiquen o dejen pasar este tipo de recursos en un sitio bastante popular, puede hacer daño a aquellos que recién empiezan y consideran que todo lo que se publica ahí sea información útil y fiable.

Sistemas de estadísticas Web y datos sobre las búsquedas

Your Traffic stats
Frecuencia con que reviso las estadísticas de acceso a este blog 😀 (Fuente isopixel)

Debido a que estos últimos meses en estuve comentando algunos temas relacionados sobre seguridad, ahora recibo unas cuantas visitas de gente buscando información sobre XSS, Sql Injection, CSRF, etc; entre estas visitas también hay algunos que buscan algunos exploits que siguen unos patrones determinados.

Al igual que un caso anterior, esta vez mientras revisaba las estadísticas de acceso al blog en Reinvigorate, un pequeño mensaje salió a la vista:

XSS Message

Al mirar más detenidamente la fuente de ese mensaje, ví que alguien al parecer estaba buscando(*) erróneamente servidores vulnerables o más información sobre un bug reportado por Stefan Esser en el Mes de los Bugs de PHP.

Es interesante como este tipo de búsquedas pueden ayudar a encontrar bugs de manera imprevista 🙂 .

(*) El texto que buscaban era http://www.google.com.ar/search?q=?a[]=<script>alert(/XSS/);</script>

Filtros genéricos y la seguridad

Hace algún tiempo ya había comentado que este tipo de funciones en general son de poca utilidad y dan una falsa sensación de seguridad a los que las usan.

php:
function antiinjection($str) {
        $banwords = array ("'", ",", ";", "--", " or ", ")", "(", " OR ", " and ", " AND ","\n","\r");
        if ( eregi ( "[a-zA-Z0-9]+", $str ) ) {
                $str = str_replace ( $banwords, '', ( $str ) );
        } else {
                $str = NULL;
        }
        $str = trim($str);
        $str = strip_tags($str);
        $str = stripslashes($str);
        $str = addslashes($str);
        $str = htmlspecialchars($str);
        return $str;
}

¿Qué problemas le encuentran al código mostrado?