Desarrollo

Cómo controlar la seguridad en los formularios

Desarrollo HTML PHP

Seguimos abordando el tema de la solicitud de datos al usuario y, en esta ocasión, nos vamos a centrar en controlar la seguridad en los formularios. Después de saber cómo solicitar datos y cómo recogerlos en nuestros programas PHP, es muy importante tener unas primeras nociones de seguridad al tratar con esos datos.

Porque un mal formulario puede echar por tierra todo el trabajo realizado y cualquier podría hacerse con datos importantes, tumbar nuestra web o acceder o modificar aspectos importantes de la misma. De ahí que la seguridad sea siempre un tema de vital importancia.

En este artículo veremos las principales formas de controlar la seguridad en los formularios, pero siempre hay que estar atentos a cualquier posible detalle para evitar mal mayores. Obviamente, para controlar al 100% la seguridad deberíamos estudiar y ampliar mucho los conocimientos, pero tener unas primeras bases es importante para evitar errores comunes. Ah, y hacer una copia de seguridad de nuestros datos nunca será un tiempo perdido.

Si quieres una información más ampliada y general, puedes empezar por leer la página de seguridad en el propio manual de PHP.

Inserción de datos sospechosos

Imaginemos que tenemos un simple formulario que pide el nombre al usuario. Es un simple <input type=”text”> donde el usuario puede escribir realmente lo que le plaza, enviar el formulario y nuestro programa procesarlo.

<form action="procesar.php" method="post">
  <p>Nombre: <input type="text" name="nombre" required></p>
  <input type="submit" value="Enviar">
</form>

Insertar HTML

A un usuario graciosillo se le ocurre escribir código HTML dentro del formulario a ver qué sucede. Por ello, coge y escribe en la caja del <input> lo siguiente:

<b>Juan Negrita</b>

Y le da a enviar el formulario. Nuestro programa es sencillo, ya que en PHP hemos programado que, una vez recibido el nombre, accedamos a $_REQUEST[‘nombre’] e imprimamos su valor por pantalla junto a un mensaje ‘Hola ‘ para saludar al nuevo usuario, sin ningún extra. Y nos encontramos con que se ha impreso:

Hola Juan Negrita

Así, tal cual en negrita. ¿Por qué? Porque al haber impreso también las etiquetas que el usuario ha introducido, la página HTML las ha tenido en cuenta y las ha procesado con normalidad, mostrando el texto en negrita. A nuestro usuario graciosillo se le escapa una risita.

Insertar JavaScript

No hemos hablado aún de JavaScript. Podemos definirlo rápidamente como un lenguaje de programación cuyo código se ejecutaría en el navegador del cliente y no en el servidor (como hace PHP), por lo que digamos que no podría acceder a los datos internos que se procesan antes de servirnos la página web.

Aunque tiene muchos usos, podríamos decir que se utiliza para animar páginas webs, dotarla de efectos y, a partir de ahí, hacer cosas mucho más complejas y útiles. Por ejemplo, JavaScript tiene una función llamada alert(), la cual muestra la típica ventanita emergente con un mensaje y el botón para aceptar. Tocaremos algo de JavaScript algún día, espero.

En fin, nuestro usuario graciosillo quiere probar ahora algo más con nuestro formulario, y se le ocurre escribir lo siguiente:

<body onload="alert('Hola')">

No nos detendremos ahora a analizarlo, pero este código sirve para abrir un aviso emergente con el texto ‘Hola’ cuando accedemos a la página. Así, nuestro usuario pulsa en el botón para enviar y, cuando nuestro PHP procesa la información y se dispone a imprimir en pantalla la cadena ‘Hola ‘ con el nombre, salta en nuestra página un aviso emergente con el texto ‘Hola’.

Se ha procesado el código JavaScript que el usuario había colocado. Peligro, pues ésto ya puede hacer cosas más serias y un usuario avanzado podría atacar sobre los datos de la web.

Inyección SQL

