php - que - Alternativa a mysql_real_escape_string sin conectarse a DB

mysqli_real_escape_string() expects exactly 2 parameters

Question

Me gustaría tener una función que se comporte como mysql_real_escape_string sin conectarse a la base de datos ya que a veces tengo que hacer pruebas en seco sin conexión de DB. mysql_escape_string está en desuso y, por lo tanto, no es deseable. Algunos de mis hallazgos:

http://www.gamedev.net/community/forums/topic.asp?topic_id=448909

http://w3schools.invisionzone.com/index.php?showtopic=20064

Answer 1

Bueno, de acuerdo con la página de referencia de la función mysql_real_escape_string : "mysql_real_escape_string () llama a la función de biblioteca de MySQL mysql_real_escape_string, que escapa de los siguientes caracteres: / x00, / n, / r, /, ''," y / x1a. "

Con esto en mente, la función que se proporciona en el segundo enlace que publicó debe hacer exactamente lo que necesita:

function mres($value)
{
    $search = array("//",  "/x00", "/n",  "/r",  "''",  ''"'', "/x1a");
    $replace = array("////","//0","//n", "//r", "/'", ''/"'', "//Z");

    return str_replace($search, $replace, $value);
}

Answer 2

De investigaciones posteriores, he encontrado:

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-11.html

Solución de seguridad:

Se ha encontrado un agujero de seguridad de inyección SQL en el procesamiento de codificación de varios bytes. El error estaba en el servidor, analizando incorrectamente la cadena escapada con la función API C de mysql_real_escape_string ().

Esta vulnerabilidad fue descubierta e informada por Josh Berkus y Tom Lane como parte de la colaboración de seguridad entre proyectos del consorcio OSDB. Para obtener más información acerca de la inyección SQL, consulte el siguiente texto.

Discusión. Se ha encontrado un agujero de seguridad de inyección SQL en el procesamiento de codificación de varios bytes. Un agujero de seguridad de inyección SQL puede incluir una situación en la que cuando un usuario proporciona datos para ser insertados en una base de datos, el usuario puede inyectar sentencias SQL en los datos que ejecutará el servidor. Con respecto a esta vulnerabilidad, cuando se utiliza el escape de conjunto de caracteres no conscientes (por ejemplo, addslashes () en PHP), es posible omitir el escape en algunos conjuntos de caracteres de varios bytes (por ejemplo, SJIS, BIG5 y GBK). Como resultado, una función como addslashes () no puede evitar los ataques de inyección de SQL. Es imposible arreglar esto en el lado del servidor. La mejor solución es que las aplicaciones usen el escape con reconocimiento de conjunto de caracteres ofrecido por una función como mysql_real_escape_string ().

Sin embargo, se detectó un error en la forma en que el servidor MySQL analiza la salida de mysql_real_escape_string (). Como resultado, incluso cuando se usó la función de ajuste de conjunto de caracteres mysql_real_escape_string (), la inyección de SQL fue posible. Este error se ha corregido.

Soluciones temporales Si no puede actualizar MySQL a una versión que incluye la solución para el error en mysql_real_escape_string (), pero ejecute MySQL 5.0.1 o superior, puede usar el modo SQL NO_BACKSLASH_ESCAPES como solución alternativa. (Este modo se introdujo en MySQL 5.0.1.) NO_BACKSLASH_ESCAPES habilita un modo de compatibilidad estándar de SQL, donde la barra diagonal inversa no se considera un carácter especial. El resultado será que las consultas fallarán.

Para establecer este modo para la conexión actual, ingrese la siguiente declaración SQL:

SET sql_mode=''NO_BACKSLASH_ESCAPES'';

También puede establecer el modo globalmente para todos los clientes:

SET GLOBAL sql_mode=''NO_BACKSLASH_ESCAPES'';

Este modo SQL también se puede habilitar automáticamente cuando el servidor comienza utilizando la opción de línea de comando --sql-mode = NO_BACKSLASH_ESCAPES o estableciendo sql-mode = NO_BACKSLASH_ESCAPES en el archivo de opción del servidor (por ejemplo, my.cnf o my.ini , dependiendo de tu sistema). (Bug # 8378, CVE-2006-2753)

Ver también Bug # 8303.

Answer 3

En oposición directa a mi otra respuesta, esta función siguiente probablemente sea segura, incluso con caracteres de varios bytes.

// replace any non-ascii character with its hex code.
function escape($value) {
    $return = '''';
    for($i = 0; $i < strlen($value); ++$i) {
        $char = $value[$i];
        $ord = ord($char);
        if($char !== "''" && $char !== "/"" && $char !== ''//' && $ord >= 32 && $ord <= 126)
            $return .= $char;
        else
            $return .= ''//x'' . dechex($ord);
    }
    return $return;
}

Espero que alguien más entendido que yo pueda decirme por qué el código anterior no funcionará ...

Answer 4

Es imposible escapar de forma segura una cadena sin una conexión DB. mysql_real_escape_string() y las declaraciones preparadas necesitan una conexión a la base de datos para que puedan escapar de la cadena usando el juego de caracteres apropiado; de lo contrario, los ataques de inyección SQL aún son posibles usando caracteres de varios bytes.

Si solo está probando , entonces también puede usar mysql_escape_string() , no está 100% garantizado contra ataques de inyección SQL, pero es imposible construir algo más seguro sin una conexión DB.