domingo, 5 de abril de 2015

Escapando caracteres para evitar inyecciones de código con PHP

Las buenas practicas de seguridad nos indican, que al desarrollar una aplicación en la que el usuario introduce datos, debemos desconfiar y por tanto filtrar la información que recibimos. Con esto evitamos que un potencial atacante pueda inyectar código y consiga vulnerar nuestra aplicación.

Si por ejemplo recibimos una cadena que contiene código JavaScript:

Ejemplo de código que permite inyección
Ejemplo de código que permite inyección
Al hacer un echo de ésta, el código se ejecutará:

Inyección de código JavaScript
Inyección de código JavaScript

Una manera de evitar lo anterior es tratar los caracteres especiales escapándolos, para ello PHP nos provee algunas funciones:

  • trim: elimina espacios en blanco y otros caracteres especiales al comienzo y al final de una cadena.
  • htmlspecialchars: convierte caracteres especiales en entidades HTML.
  • addslashes: escapa los caracteres especiales que contiene una cadena antecediendolo con un slash.

Con base a lo anterior, una cadena introducida por el usuario se podría tratar así:

 function escapar_caracteres($cadena) {
  $cadena_tratada = trim($cadena);
  $cadena_tratada = htmlspecialchars($cadena_tratada);
  $cadena_tratada = addslashes($cadena_tratada);
  return $cadena_tratada;
 }
Obteniendo un resultado más seguro:

Evitando inyección de código en PHP
Evitando inyección de código en PHP

Si bien este tratamiento de cadenas reduce considerablemente las posibilidades de sufrir un ataque por inyección de código, su sola implantación no convierte nuestro código en una aplicación segura.

Por eso además de tratar los caracteres especiales es de suma importancia realizar validaciones del lado del cliente comprobando que los datos introducidos correspondan con el tipo de campo, configurar adecuadamente nuestro servidor buscando evitar vulnerabilidades de configuración por defecto, utilizar siempre que sea posible sentencias preparadas al realizar operaciones sobre la base de datos, encriptar las comunicaciones tanto al transmitir como al almacenar, y todos los demás principios de seguridad que muchas veces como desarrolladores ignoramos.

sábado, 4 de abril de 2015

El secreto de los dedos de Aignes [Leído]

Una historia que se desarrolle en la Europa de la segunda guerra mundial que combine acción y misterio siempre estará entre mis favoritas, tal vez por eso El secreto de los dedos de Aignes - escrita por Pablo Carnicero - es la segunda novela de este tipo que me leo en un poco más de un mes.

En esta novela su autor, desde la perspectiva del soldado James Villalobos, nos cuenta como un grupo de soldados de élite del ejercito norteamericano son reasignados de unidad y elegidos para desarrollar la importante misión de recuperar algunos tesoros en poder de los nazis, cuyo valor  le ayudará a los ejércitos aliados a financiar la guerra.

El Secreto de los dedos de Aignes
El Secreto de los dedos de Aignes
La historia se comienza a desarrollar en el famoso desembarco de Normandia, a partir del cual sus protagonistas comienzan a vivir una serie de situaciones que desafían el peligro mientras se infiltran en líneas enemigas. Como se explica en su sinopsis, la misión aparentemente sencilla, esconde una maraña de traición, codicia y asesinatos, que le sitúa en el núcleo estratégico de un terrible conflicto entre los dos bandos contendientes.

Durante el desarrollo de la historia se nota el trabajo de su autor por describir muy bien los escenarios de la Europa en guerra, principalmente en Francia, así como los detalles técnicos propios del conflicto que fue la Segunda Guerra Mundial que hacen que la historia aunque sea de ficción se encuentre muy bien sustentada.

Otro punto a favor del libro es que se encuentra escrito en un lenguaje que facilita su lectura, y aunque no ahonda en detalle sobre sus personajes no queda ningún cabo suelto de la historia a pesar de su corta extensión (unas 211 páginas).

Si se busca una historia de acción, con un poco de contenido bélico (contenido necesario para la época y situación que se desarrolla), un poco de historia e incluso un poco de misterio, este libro es una buena alternativa. Yo por mi parte dejo en mi lista de pendientes explorar otras obras del autor que se encuentran disponibles en su página web y que sin duda se ven atractivas.






miércoles, 1 de abril de 2015

Diferencia entre CHAR y VARCHAR en MySQL

Un aspecto importante a la hora de diseñar bases de datos es definir de forma correcta los tipos de datos que se almacenarán en cada campo, ya que esto a largo plazo y dependiendo del volumen de transacciones que maneje la base de datos impactará en su rendimiento.

MySQL provee muchos tipos de datos, los cuales muchas veces resultan ambiguos pero que de fondo difieren en la forma en que son tratadas por el motor. Un claro ejemplo son los tipos CHAR y VARCHAR que nos permiten almacenar cadenas alfanuméricas, los cuales ha simple vista parecen iguales pero que como veremos a continuación difieren en la longitud máxima permitida, en la manera en que son almacenados, y en como son recuperados tal y como se explica a continuación.