La inyección SQL es uno de los ataques más conocidos y una de las razones por las que debemos controlar la seguridad en los formularios de manera muy clara si no queremos llevarnos sustos. Podemos conocer más cosas en este enlace (en inglés).

SQL es un tipo de lenguaje que se utiliza para administrar bases de datos y desde donde podremos ejecutar consultas a la base de datos, añadir, modificar, borrar, etc. Pensemos que, en nuestra base de datos, tendremos todos los datos de nuestros usuarios, contraseñas y mucho más.

Atención. La siguiente explicación es para concienciar de la importancia de la seguridad en nuestros formularios, no para utilizarla con fines fraudulentos.

Una pequeña comprobación inicial

Supongamos que tenemos el típico formulario que pide usuario y contraseña. Sabemos que la consulta SQL a una base de datos suele utilizar, al igual que los strings que ya hemos visto, comillas simples o comillas dobles, pero no lo sabemos en este caso concreto. En primer lugar, para conocer esta información escribimos en el campo de usuario lo siguiente:

"prueba

Probamos y el programa nos dice que el nombre de usuario es incorrecto. Vamos ahora a probar con comillas simples:

'prueba

Y el programa ya no nos devuelve un usuario incorrecto, sino que obtenemos un mensaje de que ha habido un error en la consulta o algo parecido. Acabamos de comprobar que los datos introducidos no se comprueban y que además las consultas se realizan con comillas simples. Probablemente la consulta sea algo así:

SELECT * FROM usuarios WHERE usuario='prueba' AND password='prueba'

Básicamente, una simple petición de obtener el usuario con nombre de usuario prueba y contraseña prueba. En el primer caso, con las comillas dobles probando en el campo de contraseña esta vez tendríamos:

SELECT * FROM usuarios WHERE usuario='prueba' AND password='"prueba'

Lo que no da error, pues la consulta es correcta (las comillas dobles se considerarían parte de la contraseña) pero como nuestro usuario no tiene esa contraseña, pues simplemente avisamos del error de que la contraseña es incorrecta. Probemos ahora con comillas simples:

SELECT * FROM usuarios WHERE usuario='prueba' AND password=''prueba'

Con lo que vamos sabiendo ya deberíamos ver que aquí algo no cuadra. Hay un error, pues abrimos comillas simples, las cerramos y luego colocamos prueba’ con lo que la consulta da error y eso se nos indica. No nos está diciendo que no existe el usuario y la contraseña, sino que esa consulta devuelve un error.

Conectándonos aun sin saber usuario y contraseña

Sabiendo ésto se puede atacar. La clave es condicionar la consulta a lo que el atacante quiere, que es entrar sin saber usuario y contraseña. Para ello debe conseguir que la consulta le devuelva todos los datos. Es decir, si encuentra al menos un usuario y contraseña, entonces accederá sin problemas.

Nuestro avispado usuario coloca entonces, en el campo de la contraseña, lo siguiente:

prueba' OR '1'='1

Alguno se pensará, ¿y qué ha conseguido con ésto? Vamos a copiar la consulta que se realizaría a la base de datos y se verá más claro:

SELECT * FROM usuarios WHERE usuario='prueba' AND password='prueba' OR '1'='1'

¡Cómo ha cambiado la consulta! Leamos bien, ahora nos está diciendo que nos devuelva al usuario prueba y contraseña prueba, el cual no existe, y atención, o que devuelva ‘1’=’1′, ¡lo cual siempre va a ser cierto! De esta forma ha conseguido consultar todos los registros de la tabla de usuarios y entrar en la aplicación web sin necesidad de usuario y contraseña.

Conocer los nombres de los campos de la base de datos

Podemos usar algo parecido para intentar obtener los nombres de los campos que tenemos en nuestra base de datos. Aunque, para ello, necesitamos ir con el concepto de “prueba y error”, pero podríamos llegar a obtener el nombre de los campos.

Para ello, vamos a escribir en el campo de la contraseña lo siguiente:

prueba' AND usuario='prueba

