Construyendo aplicaciones

Transcripción

1

2 Construyendo aplicaciones seguras con PHP y Judas Borbón Este libro está a la venta en Esta versión se publicó en This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do Ben.edmunds@gmail.com y Judas Borbón

3 Índice general Capítulo 1 - Nunca confíen en los usuarios. Filtren TODAS las entradas de datos Inyección de SQL Asignación Masiva Typecasting Sanitizando información de salida

4 Capítulo 1 - Nunca confíen en los usuarios. Filtren TODAS las entradas de datos. Comencemos con una historia. Mike es un administrador de sistemas para una escuela privada en Oklahoma. Su principal responsabilidad es mantener funcionando la red de computadoras. Hace poco comenzó a desarrollar una aplicación web interna con el objetivo de automatizar diferentes tareas de la escuela. Mike no tiene formación profesional en desarrollo y comenzó a programar alrededor de un año atrás, pero siente que es bastante bueno en lo que hace. Sabe lo básico de PHP y ha creado un sistema para manejo de clientes (CRM) bastante estable. Todavía queda mucha funcionalidad por agregar, pero lo esencial está terminado. Incluso el director de la escuela lo felicitó por agilizar operaciones y ahorrarle dinero a la escuela. Todo iba bien hasta que llegó un nuevo estudiante. El nombre del estudiante es Little Bobby Tables ¹. Un día, John de la oficina administrativa le informó a Mike que el sistema estaba caído. Después de realizar una inspección, Mike se ¹

5 de datos. 2 dio cuenta que la tabla que contenía la información de los estudiantes ya no estaba. Al parecer, el nombre completo de Little Bobby Tables era Robert ); DROP TABLE students;. No hay ningún respaldo de la base de datos; ha estado en la lista de pendientes de Mike por un tiempo, pero nunca lo ha hecho. Mike está en grandes dificultades.

6 de datos. 3 Inyección de SQL El mundo real Aunque es poco probable que el nombre real de una persona contenga código SQL, este tipo de vulnerabilidad por inyección se da en el mundo real todo el tiempo:² En el 2012, se expuso la información de cerca de 6 millones de usuarios de LinkedIn debido a una inyección de SQL no revelada En el 2012, 450,000 contraseñas de usuarios de Yahoo quedaron expuestas En el 2012, 400,000 contraseñas de usuarios de Nvidia fueron comprometidas En el 2012, 150,000 contraseñas de usuarios de Adobe fueron comprometidas En el 2013, se expusieron alrededor de 1.5 millones de contraseñas de usuarios de eharmony Cómo funciona una inyección de SQL? Si se utilizan datos directamente desde un campo de texto, es posible que un usuario haya ingresado información inesperada y provoque que se modifiquen las consultas SQL. Si nuestro código luce así:³ ²Los detalles precisos de estas vulnerabilidades no fueron revelados, es por ello que no podemos estar seguros que ocurrieron debido a inyección de SQL. Aunque en la mayoría de los casos es debido a una inyección. ³La extensión mysql_* y sus métodos están deprecados oficialmente. Por favor no los usen.

7 de datos. 4 1 mysql_query('update users 2 SET first_name="'. $_POST['first_name']. '" 3 WHERE id=1001'); Esperaríamos que la consulta SQL luciera así: UPDATE users set first_name="liz" WHERE id=1001; Pero si un usuario escribe su primer nombre de la siguiente manera: Liz", last_name="lemon"; -- El SQL generado se convierte en: UPDATE users SET first_name="liz", last_name="lemon"; --" WHERE id=1001; Ahora todos los usuarios se llaman Liz Lemon, y eso no es nada bueno. Cómo Protegerse El requisito principal para evitar la inyección de SQL es la sanitización (también conocida como escape). Podemos escapar cada entrada de datos individualmente o usar un mejor método llamado vinculación de parámetros. La vinculación de parámetros es, en definitiva, la medida que recomiendo, ya que ofrece mayor seguridad. El código quedaría de las siguiente manera usando la clase PDO de PHP⁴: ⁴

8 de datos. 5 1 $db = new PDO(...); 2 $query = $db->prepare('update users 3 SET first_name = :first_name 4 WHERE id = :id'); 5 6 $query->execute([ 7 ':id' => 1001, 8 ':first_name' => $_POST['first_name'] 9 ]); Vincular los parámetros hace que cada valor sea filtrado apropiadamente. Sin embargo, hay que tener en cuenta que la vinculación de parámetros protege las consultas SQL pero no protege de los datos que ya han ingresado a la base de datos. Hay que recordar que cualquier valor puede ser malicioso. Es necesario sanitizar la información que vaya a tomarse de la base de datos para ser mostrada al usuario. Esto se puede hacer al momento de almacenar la información o al momento de mostrarla; lo importante es no saltarse este paso. Abordaremos más al respecto en la sección llamada Sanitizando información de salida. Nuestro código ahora es más extenso, pero es seguro. Ya no habrá que preocuparse por otro Little Bobby Tables. La vinculación de parámetros es genial, cierto? Buenas prácticas y otras soluciones Los procedimientos almacenados son otra forma de protección contra una inyección de SQL. Un procedimiento almacenado es una función que se encuentra en la base de datos. Usar procedimientos almacenados disminuye el riesgo de una inyección de SQL, ya que los datos no se mandan directamente a

