Hola,
Voy a hacer una serie de comentarios, explicar unas cuantas ideas, para ver si alguien puede decir "no, amigo mío, en esto y aquello estás confundido".
Se lo agradeceré enormemente, puesto que quisiera que todo esto de que ahora hablaré quedara bien claro en mi cabeza.
La clase en la que me basé para llevar a cabo la clase "BDatos" que vengo utilizando ya contaba con un método "Escapar". Yo nunca hasta hoy (si puede decirse luego se verá) he comprendido el significado de dicho método "Escapar" en la clase BDatos. Por mejor decir nunca lo comprendí en su totalidad.
Yo tenía claro que el método "Escapar" no servía para validar las entradas del usuario. Esto era tarea que había que hacer, convenientemente, por separado. Sin embargo no entendía a qué se dedicaba entonces el método "Escapar", y resulta que este método ha de utilizarse para evitar "ataques" de "SQL Injection".
Hasta hace dos días estaba usando la función "
mysql_escape_string", por no mirar con detenimiento en el manual de PHP, pues resulta que esta función se considera "obsoleta" y en su lugar hay que utilizar la función "
mysql_real_escape_string". Recordad que con esta función pretenden escaparse determinados caracteres para evitar lo que se conoce como "SQL Injection".
Esto es lo que tenía que haber tenido claro desde un principio y nunca lo tuve hasta hoy. No se trata de "escapar" caracteres para entrarlos a la base de datos o algo parecido... se trata de evitar que una consulta SQL no contenga determinados caracteres...
Cita:
|
Empezado por Manual de PHP
mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.
|
Que pueden dar lugar a inyecciones SQL, como vengo diciendo, vamos, y como se dice en el manual de PHP... que yo no leí atentamente ni mucho menos.
Al confundirme yo en ese punto, es decir, al pensar que el método "Escapar" servía para descartar "caracteres peligrosos", así, en general,... y no determinados caracteres de una cadena que luego se usará en una consulta SQL... Y NADA MÁS... como yo estaba equivocado, me puse a utilizar como un loco el método "Escapar"... para casi todo.
Por ejemplo, en la entrada del usuario de un determinado formulario... ¿qué hacía? Escapar los caracteres con el método susomentado. ¿Iba a formar parte la entrada del usuario en una consulta SQL? Ah... unas veces sí, otras veces no... no tenía ningún conocimiento,... mi intención era que en la entrada del usuario no vinieran caracteres "extraños"... y ya está.
Y ya está el lío montado, quiero decir. Porque voy a tener que repasar todo el código de la aplicación, prácticamente, como buenamente pueda, en busca de estas incongruencias.
Y menos mal que al fin y al cabo conocía la diferencia entre la validación de la entrada del usuario y su "escape"... porque lo segundo puede sobrar, pero, lo primero es imprescindible y no sólo por cuestiones de seguridad, sino también porque así lo exige la propia aplicación... por ejemplo, la descripción de un enlace no ha de contener más de X caracteres y esto hay que validarlo. ¡Pero no hay que escaparlo siempre!
Hay que "escaparlo" con el método "Escapar" de la clase "BDatos" cuando dicha descripción va a formar parte de una consulta SQL... entonces sí, pero, si no es así, si únicamente va a presentarse dicha descripción en la página Web, entonces el "escape" se hace innecesario... a lo menos es "escape" que trata de evitar el "SQL Injection"... ¿Cómo iba a darse un ataque de este tipo si no se va a llevar a cabo consulta SQL ninguna?
Y aquí es donde entramos en el "Cross Site Scripting." Es decir, la cadena que vamos a validar no se incluirá en ninguna consulta SQL, pero, sí se mostrará en la página Web... código HTML... al fin y al cabo... al que se le pueden añadir "cosas" como un evento que se dispararse cuando se pasar por encima de determinado elemento. Es decir, justo lo que el compañero que me escribió amablemente para darme luz sobre todo esto propuso en la segunda URL de ejemplo que hay al comienzo de este Hilo.
Es aquí, amigos, donde entra el "Escape" necesario, que esta vez no tiene que ver con el uso de la función "mysql_real_escape_string"... sino con la función "
htmlentities", por ejemplo, junto con "
strip_tags", si se me apura, o a lo que yo entiendo. Lo que pretendemos al hacer uso de esta función es evitar las posibles etiquetas PHP y HTML (?) que se incluya en la entrada del usuario, así como convertir determinados caracteres en sus correspondientes entidades HTML.
Bien. Ya termino. Os pido disculpas por el rollo. Si habéis leído hasta aquí ya tenéis valor, ya.
Este es el método "Escapar" conque ahora cuenta la clase "BDatos":
Código PHP:
function Escapar($cadena) {
// http://es.php.net/manual/en/function.mysql-real-escape-string.php
if(get_magic_quotes_gpc()) $cadena = stripslashes($cadena);
return mysql_real_escape_string($cadena, $this->enlaceConexionBd);
}
Y este es el método "Escapar" conque ahora cuenta la clase "XHtml":
Código PHP:
function Escapar($entrada) {
return htmlentities(strip_tags($entrada), ENT_QUOTES, 'utf-8');
}
Si tenéis algo que decir sobre ellos soy todo ojos. El trabajo que me queda ahora es revisar lo necesario para que dichos métodos se utilizen donde convengan y no donde no convengan. Voy a ver si no cuesta tanto como me parece que va a costar... porque sigo estando bicho, bicho, bicho. O algo peor.
Bueno. No digo nada. Agur.