Podemos encontrarnos ante dos situaciones distintas. La primera es que se nos muestre un error, por lo que se puede sobreentender que el campo usuario no existe en nuestra base de datos. Pero si el mensaje que se nos muestra es el típico de “Usuario o contraseña incorrectos”, entonces es que el campo usuario sí existe y no ha dado error. De esta forma, ya sabemos que ese campo existe y podríamos probar con los campos que se nos ocurrieran. ¿Imagináis que probamos a ver si un campo se llama DNI?

Conocer los nombres de las tablas de la base de datos

Con el mismo concepto podemos ir probando hasta obtener los nombres de las tablas de la base de datos. Por ejemplo, podríamos colocar el siguiente texto en el campo para la contraseña:

prueba' AND 1=(SELECT * FROM usuarios); --

En SQL los comentarios empiezan por –, así que lo que vendría luego (en este caso sería una comilla simple) se obviaría. Al enviar este texto utilizamos el mismo concepto que antes. Si se nos devuelve un error es que el nombre de la tabla era incorrecto y, por tanto, la consulta es incorrecta. Si se nos muestra que el usuario o contraseña son incorrectos, significa que la consulta ha ido bien y, por tanto, el nombre usuarios es el nombre de una tabla de la base de datos.

Ya tenemos el nombre de una tabla y el de sus campos. ¿Para qué podríamos utilizarlos?

Conocer el contenido de un campo de la base de datos

Pongamos que, con los dos métodos anteriores, hemos sabido que existe un campo de nombre usuario y que tenemos una tabla de nombre usuarios. Sabiendo ésto, vamos a intentar obtener si existe el nombre del usuario, por ejemplo, pedro. Colocaríamos de nuevo en el campo contraseña lo siguiente:

prueba' OR usuario LIKE 'pedro'; --

Y esperamos algo parecido en este caso. ¿Que conectamos? Hay un usuario de nombre pedro. ¿Que no conectamos? Entonces no hay ningún usuario con ese nombre.

Podemos ir yendo poco a poco hasta ir sacando todos los nombres de usuario, por ejemplo así:

prueba' OR usuario LIKE 'a%';--

Le estamos pidiendo que nos diga si hay usuarios que empiecen por a. Si todo es válido, podríamos seguir buscando los que empiecen por aa. Si no hay, entonces buscar los que empiecen por ab y así hasta obtener los nombres de usuarios que queramos.

Insertar o modificar campos existentes en la base de datos

Sí, podemos saber el nombre de algún usuario, pero peor será modificar alguno de sus datos o insertar usuarios nuevos. Nuestro usuario experto, que ya sabe el nombre de las tablas y de los campos, introduce ahora en el campo para la contraseña lo siguiente:

prueba'; INSERT INTO usuarios('usuario', 'password') VALUES('pedro', 'pedro');--

Dándole a enviar y ejecutando en SQL la consulta completa, este trozo lo que haría sería insertar en la tabla usuarios un usuario y un password nuevo con valores pedro y pedro respectivamente. Ya tenemos registrado ese nuevo usuario y podríamos acceder sin problemas. Imaginad que es una aplicación de pago o algo parecido, pero ahora nuestro usuario experto tiene un usuario para él solo.

O puede ejectuar una sentencia parecida para, si ha logrado obtener el nombre de un usuario, cambiarle la contraseña, por ejemplo. De esta forma podría usurpar su identidad fácilmente, lo cual sería muy peligroso.

Borrar una tabla de la base de datos

Pero, claro, haciendo estas cosas podemos ejecutar otras sentencias SQL que también serían muy dañinas, como la de borrar una tabla. Nuestro usuario experto quiere hacer daño a la aplicación web y, para ello, va a borrar todos los datos de los usuarios. Escribe en el campo de la contraseña lo siguiente:

prueba'; DROP TABLE usuarios; --