9 de datos. 6 la consulta SQL. En general, los procedimientos almacenados no son bien vistos. Algunas de las razones principales son: 1. Son difíciles de probar 2. Trasladan la lógica hacia otro sistema fuera de la aplicación 3. Son difíciles de incluir en un sistema de control de versiones por encontrarse en la base de datos y no en el código 4. Su uso puede limitar el número de personas capaces de modificar la lógica, de ser necesario JavaScript NO es una solución para validación de datos. Puede ser alterada o burlada fácilmente por un usuario malicioso que ni siquiera cuente con mucho conocimiento. Repitan después de mi: NUNCA voy a confiar en la validación con JavaScript; NUNCA JAMÁS voy a confiar en la validación con JavaScript. Es posible usarla para proporcionar información inmediata y mejorar la experiencia de usuario, pero por el amor de su deidad favorita, revisen los datos de entrada para asegurarse que son válidos.

10 de datos. 7 Asignación Masiva La asignación masiva puede ser una herramienta muy útil para acelerar el desarrollo, pero también puede causar mucho daño si se usa incorrectamente. Supongamos que tenemos un modelo User el cual necesitamos actualizar. Podríamos actualizar cada campo de forma individual, o podríamos enviar todos los cambios desde un formulario y actualizar todos a la vez. El formulario podría lucir del siguiente modo: 1 <form action="..."> 2 <input name="first_name" /> 3 <input name="last_name" /> 4 <input name=" " /> 5 </form> Luego tendríamos el código PHP que se encarga de procesar y guardar la información. Usando el framework Laravel luciría así: 1 $user = User::find(1); 2 $user->update(input::all()); Rápido y fácil, cierto? Pero, qué tal si un usuario malicioso modifica el formulario para otorgarse permisos de administrador?

11 de datos. 8 1 <form action="..."> 2 <input type="text" name="first_name" /> 3 <input type="text" name="last_name" /> 4 <input type="text" name=" " /> 5 <input type="hidden" name="permissions" value="{\ 6 'admin':'true'}" /> 7 </form> El mismo código ha cambiado los permisos del usuario de forma errónea. Puede parecer un problema muy tonto, pero muchos desarrolladores y sitios han sido víctimas de él. El más reciente y conocido exploit de esta vulnerabilidad ocurrió cuando un usuario descubrió que el framework Ruby on Rails era susceptible. Cuando Egor Homakov le reportó al equipo de Rails que las nuevas instalaciones eran inseguras, su reporte del bug fue rechazado. El equipo pensó que se trataba de un problema menor, el cual los nuevos desarrolladores sabrían cómo evitar. Para atraer la atención hacia el problema, Homakov hackeó la cuenta de GitHub de Rails (GitHub está construido con Rails) para otorgarse permisos de administrador en sus repositorios. No hace falta mencionar que esto probó lo que Homakov trató de demostrar desde un principio y ahora Rails (y GitHub) están protegidos contra este ataque. Cómo podemos proteger nuestra aplicación frente a esto? Los detalles de implementación dependen del framework o código en el que nos estemos basando, pero existen algunas opciones: Desactivar por completo la asignación masiva Poner en una lista blanca los campos que pueden ser incluídos en una asignación masiva

