[Consulta] La función like en mysqli es segura¿?

[dj_krihs]

Un saludo compañeros de Foros Del Web, estoy programando un script desde hace más de dos meces y bueno estaba creando una función para un buscador y me inquieta si la función like es segura o no. Acá les doy un ejemplo de mi buscador:

Código PHP:

  function secure($var, $xss = false){
    global $mysqli;
    $var = function_exists('magic_quotes_gpc') ? stripslashes($var) : $var;
    $var = cleanInput($var);
    $var = $mysqli->real_escape_string($var);
    if($xss) $var = htmlspecialchars($var);
    return $var;
}
 
$sql = $mysqli->query('SELECT p.p_id, p.p_title FROM posts AS p WHERE p.p_title LIKE \'%'.secure($_POST['busqueda']).'%\' LIMIT 10') or die($mysqli->error);
while($row = $sql->fetch_assoc()) $result[] = $row; 
   

Ese es el código que tengo, alguien me puede decir si es seguro o alguien puede hacer una inyección Sql o burlar la seguridad de mi script¿?

[gnzsoloyo]

Ese es el código que tengo, alguien me puede decir si es seguro o alguien puede hacer una inyección Sql o burlar la seguridad de mi script¿?

Cualquier sentencia SQL pura es insegura. Si quieres trabajar de forma completamente segura no debes ejecutar sentencias, sino usar stored procedures. Eso desde el punto de vista del SQL.

A nivel PHP, te recomiendo que antes de seguir leas el manual de PHP: http://www.php.net/manual/es/securit...-injection.php

[dj_krihs]

Iniciado por gnzsoloyo

Cualquier sentencia SQL pura es insegura. Si quieres trabajar de forma completamente segura no debes ejecutar sentencias, sino usar stored procedures. Eso desde el punto de vista del SQL.

A nivel PHP, te recomiendo que antes de seguir leas el manual de PHP: [url]http://www.php.net/manual/es/security.database.sql-injection.php[/url]

Ok, gracias, voy a revisar un poco más sobre stored procedures aunque te agradecería si me das un resumen de qué es y cómo se usa, claro, solo si tienes tiempo.

Saludos!

[gnzsoloyo]

¿En síntesis?
Son rutinas programadas en SQL que pueden recibir parámetros y devolver resultados por parametro o como tablas (arrays en PHP), las cuales son invulnerables al SQL-Injection, ya que un SQL injection ingresando por parámetro genera un error de sintaxis irreversible.
Todos los DBMS (SQL Server, Oracle, PostgreSQL, MySQL, DB2, Firebird, etc.) tienen su propio modo de escribir estas rutinas, se crean en las mismas bases de datos.
Requieren cierta práctica, pero en esencia permiten realizar una o más operaciones en forma atómica (como si fuesen una sola sentencia), y para ciertas operaciones resultan mucho más eficientes, ya que toda la ejecución ocurre en el servidor de bases de datos, liberando a la aplicación de ciertas cargas.
Son muy usadas en sistemas de alta exigencia de seguridad. De hecho, en algunos casos que conozco las áreas de seguridad informática especifican a los desarrolladores que las consultas a la base se deben realizar exclusivamente en SP.

Hay mucha literatura sobre ellas, y como la sintaxis cambia entre los diferentes sistemas de BBDD, es recomendable acudir al manual de referencia del que vas a usar para ver exactamente cómo se crean, escriben y usan.

[patriciomase]

Una consulta sql bien escapada no es vulnerable a sql injection. Los frameworks php actuales también traen filtros a POST que bloquean las injecciones. Usar procedimientos almacenados no está del todo bueno porque te queda parte de la lógica en la base de datos. A mi modo de ver la base es para GUARDAR la información y la lógica tiene que estar toda en la aplicación, pero bueno son distintos puntos de vista.

[gnzsoloyo]

Usar procedimientos almacenados no está del todo bueno porque te queda parte de la lógica en la base de datos.

Usar stored procedures (y lo digo con total conocimiento de causa), es la mejor forma de resolver procesos donde sólo debe intervenir la base de datos, como pueden ser cadenas ABM en los que el overhead de la red es pasible de generar inconsistencias, o en procesos que deben ser completamente atómicos, como ser la cadena de procesos de una factura y/o pago que se emite.
La base de datos guarda datos, pero si escuchaste a los profesores de BBDD en clase debes recordar que ademas procesa datos para devolver información, y en ese contexto, los SP son total y absolutamente necesarios.
Como ya comenté, trabajo para una empresa donde es un requisito de seguridad informática que no se hagan peticiones a la base que no sean por SP.
¿Es el sql-injection la única razón?
No. Hay otra muy interesante: Puedes hacer funcionar todo un sistema de altísima complejidad con usuarios que lo único que pueden hacer en la base es LOGIN y EXECUTE ROUTINE.

En cuanto a lo de que "la logica debe estar toda en la aplicación" es cierto... pero lo que debe estar allí es la lógica del negocio, no la lógica de datos, que son dos cosas totalmente diferentes.
La aplicación tiene la lógica de negocio, eso sin duda, pero trasportar a ella la construcción de las consultas, porque esa no es lógica de aplicación, y generas uno de los peores defectos que existen: exceso de acoplamiento con la base de datos.
Si migras la lógica de los SP a la aplicación esclavizas al sistema con un modelo de datos, donde cada ajuste requerirá de inmensas cantidades de programación adicional. Mientras que cambiar proceso en base, no la afectará en nada.

En resumen: No hay que confundir la lógica del negocio, dominio de la aplicación, con la lógica de BBDD.