Y se acabó. Acaba de ejecutar la instrucción que borra completamente la tabla de usuarios. Todos se han perdido, todos sus datos y todo lo que hubiera guardado en esa tabla de usuarios. Si no se ha hecho una copia de seguridad, los datos son irrecuperables y acaba de hundir totalmente la aplicación y puede que hasta el negocio entero si empieza a borrar más y más tablas.

¿Realmente queremos que haga ésto? No, por tanto, vamos a intentar controlar la seguridad en los formularios para evitarlo. Pero antes, veamos algún ataque más.

CSRF

El CSRF es otro tipo de ataque que puede afectar nuestras webs, que especialmente puede hacer daños en sistemas que tienen usuario y contraseña. Es posible que el concepto sea más complejo de lo que hemos visto hasta ahora, pero vamos a resumirlo.

Imaginemos que tenemos una aplicación web muy bien formada, con un buen sistema de usuarios y contraseñas, pero baja seguridad. En esta página web, cuando queremos eliminar un usuario (sólo nosotros, que tenemos permisos de administrador y podemos ver el botón de eliminar usuarios), pulsamos un botón que ejecuta el siguiente enlace:

https://www.mifantasticaweb.com/usuarios/eliminar/238

El código PHP que se ejecuta recogería ese 238, el cual sería la ID del usuario que queremos eliminar, lo buscaría en la base de datos y lo eliminaría. Pero imaginemos que, como hemos dicho, no hemos controlado mucho la seguridad.

Por ello, un usuario avispado que entiende un poco de este tipo de aplicaciones coge y le da por escribir en la barra de URLs de un navegador la ruta que hemos escrito arriba. Si no hay ningún tipo de seguridad, nuestra aplicación web ejecuta la eliminación del usuario 238. Ahora imaginad qué ocurriría si le diera por ejecutar masivamente eliminaciones del usuario 1, 2, 3, 4, etc. Adiós a todos los usuarios de la web.

Hay técnicas para evitarlo, por supuesto. Alguna la veremos luego, pero siempre es recomendable informarse más y mejor en lugares más avanzados para ampliar conocimientos sobre cómo controlar la seguridad en los formularios. Además, la mayoría de frameworks existentes hoy en día incorporan métodos para evitar el CSRF.

Controlar la seguridad en los formularios

Vistas una serie de acciones que pueden ser perjudiciales para nuestros formularios, vamos a ver formas de resolver los problemas que nos hemos encontrado y así controlar la seguridad en los formularios. Sin embargo, en cuanto a la inyección SQL habrá que buscar fuentes mucho más extensas y completas, pues no es un tema sencillo a priori para el aprendizaje. Pero debemos saber que ahí está, aunque comentaremos algo ahora luego en este mismo artículo.

Eliminar etiquetas

Para el problema que teníamos al principio en el cual nuestro usuario graciosillo introducía etiquetas en su nombre, debemos utilizar la función strip_tags($string). Esta función elimina todas las etiquetas y devuelve el string sin ellas.

Por ejemplo, si nuestro usuario ha introducido <b>Juan Negrita</b>, para eliminar las etiquetas deberíamos recoger el dato de la siguiente manera:

strip_tags($_REQUEST['nombre']);

De esta forma, <b> y </b> se eliminarían. Simplemente, debemos tener cuidado pues se eliminaría cualquier etiqueta, incluso si alguien pusiera <juan> de esta forma, se eliminaría porque lo consideraría una etiqueta.

Eliminar caracteres especiales

En ocasiones, debemos pensar que el usuario puede introducir comillas en los datos que introduce. A parte de los ejemplos mostrados anteriormente en la inyección SQL, imaginemos que un usuario introduce lo siguiente en el formulario que pedía el nombre:

"Juan"

Si recordamos, aquí cogíamos esta cadena y mostrábamos por pantalla un mensaje que quería ser “Hola Juan” pero, en este caso, algo falla. Miremos el código en PHP de ese simple echo e igual lo vemos más claro:

echo "Hola $_REQUEST['nombre']";