Cuando se declara un valor tipo CHAR el campo se crea con la longitud fija indicada al crear la tabla, la cual debe ser entre 0 y 255. Dado que es un tipo de longitud fija, al momento de almacenar datos en una columna CHAR, se rellenará con espacios en blanco las posiciones que no son ocupadas por los caracteres de la cadena que se está almacenando, caracteres que se eliminan cuando el dato es recuperado.

En contra parte los campos tipo VARCHAR son de longitud variable que deber ser entre 0 y 65.535. Cuando se declara un valor tipo VARCHAR MySQL reserva 1 o 2 Bytes para ser usados como un prefijo de longitud, que almacena el valor de la longitud en Bytes de la cadena que se está almacenando. Si la cadena tiene una longitud de 255 o menos reserva 1 Byte, si la longitud es de 256 hasta 65.535 reserva 2 Bytes.

Con base a lo anterior podemos concluir que VARCHAR es más adecuado para cadenas que superan los 255 caracteres de longitud; sin embargo por ser un tipo de datos estático, CHAR tiende a ser más rápido que VARCHAR lo cual lo convierte en la mejor alternativa si lo que se busca es el performance.

Un ejemplo de uso correcto de estos tipos de datos sería: usar CHAR para almacenar los hashes de contraseñas encriptadas con SHA1 ya que este algoritmo siempre genera cadenas de 40 caracteres, y usar VARCHAR para almacenar datos como direcciones o nombres de personas ya que estos datos son de longitud variable.

Más información en https://dev.mysql.com/doc/refman/5.0/en/char.html

martes, 31 de marzo de 2015

Escribiendo código con estilo

Personalmente opino, que una de las competencias básicas que debe tener todo desarrollador es la capacidad de adaptación al cambio, ya que en un mercado tan cambiante y dinámico como lo es el de la tecnología, y más concretamente el de desarrollo de software, aferrarse a viejas costumbres y mantenerse en las mismas habilidades nos reduce la competitividad.

De igual forma, para que esa adaptación al cambio sea exitosa, debe ir acompañada de metodologías apropiadas y de buenas prácticas que permitan hacer las cosas con la mejor calidad posible. Una buena práctica a la hora de aprender y adoptar un nuevo lenguaje de programación es seguir una guía de estilo para escribir código en ese determinado lenguaje de programación.

Una guía de estilo para un lenguaje de programación no es más que un conjunto de recomendaciones, con las cuales se busca que el proceso de escribir código sea lo más uniforme posible basándose en buenas prácticas que generalmente surgen desde una comunidad de desarrolladores, compañía,  o institución. Con esto se logra que el código escrito por una persona sea inteligible para otras; logrando así una mayor reutilización del código, agilidad en el desarrollo, facilidad de mantenimiento de las aplicaciones, estandarización, escalabilidad, y demás beneficios inherentes a las metodologías de desarrollo ágil cuyo uso está tan extendido hoy en día.

En términos generales una guía define aspectos relevantes a la hora de escribir código como lo son el manejo de espacios, tabulaciones, y saltos de línea; manejo de la documentación y comentarios en el código; notaciones para nombrar objetos como variables, constantes, clases, y demás elementos que provee el lenguaje;  uso de los operadores y símbolos; entre otros aspectos.

No existe una guía de estilo única, pues cada uno está condicionado al lenguaje para el que fue diseñado e incluso una guía de estilo no está ligada únicamente a un lenguaje de programación, sino también a productos que se desarrollan con determinadas tecnologías. Un claro ejemplo de esto último es el Kernel de Linux que tiene una guia de estilo propia para la escritura de código, a pesar de que está desarrollado dos lenguajes de programación distintos (C y ensamblador).

La mayoría de lenguajes de programación cuentan con una o más guías de estilo, entre las que podemos destacar la guia PSR-4 (antes existió la 1, 2 y 3) para PHP, la guia para PEAR, la PEP8 para Python, la guía de W3Schools para JavaScript e incluso la de jQuery para el mismo lenguaje. De hecho Google propone guías de estilo para muchos lenguajes como C++, Python, HTML, CSS, entre otros; sólo basta con navegar por la red para encontrar y estudiar interesantes propuestas.

Conclusión

La adopción de una guía de estilo no es una camisa de fuerza; sin embargo si queremos ser competitivos en el mercado del software, si queremos que nuestro código sea comprensible para otras personas, si queremos mejorar el trabajo en equipo, o si simplemente queremos hacer las cosas con la mejor calidad, adoptar una guía de estilo es sin duda una buena practica que debemos implementar en nuestros proyectos.

viernes, 13 de marzo de 2015

Mensaje "304 NOT MODIFIED" en HTTP

Cuando estamos depurando aplicaciones web, y más concretamente analizando el tráfico HTTP entre el servidor y el cliente, es normal que aparezca de forma recurrente un mensaje 304 NOT MODIFIED.

Mensaje 304 de HTTP
Mensaje 304 de HTTP

Si consultamos el protocolo HTTP (RFC 2616), veremos que los mensajes que comienzan por 3 hacen referencia a las operaciones de redirección que requieren la intervención del Agente de usuario, por lo cual el mensaje 304 no representa es un error. 

Con base a lo anterior no debe ser una preocupación que aparezca este mensaje, ya que el servidor nos está informando que el recurso solicitado desde la última vez que lo pedimos no ha sufrido cambios, y por lo tanto será servido desde la chaché.