12 de datos. 9 Poner en una lista negra los campos que no deben ser incluídos en una asignación masiva Dependiendo de la implementación, algunos se pueden utilizar simultáneamente. En Laravel agregamos una propiedad llamada $fillable a los modelos para establecer los campos que pueden ser asignados de forma masiva: 1 class User extends Eloquent { 2 3 protected $table = 'users'; 4 5 protected $fillable = ['first_name', 'last_name'\ 6, ' ']; Esto evita que la columna permissions se incluya en la asignación masiva. Otra forma de solucionar esto en Laravel es utilizando una lista negra mediante la propiedad $guarded: 1 class User extends Eloquent { 2 3 protected $table = 'users'; 4 5 protected $guarded = ['permissions']; La decisión sobre usar una lista negra/lista blanca depende de cuál sea más fácil de implementar en nuestra aplicación. Si no usan Laravel, el framework que utilicen probablemente cuente con un método similar. Si utilizan un framework propio les recomiendo implementar esta funcionalidad.

13 de datos. 10 Typecasting Un paso adicional que deberían de considerar, no sólo por cuestiones de seguridad sino también de integridad de datos, es la conversión a formatos conocidos. Ya que PHP es un lenguaje dinámico⁵, sus valores pueden ser de cualquier tipo: cadena de texto, entero, flotante, etc. Al convertir un valor podemos verificar que la información coincide con lo que esperamos. En el ejemplo anterior, si el identificador proviene de una variable tiene sentido hacer la conversión si sabemos que siempre debe tratarse de un valor entero: 1 $id = (int) 1001; 2 3 $db = new PDO(...); 4 $query = $db->prepare('update users 5 SET first_name = :first_name 6 WHERE id = :id'); 7 8 $query->execute([ 9 ':id' => $id, //sabemos que es un entero 10 ':first_name' => $_POST['first_name'] 11 ]); En este caso no hay mucha diferencia puesto que el identificador lo hemos definido nosotros, así que estamos seguros que se trata de un valor entero. Pero si el identificador viniera desde otra fuente, tendríamos la seguridad de tener el tipo de dato correcto. PHP soporta diferentes tipos para conversión: ⁵

14 de datos $var = (array) $var; 2 $var = (binary) $var; 3 $var = (bool) $var; 4 $var = (boolean) $var; 5 $var = (double) $var; 6 $var = (float) $var; 7 $var = (int) $var; 8 $var = (integer) $var; 9 $var = (object) $var; 10 $var = (real) $var; 11 $var = (string) $var; Esto es útil no sólo para tratar con la base de datos, sino también con la aplicación. El hecho de que PHP sea un lenguaje dinámico no significa que no podamos asegurar el tipo de datos.

15 de datos. 12 Sanitizando información de salida Desplegando información en el navegador No hay que tomar precauciones únicamente al guardar información, hay que sanitizar / escapar cualquier información generada por el usuario que vaya a mostrarse en el navegador. Podemos modificar y escapar información previo a guardarla en la base de datos o al recuperar la información para mostrarla. Normalmente depende de cómo se utilice la información. Por ejemplo, si el usuario va a poder editar la información posteriormente, tiene sentido guardarla tal y como es y sanitizarla al momento del despliegue. Cuáles beneficios de seguridad se obtienen al escapar información generada por el usuario? Supongamos que un usuario guarda el siguiente fragmento de código en nuestra aplicación, la cual lo guarda para mostrarlo después. <script>alert('i am not sanitized!');</script> Si no sanitizamos este código antes de imprimirlo en el navegador, el JavaScript malicioso se ejecutará normalmente, tal y como si lo hubiéramos escrito nosotros mismos. En este caso es un inofensivo alert(), pero un hacker no será tan benevolente. Otro lugar común para este tipo de exploit es en la información XIFF de una imagen. Si un usuario carga una imagen y nuestra aplicación muestra la información XIFF, habrá

16 de datos. 13 que sanitizarla también. En cualquier lugar donde vayamos a mostrar información proveniente del exterior, hay que sanitizar. Si usamos una librería para templates o un framework que los maneje, es posible que la sanitización se haga de manera automática o exista un método encargado de ello. Hay que asegurarnos de revisar la documentáción de la librería / framework para averiguar cómo implementar la sanitización. Para quienes lo hagan por si mismos, PHP provee una serie de funciones que serán grandes aliados a la hora de mostrar información en el navegador: htmlentities()⁶ y htmlspecialchars()⁷. Ambas escapan y manipulan información para hacerla más segura antes de desplegarla. htmlspecialchars() sea quizá la opción para el 90% de los casos. Se encarga de encontrar caracteres especiales (p. ej. <, >, &) y tranformarlos a su equivalente en HTML. htmlentities() es como htmlspecialchars() con esteroides. Se encarga de codificar cualquier caracter para convertirlo en su equivalente en HTML, en caso de que exista. Quizá no sea lo que necesitemos en muchos casos. Hay que asegurarse de entender cómo trabajan estas funciones para evaluar cuál es la mejor para el tipo de información que deseamos enviar al navegador. ⁶ ⁷

17 de datos. 14 Imprimiendo en la línea de comandos No hay que olvidar sanitizar cualquier cosa proveniente de un script de línea de comandos. Las funciones encargadas de esto son: escapeshellcmd()⁸ y escapeshellarg()⁹. escapeshellcmd() se usa para escapar comandos; previene la ejecución abritraria de cualquier comando que provenga del exterior. escapeshellarg() se usa para filtrar parámetros con el fin de asegurarse de que sean válidos. No hay que dejar que la aplicación acepte cualquier comando como entrada. ⁸ ⁹