Cuando vayamos a imprimir este mensaje por pantalla, imaginemos lo que hará PHP. Cogerá ese $_REQUEST[‘nombre’] y lo modificará con el texto introducido, el cual era en este caso, “Juan”. ¿Cómo se vería el código?

echo "Hola "Juan"";

Error. Se puede ver a simple vista que las cosas no van a salir bien. Estamos cerrando comillas antes de imprimir Juan y luego hay una cadena vacía, pero no estamos concatenando nada… En fin, que no nos funcionaría.

La función htmlspecialchars

Podríamos, por ejemplo, utilizar la función str_replace para reemplezar las comillas dobles por alguna otra cosa, por ejemplo por \” que sí nos mostraba esas comillas dobles dentro de un string de comillas dobles. Pero esta situación también la tendremos con otros caracteres como ampersand (&) o las desigualdades (< y >). Usamos entonces la función htmlspecialchars.

Esta función realiza todas las sustituciones que hemos comentado por sus entidades HTML. Estas entidades son la forma en que estos caracteres se guardan. Por ejemplo, & se guarda como & a m p ; (realmente todo junto, pero si lo pongo así me va a mostrar & sin más) mientras que < se guarda como & l t ; y > se guarda como & g t ; por su parte.

Gracias a ello, podemos tener ahora nuestro programa en PHP así:

$nombre = htmlspecialchars($_REQUEST['nombre']);
echo "Hola $nombre';

Y lo que imprimiría por pantalla dependería de la configuración que tuviéramos activa. Puede que imprimiera esos caracteres especiales o que realizara la “traducción” directa y se imprimiera el mensaje correctamente. Depende de cómo esté configurado, pero lo importante es que el problema se ha solucionado.

Enviar formularios con el método POST

Comentamos que podíamos enviar nuestros formularios con dos métodos: GET y POST. La principal diferencia radicaba en la forma de enviar los datos, pues POST los envía ocultos mientras que con GET podemos ver todos los datos en la URL. Imaginad un formulario con GET y la siguiente URL:

https://programacionbasica.es/conexion.php?user=pedro&password=12345&dni=12345678X

Estamos mostrando todos los datos enviados en la URL, incluso en este caso la contraseña. Hay que evitarlo, al igual que, si podemos, evitar darle al atributo name exactamente el mismo nombre que tiene ese campo en la base de datos. Si no es así, estamos dando una importante pista de cómo está construida nuestra base de datos y para controlar la seguridad en los formularios, cualquier pista debe ser evitada.

Validar datos

Valida absolutamente todos los datos, especialmente cuanto más sensibles sean. ¿Y qué es validar un dato? Pues sencillamente asegurarte de que recibes una estructura que buscas. Por ejemplo, si pides un DNI, valida que esté bien construido y que la letra se corresponda con los números. Si pides una contraseña entre 8 y 30 caracteres, valida que así sea y no hayas recibido una más larga o más corta. Si pides el número del día de tu fecha de nacimiento, valida que es un número y no son letras, que está entre 1 y 31 y que no sea el 31 de febrero, por ejemplo.

Valídalo todo porque, si no es así, como mínimo puedes tener datos que serán incorrectos, pasando por llevar a errores (por ejemplo si esperas números pero guardas cadenas y empiezas a sumar con ellas no recibirás lo que buscas). Y evitando ataques mayores.

Dedicaremos un artículo dentro de unos días a hacer validaciones sencillas de datos.

Utiliza un captcha

¿Sabes lo que es un captcha? Imagino que sí, pues todos nos hemos encontrado alguna vez con ellos. Un captcha es una imagen distorsionada con un código (letras, números o incluso imágenes) para que el usuario los introduzca y se pueda comprobar que no es fraudulento ni un código malicioso. Ayuda mucho a evitar, por ejemplo, el spam. Deja un formulario sin captcha, despliega una web, obtén muchas visitas y verás cómo empiezan a llegar correos desde tus formularios de contacto “extraños”.

Hoy en día Google tiene un gran servicio con reCAPTCHA, lo cual es una muy buena opción para utilizarlo. Incluso, la última versión del captcha es totalmente invisible, es decir, ya no verás el bloque del captcha ni el usuario tendrá que hacer nada, haciéndolo todo Google de forma interna y transparente. Algo que el usuario siempre agradecerá.

Añade un token a tus formularios

Para evitar especialmente ataques como el CSRF (además de asegurarte en tu aplicación que quien ejecuta esa URL es alguien con permisos de administrador) es una buena idea añadir un token. Un token es, básicamente, como una cadena de texto con muchos caracteres, generada en el momento para que no sea igual y utilizada para identificar sesiones.

Son aspectos más avanzados que no hemos visto aún pero, por ejemplo, podríamos generar un token a partir del día, hora, minuto y segundo en el que el usuario accede a un formulario y guardarlo en una variable de sesión (ya veremos mucho más adelante qué es ésto) además de añadirlo en un campo oculto dentro del formulario. Luego, a la hora de procesar el formulario en PHP, primero recuperamos la variable de sesión y comprobamos que el token es idéntico.

Es una explicación rápida y simple para introducir esta forma de añadir seguridad. Es recomendable que veáis y leáis mucha más documentación para conocer más sobre cómo evitar este ataque.

Sanitizar

Esta palabra sirve un poco para definir todo lo que hemos visto en los últimos párrafos. Sanitizar es, dicho rápida y sencillamente, tratar los datos antes de utilizarlos, validarlos y comprobar que son correctos. Y es que nunca debes fiarte de lo que un usuario (avispado o no tanto) coloque dentro de un formulario web. Allá donde leas, para controlar la seguridad en los formularios llegarás en algún momento a la palabra sanitizar.

¿Y cómo evitamos la inyección SQL?

Pese a su importancia, no es objecto de este artículo, aunque algunas técnicas vistas ayudan a minimizar un primer impacto. Simplemente hemos utilizado un buen tiempo a explicar cosas que se pueden hacer para atacar a nuestros formularios para enfatizar en que se debe controlar la seguridad en los formularios.

Sobre el tema de la inyección SQL hay mucho escrito, normalmente de aspectos mucho más avanzados que lo que aquí estamos viendo. Empieza, si quieres saber más, por un artículo general, pero no te quedes sólo ahí y lee bien sobre el tema, porque ese artículo necesita ser más extenso.

Como todavía no hemos llegado, y aún tardaremos, a utilizar bases de datos en nuestros programas, no vamos a dedicarnos ahora a desgranar las posibles soluciones a ello. Simplemente comentar que deberíamos preparar muy bien y con los diferentes métodos que se nos dan, las sentencias SQL para ejecutar en nuestra base de datos y nunca hacerlas de forma directa. Hay métodos para ello.

Métodos ya definidos para tratar con la inyección SQL

Pese a lo comentado, sí podemos indicar algunos métodos que ya están definidos en PHP para tratar de minimizar los ataques, aunque no nos vamos a extender. Principalmente, en PHP, encontramos dos formas de trabajar con bases de datos que están lo bastante extendidas. Son MySQLi y PDO. Con ellas vienen un montón de funciones y guías para el trabajo con bases de datos a las que ya dedicaremos su tiempo en el futuro.

Básicamente, estas dos formas de trabajar con bases de datos tienen métodos para construir previamente las consultas y prepararlas para su óptima utilización, evitando muchos de los problemas vistos en este artículo. Cojamos como ejemplo una consulta SQL que hemos utilizado anteriormente:

SELECT * FROM usuarios WHERE usuario='prueba' AND password='prueba'

Ya hemos visto todo lo que podemos hacer fraudulentamente con esta consulta, así que veamos un ejemplo de cómo actúan estos dos métodos. Por ejemplo, en MySQLi tendríamos la siguiente forma para construir esta consulta (se asume una variable $mysqli que contiene la conexión a la base de datos, otra variable $user con el nombre de usuario y una última variable $password con la contraseña):

$stmt = mysqli_prepare($mysqli, 'SELECT * FROM usuarios WHERE usuario = ? AND password = ?');
mysqli_stmt_bind_param($stmt, 'ss', $user, $password);
mysqli_stmt_execute($stmt);

En este sencillo ejemplo, en la primera línea, “preparamos” la consulta a realizar con la función mysqli_prepare. Pero nos fijamos que colocamos unos interrogantes en el lugar donde deben ir los datos que se proporcionan externamente.

A continuación llamamos a la función mysqli_stmt_bind_param y le pasamos, además de la consulta preparada, una cadena que ahora explicaremos y las dos variables que contienen los datos proporcionados. En esta cadena indicamos a qué tipo corresponde cada uno de los valores, en este caso la s representa un string, pero tenemos también la i para un entero, la d para un decimal y la b para un blob, que es un tipo dedicado principalmente para archivos (un valor booleano se guardará en la base de datos como 1 si es verdadero y 0 si es falso). De esta forma, si se proporciona un número como nombre de usuario, se indicará un error y la consulta será rechazada. Es una forma de sanitizar y validar datos antes de ejecutar la consulta, la cual ejecutaríamos con mysqli_stmt_execute.

Con PDO es bastante parecido, aunque sólo tiene instrucciones adaptadas a la programación orientada a objetos (que veremos dentro de un par de meses). Veamos cómo actuaría en este ejemplo (asumiendo $gdb como la variable que contiene la base de datos esta vez):

$gsent = $gdb->prepare('SELECT * FROM usuarios WHERE usuario = :user AND password = :password');
$gsent->bindParam(':user', $user, PDO::PARAM_STR);
$gsent->bindParam(':password', $password, PDO::PARAM_STR);
$gsent->execute();

También aquí tenemos la preparación de la consulta, pero en lugar de ? (aunque también se puede con ellos) tenemos nombrado el campo y delante dos puntos. Posteriormente indicamos cada campo a qué variable corresponde y de qué tipo es mediante unos tipos que ya tiene predefinidos. Incluso podríamos indicarle la longitud máxima de un string.

Como veis, si queremos prevenir ataques que puedan dañar nuestra base de datos, es muy conveniente utilizar todos estos métodos que ya están diseñados y preparados para ello. Pero siempre debemos seguir extremando precauciones.

¿Qué hay de las contraseñas?

Aunque no es un tema de seguridad “externo” y no dependa de controlar la seguridad en los formularios, hay que tener cuidado con las contraseñas. Nunca, nunca jamás, guardéis una contraseña en “texto plano” en la base de datos. Cualquiera que pudiera ver la base de datos (vosotros mismos) o que supiera cómo acceder a los datos, podría ver las contraseñas tal cual. Y eso es un peligro.

Utilizad siempre alguno de los muchos métodos para encriptar las contraseñas antes de guardarlas en la base de datos. Repetimos, nunca jamás guardéis las contraseñas en texto plano en la base de datos. Dedicaremos algún artículo más adelante a cómo guardar las contraseñas.

La seguridad depende de ti

Recuerda, la seguridad depende de lo mucho que te preocupes por ella cuando estás realizando tus programas, especialmente si vas a recibir datos de los usuarios. El futuro de tu aplicación web penderá de un hilo si no es así, así que si piensas trabajar con formularios y base de datos (y más cosas), empieza a pensar seriamente en controlar la seguridad en los formularios.

Curiosidad
Para ejemplo, este blog. Antes de cumplir el primer mes de vida ya había sufrido un intento de ataque y un par más posteriormente. Supuestamente se hacen muchos ataques a webs de este tipo para introducir SPAM en los comentarios o para enviar masivamente correos basuras. Suerte que la propia seguridad de la página y algunos ajustes adicionales bloquearon el ataque.

En próximos artículos seguiremos hablando sobre formularios y viendo cómo mostrar los datos por pantalla y cómo validar datos. Recuerda que puedes ver todo lo publicado en el índice de contenidos.

Deja una respuesta