Jdiezfoto » Informática

Internet, ¿Qué es y como funciona?

Juan — Thu, 12 Apr 2012 11:07:01 +0000

Imagen obtenida de Wikipedia.org

Seguramente ha llamado la atención el título de la entrada, no es una pregunta que se haga uno muy a menudo, lo usamos, lo conocemos y con eso nos vale.

Pero, realmente sabemos lo que estamos usando y que hay detrás de todo ello. Pues eso es justamente lo que pretendo con esta entrada, concretar un poco los conocimientos que tenemos sobre Internet. Todo esto viene de un trabajo que he tenido que hacer en la Universidad y elegí este tema a investigar y preparar una presentación, y después de acabarlo me he dado cuenta de todas las cosas interesantes que he descubierto y quiero compartirlo con vosotros.

No es fácil encontrar un sitio que te diga que es Internet, llegar a una conclusión razonable es un trabajo de “bucear” por la red e ir sintetizando y uniendo trozos de la información que se va encontrando. Dicho esto es de suponer que en este artículo serán abordados muchos temas para conocer como está formado Internet; por lo tanto la lectura ha de ser tranquila, y en caso de no entender algo siempre que conozca la respuesta intentaré aclararla

Voy a dividir el artículo principalmente en dos partes fundamentales, una parte más técnica y otra parte orientada a todos los públicos con curiosidades varias sobre la topología de Internet, empresas y finalmente un tema a simple vista sencillo pero muy interesante: los cables submarinos. Y, finalmente lo que haré será dejar a vuestra disposición la presentación que hice como resultado de este trabajo de búsqueda de información.

1. Introducción

Internet tiene sus orígenes en el año 1969 con el nacimiento de ARPANET (Advanced Research Projects Agency Networks), una red construida con el fin de interconectar los ordenadores de varias universidades de los EEUU, que posteriormente se convirtió en un proyecto militar. Si actualmente me pidieran que definiera lo que es Internet con las menos palabras posibles diría que es un conjunto de redes de varias empresas interconectadas; denominando a cada una de esas redes Sistemas Autónomos (AS – Autonomous System).

Si queréis conocer más acerca de la historia de Internet han publicado un interesante artículo en Omicrono en el que se presenta un vídeo bastante interesante. Lo recomiendo.

1.1. Sistema Autónomo

Como hemos dicho un Sistema Autónomo es una de las redes de las que hablábamos que compone Internet, pero más formalmente estaríamos hablando de un conjunto de encaminadores y redes que son gestionados por una única empresa. Y, esos encaminadores como resultado de estar todos dentro de un mismo Sistema Autónomo han de intercambiar información de encaminamiento mediante un protocolo común.

Comunicaciones y Redes de Computadores - William Stallings

Hablando de Protocolos vamos a distinguir entre dos tipos, el usado en el interior de un Sistema Autónomo y el protocolo que sirve de unión entre todos los Sistemas Autónomos.

IRP. Interior Router Protocol: Es el protocolo de encaminamiento usado dentro de un mismo Sistema Autónomo, no ha de ser el mismo en todos los AS.

ERP. Exterior Router Protocol: Este es el protocolo encargado de transmitir información de encaminamiento entre todos los Sistemas Autónomos, este será igual en todo Internet; en la actualidad el protocolo usado para este fin es BGP (Border Gateway Protocol). Este protocolo no necesita conocer el interior de un Sistema Autónomo; en definitiva este protocolo solo necesita saber el AS objetivo y los Sistemas Autónomos que tiene que atravesar para llegar al mismo.

1.2.- Algoritmo de Dijkstra

Este va a ser un algoritmo que vamos a presentar en la introducción para usarlo posteriormente en la explicación de OSPF (Open Shortest Path First), el protocolo de encaminamiento interior por excelencia. En definitiva, el objetivo de este algoritmo será encontrar los caminos más cortos desde un nodo origen hacia el resto de los nodos.

Si empezamos a vislumbrar el asunto nos damos cuenta de lo bueno que sería que cada encaminador dentro de un Sistema Autónomo conociera el resto de la topología del AS y con ella encontrar los caminos más cortos hacia el resto de los encaminadores con este algoritmo; pues, veremos más adelante que eso es exactamente lo que se hace.

Definamos una serie de aspectos necesarios para explicar el algoritmo.

N: Conjunto de nodos de la red
s: Nodo origen
T: Conjunto de nodos incorporados por el algoritmo
w(i, j): Coste desde el nodo i hasta j
L(n): Coste en curso obtenido para el camino de mínimo coste desde el nodo s hasta el nodo n

Comunicaciones y Redes de Computadores - William Stallings

Una vez que ya hemos definido las variables que necesitamos nos ponemos a ver en que consiste el algoritmo; consta de tres pasos, el primero de ellos de inicialización y los dos siguientes son los que se repetirán iteración tras iteración hasta que se hayan añadido a T todos los nodos de N, que será el momento en el que se han asignado las rutas finales a todos los nodos de la red.

Consiste únicamente en añadir el nodo origen al conjunto T y posteriormente anotar el coste de los caminos hacia los nodos alcanzables desde el nodo origen.
Tiene como objetivo la búsqueda del siguiente nodo para añadir al conjunto T, que ha de ser el más cercano al nodo origen (hablando de costes) y que no se haya añadido previamente a T.
En este paso lo que haremos será recalcular el coste desde el nodo origen hacia todos los nodos (que sean alcanzables con los nodos añadidos a T), puesto que al añadirse un nodo a T se ha abierto la posibilidad a más rutas posibles y puede que con menor coste que las que se tenían anteriormente.

En la presentación que voy a dejar disponible se puede ver más en detalle el algoritmo junto con un ejemplo como el que podemos ver en la imagen pero realizado paso por paso.

2. OSPF (Open Shortest Path First)

También llamado como protocolo del camino más corto disponible, como ya se ha dicho es el protocolo de encaminamiento interior por excelencia.

Como ya se ha ido adelantando, el objetivo es hayar los caminos con menor coste a través de la interconexión de redes. Se caracteriza por ser capaz de equilibrar la carga entre varios caminos de igual coste.

Una de las grandes ventajas que tiene es que el coste es totalmente configurable, podemos usar métricas atendiendo al retardo, velocidad de transmisión, costes económicos u otros factores.

Consigue realizar estas tareas gracias a que es capaz de almacenar en su interior un grafo que representa toda la topología de la red y aplicar sobre él el Algoritmo de Dijkstra que ya hemos comentado para obtener los caminos mínimos hacia el resto de los encaminadores o redes del Sistema Autónomo y como resultado de este árbol construye la tabla de encaminamiento de manera totalmente automática.

De nuevo comento que en la presentación que dejo a vuestra disposición al final del artículo podemos encontrar el detalle de la construcción del grafo a partir de la topología de red con las explicaciones necesarias y con el ejemplo correspondiente.

3. BGP (Border Gateway Protocol)

Entender este protocolo es la clave de la cuestión que hoy nos atañe, entendiendo su objetivo es como realmente nos podemos hacer una idea de como funciona Internet, de como es capaz de llevar nuestros datos de un extremo a otro del mundo y saber exactamente la ruta que ha de seguir para ello; que para mí fue la pregunta clave que me llevó a elegir este tema para el trabajo.

También conocido como Protocolo de Pasarela Frontera. Es el usado para intercambiar información de encaminamiento entre todos los Sistemas Autónomos; con este protocolo nodos de diferentes AS decidirán ser vecinos e intercambiar información de encaminamiento poniendo unos en conocimiento de otros las redes que son alcanzables desde cada uno de ellos y los AS que se han de atravesar para alcanzar dichas redes.

El protocolo se basa principalmente en obtener las rutas hacia cada una de las redes y posteriormente el paso clave, cuando un encaminador obtiene una ruta para un conjunto de redes comparte esa información con sus vecinos de manera que poco a poco se van formando las Bases de Datos de las redes alcanzables y las rutas que se han de seguir en cada uno de los encaminadores de la interconexión de redes que implementen BGP. Imaginando este paso que describo a lo grande, con las dimensiones de Internet es como uno se llega a hacer a la idea de como funciona y como cada uno de los encaminadores saben exactamente lo que han de hacer para transferirse la información entre ellos.

Al igual que ya he comentado en apartados anteriores se puede seguir el tema con más rigurosidad en la presentación que dejo a vuestra disposición en donde se pueden encontrar ejemplos de los casos que propongo junto con el protocolo en detalle con sus tipos de mensajes y operaciones posibles.

4. Punto Neutro

A partir de este momento es donde orientamos el artículo de manera totalmente diferente, más orientado a todos los públicos y explicando como se forma Internet, las empresas que lo componen, tipos de acuerdos entre ellas y conceptos importantes como el que vamos a definir ahora.

IXP (Internet Exchange Point) o NAP (Network Access Point). Es una infraestructura física en la que se intercambian tráfico de Internet varios operadores entre sí. La ventaja de ello es hacer una interconexión directa entre ellos en vez de hacerlo a través de las redes de terceros. En definitiva está compuesto por uno o varios conmutadores de los ISP (Internet Service Provider) participantes en dicho Punto Neutro.

Conmutador de Fibra Óptica en el Punto Neutro de Amsterdam AMS-IX. Imagen de Wikipedia.org

Otra de las ventajas del uso de un Punto Neutro viene dada por cuestiones económicas; el tráfico que atraviesa un IXP no es facturado. Únicamente cuando el IXP lo han de mantener los ISP pagan por la velocidad del puerto que estén usando cada uno, pero en ningún caso pagan por el volumen de tráfico transferido.

En España disponemos de Espanix, el Punto Neutro Español, es el noveno en términos de tamaño del mundo y lo tenemos situado en Madrid en el CPD de Banesto. Como curiosidad comentar que está a disposición del público el volumen de tráfico que atraviesa este IXP. Es probable que pensemos que esto únicamente sirve como dato de curiosidad, pero recientemente he descubierto que su utilidad va mucho más allá; por ejemplo he visto su uso como medio para medir el impacto de la reciente Huelga General en Internet.

Por algún otro Punto Neutro podríamos hablar de DE-CIX situado en Alemania, el que se dice que es el más grande del mundo con un tráfico medio diario de 900 Gbs y 3 Tbs de pico; pueden servir estas cifras para hacernos una idea del volumen de tráfico que puede llegar a atravesar un IXP.

Finalmente nombremos a AMS-IX, el Punto Neutro de Amsterdam que se puede ver en la imagen; del que también podemos ver los participantes y las estadísticas de tráfico.

5. Core Router

Lo que significa en español Router de núcleo. Es el concepto usado para denominar a los routers que se usan en el núcleo de Internet; es decir, serán los router usados en el Internet Backbone (espina dorsal de Internet) y en los Puntos Neutros.

Son equipos con soporte para los protocolos enrutamiento usados en Internet como los que ya hemos visto tanto para el interior de un Sistema Autónomo (OSPF) como para la interconexión de estos (BGP) y lógicamente con varias interfaces de gran capacidad para el reenvío de paquetes IP a gran velocidad por cada una de ellas.

6. Peering y Tránsito IP

En este apartado lo que haremos será ver los tipos de acuerdos que llevan a cabo las operadoras o ISP entre sí.

Tránsito IP: Acuerdo que permite enviar y recibir tráfico entre operadores que no tienen una conexión directa entre sí. La conexión se hace a través de un tercero al que se le tiene que pagar.

Peering: Enlace entre dos operadores directamente conectados. El tráfico es originado en uno de ellos y con destino el otro. En este caso al ser un intercambio de tráfico habitualmente el pago es ese mismo intercambio.

Podemos ver un ejemplo en los participantes del Punto Neutro de Espanix, en donde podemos encontrar los acuerdos entre los diferentes ISP participantes así com observar que no siempre son conocidos los acuerdos entre operadores al no ser públicos, a lo que hago mención en el siguiente apartado.

7. ISP Tier

Como se puede esperar en algo tan grande como es Internet deben existir una serie de niveles para lograr la mejor organización posible. No existe una autoridad encargada de definir los niveles que intervienen en Internet, pero aún así se suele distinguir entre tres niveles.

Imagen obtenida de Wikipedia.org

ISP Tier 1: Se podría definir como el nivel de ISP que puede alcanzar Internet sin llegar a ningún tipo de acuerdo con terceros. A veces no es posible saber si realmente un ISP es de nivel 1 porque no todos los acuerdos entre operadores son públicos, muchas veces los acuerdos entre ellos no son conocidos.

Hay varios ISP de nivel 1, los podemos encontrar en el enlace que he dejado, pero podríamos destacar Global Crossing y Level 3 (antes dos empresas que actualmente están unidas); normalmente este tipo de empresas no proporcionan demasiada información sobre su red, aunque sí un mapa de la topología de su red; un ejemplo de ello es el que se puede ver en la web de Global Crossing y Level 3. Podemos por ejemplo ver también la topología de red de Cogent Communications o la de Telefónica Wholesale Services.

ISP Tier 2: Son aquellas redes que necesitan de un ISP Tier 1 para alcanzar Internet; se dice que son los clientes de los ISP Tier 1 y estos son los proveedores. Normalmente tienen una cobertura nacional o regional. En el enlace que he proporcionado se puede ver un ejemplo de los mismos junto con los acuerdos conocidos entre ellos; es decir, una lista de los ISP de nivel 2 junto con los ISP de nivel 1 con los que tienen acuerdos de tránsito para alcanzar Internet.

ISP Tier 3: Una red que únicamente adquiere tránsito IP de otras empresas para alcanzar en Internet.

8. Topología Abstracta de Internet

Con esto me quiero referir a unos curiosos mapas que nos podemos encontrar por Internet cuando buscamos la topología del mismo (como el que podemos encontrar en la cabecera de este artículo). En primer lugar, como se puede esperar después de lo explicado sobre como se forma Internet; no se puede encontrar un mapa de la topología de Internet completo, son muchas empresas las que lo componen y eso imposibilita la elaboración de esta topología, lo que nos podemos encontrar como ya hemos visto es la topología de la red de los diferentes operadores.

Otro caso es el de los mapas abstractos de los que os hablaba que en definitiva son el resultado de varios estudios con el fin de comprender el volumen de Internet; estos resultados se representan en forma de red neuronal que es lo que nosotros vemos cuando buscamos por la Topología de Internet.

Podemos ver un muy buen ejemplo de la topología de Internet en un estudio de ATT Labs. Es un pdf, recomiendo ampliarlo para visualizarlo en detalle.

9. Cables Submarinos

Lo cables submarinos no dejan de ser un cojunto de fibras ópticas destinadas a su utilización bajo el mar, y por ello son algo distintas de las que podemos ver en cualquier otro sitio.

La fibra óptica es capaz de transmitir la luz con unas ligeras pérdidas; el problema es que se suele decir que la fibra es un producto perfecto e inmejorable, luego es de esperar que si se quiere transmitir luz con una mínima pérdida haya que investigar sobre otras soluciones posibles. Por ejemplo, se está observando un animal de las profundidades llamado Ratón Marino (Aphrodita aculeata) que, está recubierto por unas fibras que al parecer por su estructura son capaces de transmitir la luz con una mínima pérdida.

Imagen obtenida de Wikitel.info

Aún así, se puede afirmar que 12 fibras pueden abastecer las comunicaciones de un País entero (de forma genérica sin tener en cuenta el tamaño del País).

Cuando estamos hablando de los cables submarinos no solo nos preocupa la fibra sino que nos preocupan muchos aspectos más como son la composición y capas de clable; los cables deben de soportar todo tipo de incidencias, como mordeduras de animales, anclas de los barcos, redes de pesca…

Si os ha gustado el tema de los cables submarinos después de leer el artículo se pueden ver dos interesantes documentales acerca del tema. Uno del Discovery Channel, y otro del Canal Odisea (buscando “internet submarino” en Youtube podemos ver las 4 partes que lo componen).

9.1.- Instalación

La colocación de los cables sobre el lecho marino es una operación que nos puede parecer simple; pero no es en absoluto una operación trivial, por ello merece la pena una pequeña observación sobre las tareas que se llevan a cabo en la operación.

Animación obtenida de Wikitel.info

En primer lugar lo que se debe de hacer es cargar los cables en los barcos cableros (barcos especiales destinados a este fin); esto es un proceso manual en el que se va enrollando el cable en las gigantescas bobinas de los barcos; y a todo ello hay que sumar la carga de los repetidores (aparatos encargados de repetir la señal cada cierta distancia para evitar su pérdida) cada 50-100 Km de cable, que es otra operación muy delicada.

Una vez que los barcos han sido cargados se pasa a la instalación de los cables, empezando por la estación terminal en tierra, en la que se ha de fijar correctamente el cable para evitar tirones y otros problemas como consecuencia de lo que pase en el mar. Posteriormente, una vez ya en el mar lo que se hace es ir enterrando el cable según se va soltando del barco mediante una pieza especial llamada arado. El barco irá siempre a una velocidad constante independientemente de las condiciones en las que este el mar, de tener una velocidad variable el cable podría partirse por su propio peso al caer del barco; de ahí la extrema delicadeza con la que se han de realizar todas las operaciones.

Como medida de protección en las proximidades de las cosas los buzos se van encargando de cubrir el cable con piezas de acero para evitar en la mayor medida posible los golpes de los anclas de los barcos.

9.2. Reparación

Pues sí, los cables submarinos tienen que ser reparados a pesar de los medios y esfuerzos que se gastan en la instalación de los mismos; y además, la reparación de estos cables puede costar cientos de miles de euros o incluso millones, es un proceso costoso y complicado.

El proceso en primer lugar para el usuario es transparente, ya que por cada fibra instalada en el lecho marino hay conexiones de apoyo para los casos en los que se producen las roturas y que ello no suponga la suspensión completa de la comunicación.

Los fallos en los cables son detectados desde las estaciones terminales; desde las que es posible detectar el kilómetro exacto en el que se ha producido la rotura del cable. Una vez que se ha detectado se ha de enviar el barco para las reparaciones, una vez que el barco está en las proximidades del cable se envían señales eléctricas desde la estación terminal, las cuales el barco es capaz de detectar.

En las estaciones terminales están situados unos equipos llamados PFE (Power Feer Equipment. Equipo de Alimentación Eléctrica), cuya función consiste en la gestión energética de los cables submarinos (sí, llevan energía eléctrica a parte de luz, los repetidores necesitan alimentación para cumplir su función). Desde estos equipos es desde donde son enviadas las señales eléctricas para que el barco las detecte.

Animación obtenida de Wikitel.info

Las señales cumplen una doble función, en primer lugar ayudan al barco a localizar el cable exactamente y también ayudan a detectar el punto exacto de la rotura, ya que donde se corte esa señal será donde se ha producido la rotura del mismo.

Una vez que se ha detectado la rotura lo que se hace es enviar un robot al lecho marino, dicho robot tendrá que desenterrar el cable y subirlo a bordo en donde se tendrá que cortar para después unir los dos extremos. Cuando hablamos de unir los dos extremos no hablamos de unir un hilo de cobre de nuestra casa, estamos hablando de un proceso costoso llevado a cabo por personal cualificado para unir fibras ópticas y en un lugar especial del barco totalmente limpio y sin partículas de polvo. El proceso puede llevar aproximadamente unas 24 h.

Una vez que se ha llevado a cabo la unión se deberá comprobar el funcionamiento correcto del cable y en caso de que la comprobación sea positiva se volverá a dejar de nuevo el cable en el lecho marino.

Pues hasta aquí he llegado con mi particular investigación sobre el tema, me parece un tema que es muy interesante y del que sin duda me queda mucho por averiguar; pero lo que no cabe duda es que con este pequeño acercamiento he aprendido muchas cosas y concretado muchas cosas que hasta ahora para mí solo eran suposiciones.

Os dejo también aquí un interesante enlace hacia la web de Akamai donde podemos ver estadísticas variadas del uso de Intenet a nivel mundial.

Como lo prometido es deuda, os dejo la presentación que llevo prometiendo todo el artículo: Presentación “¿Qué es Internet?”.

Espero que os haya resultado interesante el artículo y ya sepáis un poco más acerca de aquello que usamos todos los días y no sabemos que es lo que hay detrás de todo ello.

Finalmente quisiera agradecer desde aquí a Víctor Manuel López Millán, profesor de la Universidad San Pablo CEU, por su labor como profesor por conseguir desperar el interés por la materia y lo relacionado con ella y fomentar el auto-aprendizaje de esta manera.

Artículos más comentados

Spotbros: Un ejemplo de como hacer las cosas bien

Juan — Tue, 21 Feb 2012 10:38:48 +0000

Esta semana pasada navegando por una de mis webs sobre Android me encontré con una nueva aplicación al estilo Whatsapp, pero bien distinta; el artículo me convenció y decidí probarla y la sorpresa ha sido tan agradable que aquí estoy escribiendo un artículo sobre ella.

La aplicación se llama Spotbros, es nueva, acaba de salir en enero y está en versión beta; se trata de una aplicación de mensajería instantánea vía internet por push al estilo de Whatsapp, pero seguro, bien hecho y encima con unas ideas añadidas bastante interesantes e innovadoras.

Convendría comentar que no estaría escribiendo esto sino me hubiera llamado tan gratamente la atención en muchos aspectos, comencemos describiendo la aplicación.

Como he dicho no es algo nuevo, ya existe, lo tenemos, pero… ¿lo que tenemos es lo mejor? Yo diría que no, entre funcionamiento, fiabilidad, calidad y seguridad hay diferencias; muchas veces parece que importa más el que primero saca la idea que el que saca la idea con mejor calidad.

Pues si es algo que ya tenemos habrá que ver las diferencias ¿no?. Pues vamos a ello; en primer lugar es seguro, todas las comunicaciones son encriptadas usando AES de 256 bits, uno de los algoritmos de encriptación más seguros que hay. Mayor privacidad, todo rastro de nuestras conversaciones es borrado de sus servidores a los 30 días y nadie nos puede hablar sino le conocemos, es necesario que los dos extremos de la comunicación tengan al otro usuario en la agenda. Mayor eficiencia y fiabilidad, a pesar de estar en beta he notado una aplicación muy fluida y sin ningún cuelgue, e incluso he notado menor consumo de batería que con otros servicios.

Y además, no solo han mejorado lo existente por mucho sino que han añadido nuevas funcionabilidades bajo mi punto de vista interesantes e innovadoras.

Veamos que cosas son las que han introducido como nuevas.

En primer lugar, se permiten grupos, pero… ¿solo grupos? Pues no, tiene la opción de los grupos tradicional y una nueva forma de grupo bajo el nombre de spots. Grupos asignados a un lugar, se pueden crear y unir a ellos, y se muestran los que hay a tu alrededor, una forma de añadir a la aplicación funciones sociales que pueden ser muy útiles.

Y finalmente, un añadido más, ellos lo llaman shouts, pero se podría llamar un mensaje de broadcast, o un mensaje a todo el mundo; esta función manda un mensaje a todos en un radio de 1.5km. Sin duda algo muy interesante para poder mandar comunicaciones a tu alrededor, y podría ser de mucha ayuda ante una emergencia por ejemplo. Algunos podrán pensar que esto puede ser un medio de spam, pero lo cierto es que los chicos de Spotbros lo saben y tienen en mente numerosas ideas interesantes para evitar esto.

También han mejorado lo ya existente en el envío de mensajes, en concreto en lo que se refiere a los mensajes multimedia. Permiten enviar varias imágenes en un mismo mensaje; y lo que ahora son fotos en próximas versiones serán fotos, vídeos, audio y mapas todo ello en un mismo mensaje. No cabe duda de que lo que tenemos ante nuestros ojos es una obra de la innovación que en este caso va de la mano con la calidad.

Bueno, y por terminar comentar algo acerca del soporte, no he visto soporte igual en mucho tiempo, respuesta en poco tiempo, una respuesta personalizada, simpática, interesándose por un problema, muy educados, y además eficientes.

La aplicación de momento está disponible para android y para iphone está en desarrollo; de manera que también es multiplataforma.

Bueno, finalmente hacer notar que esto no es un artículo patrocinado ni nada que se le parezca, simplemente he probado la aplicación, me ha dado una muy grata sorpresa y creo que tiene mucho potencial detrás, y de ahí que este escribiendo este artículo.

Lo malo: todavía, como es normal no lo tiene mucha gente, pero creo sinceramente que con este potencial puede llegar muy lejos, solo necesitan nuestra ayuda para crecer poco a poco.

NOTA: Las imágenes del artículo son propiedad de Spotbros Technologies S.L.

Artículos más comentados

JRebel: Stop Redeploying

Juan — Sat, 18 Feb 2012 12:18:11 +0000

Esta semana que se va ha sido el SpringI/O en la Universidad San Pablo CEU, mi universidad. Mi función en este evento ha sido básicamente ayudar en lo que he podido, lo que no quita que haya podido ver cosas realmente interesantes, y entre ellas de la que hoy os voy a hablar: JRebel & LiveRebel.

Ambos productos de la empresa ZeroTurnaroud proveniente de Estonia. Tienen como idea principal facilitar al desarrollador de aplicaciones web la tediosa tarea de guardar, para el servidor y redesplegar. Ahora estas tareas se harán de manera totalmente transparente a nosotros. Veamos la idea principal de ambos productos.

JRebel: Para desarrolladores

El la idea final del producto es ayudar a los desarrolladores Java EE y ahorrarles tiempo en tareas tediosas que se dan en este entorno. Esto es, cada vez que hacemos cambios en una aplicación hay que guardar los cambios, parar la aplicación y redesplegar la aplicación de nuevo en el servidor de aplicaciones.

Aunque este problema este medianamente solucionado por lo menos en NetBeans que sí permite realizar estas acciones en caliente la solución no funciona para todos los tipos de cambios.

Y aquí es donde entra JRebel, el cual realiza estas tareas para tí de manera automática y transparente, y no solo eso sino que admite todo tipo de cambios (los podemos ver en su web). Y no solo eso, sino que soporta los principales IDEs (NetBeans, Eclipse… ) y servidores de aplicaciones (GlassFish, Tomcat, SpringSource, JBoss …).

Hoy nos han hecho una demo a varios compañeros y a mí y he de decir que funciona realmente bien. Me parece una herramienta realmente útil para desarrolladores.

El inconveniente: Es de pago, aunque hay varias versiones dependiendo de las características con precios diferentes; y también una versión gratuita para usos no comerciales. Y algo realmente interesante es la posibilidad de probar gratuitamente la versión completa durante 30 días.

LiveRebel: En producción

La idea de este producto es algo más complicada, orientada a las aplicaciones en producción y con un público más reducido.

Se trata de extender la idea de JRebel a un entorno de producción permitiendo principalmente actualización de las aplicaciones en caliente; la idea es retener las peticiones al servidor mientras la nueva versión de la aplicación es desplegada en el servidor y posteriormente pasar las peticiones al servidor como si nada hubiera ocurrido.

Tiene también otra serie de funciones como la comparación de versiones, integración contínua …, aunque sin duda alguna la más interesante de ellas me ha parecido la primera. No obstante, hoy se debatía entre los que estábamos viendo la demo la utilidad real de este proyecto, ya que, al fin y al cabo la mayoría de las veces no es un gran inconveniente parar el servidor por un corto periodo de tiempo para actualizar la aplicación web.

Esta herramienta como era de esperar tampoco es gratuita, y también consta de varias versiones con varios precios dependiendo de las características. Tiene disponible una evaluación de 90 días.

En resumen, JRebel me parece una fantástica herramienta que puede ayudar a muchísimos desarrolladores y ahorrarles mucho tiempo en el desarrollo de aplicaciones web.

He de recalcar que este artículo no es ningún tipo de patrocinio, se ha escrito porque vi la demo y lo que me contaron y me ha parecido que debería darse a conocer en más idiomas.

NOTA: Las imágenes son propiedad de ZeroTurnaround.

Vanadium: Validación de formularios con JQuery

Juan — Wed, 01 Feb 2012 09:05:13 +0000

Recientemente he anunciado en el blog por medio de una pequeña anotación que había sido subsanado uno de los problemas que tenía la tienda online en Java EE. La tienda había sido dotada de un mecanismo para validar en el registro si un email estaba ocupado o no, pero esta función no llegó a funcionar (aunque sí estaba implementada) por razones que hasta hace poco desconocía.

Dicho esto, creo que una vez solucionado este problema podría ser un buen momento para que os hablara en profundidad de las validaciones realizadas en los formularios de la tienda en el lado del cliente.

Creo que sería una buena manera de empezar siendo sinceros y comentando que no soy ni un experto en JavaScript ni en JQuery, sin embargo si he aprendido a realizar la tarea que os voy a mostrar hoy a base de investigar bastante sobre el asunto concreto que esta vez nos atañe y de luchar para que aquello funcionara correctamente.

Cuando me dispuse a realizar las validaciones de la tienda online lo primero que busqué fue una solución rápida al problema, recordemos que se trataba en un principio de una práctica, y como tal, con una fecha de entrega; así que, lo que hice fue buscar alguna librería de JQuery que me solucionara el problema. Al realizar la búsqueda mi primer resultado fue Vanadium, y esa fue la que usé y la que os voy a explicar hoy aquí. Lo que, no quita que no haya otras librerías de validación.

Respecto a la librería que yo he utilizado llamada VanadiumJS cabe destacar la sencillez de su configuración además de que es fácilmente personalizable para adaptarla a nuestras necesidades. Vamos a ver como funciona.

Instalación

Para empezar, lo primero que haremos es explicar como hemos de configurar la librería e instalarla. Una buena manera de empezar sería crear un directorio en nuestra aplicación web para guardar archivos JavaScript. Y, en dicha carpeta tendríamos que guardar en primer lugar la librería de JQuery que podemos encontrar en su web y, después guardaríamos en ese mismo directorio la librería que vamos a usar que también la podeis descargar de la misma web de VanadiumJS.

Es importante colocar estas dos librerías de JavaScript debido a que Vanadium como era de esperar hace uso de JQuery.

Posteriormente, también deberíamos crear una carpeta para guardar hojas de estilos css, aunque posiblemente ya la hayamos creado para guardar nuestras propias hojas de estilos. Dentro de esta carpeta deberemos colocar una hoja de estilos como esta. Los estilos de esta hoja son los que serán aplicados a los formularios en caso de validación correcta o validación fallida.

Es una hoja de estilos sencilla de personalizar puesto que los nombres que llevan cada uno de los estilos son bastante intuitivos.

Finalmente toca hacer funcionar esto dentro de nuestros ficheros html estáticos o jsp u otros lenguajes. Esto será tan sencillo como importar todos estos archivos que hemos usado en la cabecera de cada fichero en la que lo queramos usar. Si esto nos resulta incómodo en el caso de jsp siempre podríamos hacer uso de la etiqueta import para no tener que poner estas líneas en todos los ficheros en los que se use.


	
	Login

Validación en formularios

En este apartado aprenderemos a llamar a esta librería para que haga las validaciones pertinentes en cada campo del formulario.

Vanadium usa el atributo class de los elementos de los formularios para que en él se escriban los ajustes que sean necesarios. Veamos un ejemplo sencillo con el que se validaría un campo de texto en el que se espera un e-mail.

Se puede observar que hay un símbolo de dos puntos (:) al principio de cada ajuste. En este caso estaríamos indicando que se realizara una validación según la expresión regular de un email. Si hacemos la prueba de este código veremos que realiza la validación por cada evento que ocurre en la caja de texto, si no queremos este comportamiento se puede cambiar para que lo realice pasado un tiempo después de un evento o para que lo realice sólo cuando el campo se abandone (terminar de escribir y pasar al siguiente campo).

Otro aspecto importante es que en el ejemplo anterior se podría no escribir nada en la caja de texto y pasar la validación sin problemas, si se quiere que esto sea un campo requerido habría que usar otro ajuste. Veamos ahora un ejemplo más complejo.

NOTA: En los códigos hay un espacio sobrante entre los dos puntos (:) y la o de “only_on_blur” debido a que se cambiaba por su correspondiente emoticono.

También es posible la validación de otro tipo de campos a parte de el email que va vienen implementados por defecto con la librería. Podemos encontrar en la página web del proyecto una lista de las posibilidades admitidas. Todos los ajustes que necesiten de un valor se indicará con el punto y coma (;) y después el valor, como se ha visto para el caso de wait.

Veamos por ejemplo como validar un campo típico en el que se pide que repitas la contraseña, para comprobar que has escrito lo mismo en los dos lugares.

Contraseña



Reescriba la contraseña por seguridad

Personalizar los mensajes de error

Puesto que es una librería escrita en inglés es de suponer que los mensajes de error que se produzcan cuando falle la validación esten en inglés, pero no hay problema, lo podemos cambiar. Para ello deberemos abrir el fichero JavaScript de Vanadium que hemos guardado en la carpeta de scripts, y luego nos dirigiremos a la línea 1012 aproximadamente.

Podremos ver estructuras repetitivas que llevan la expresión regular con la que se ha de validar, un nombre y un mensaje de error. Mostremos una de ejemplo.

['asciialpha', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Please use ASCII letters only (a-z) in this field.'],

Ahora si lo que queremos es que el mensaje se muestre en español sería tan sencillo como traducir el mensaje.

['asciialpha', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Por favor, use solo caracteres ASCII (a-z) en este campo'],

Como podemos ver es una tarea bastante sencilla.

Personalizar los tipos de validaciones

En este apartado veremos que también es posible añadir otros tipos de validaciones aparte de las que ya vienen implementadas por defecto con la librería, por ejemplo sería interesante una validación para direcciones postales.

Para esto nos situaremos en la zona del fichero JavaScript de Vanadium, aproximadamente por la línea 1012 y solo tendremos que repetir la estructura que ya hemos comentado en el apartado anterior pero personalizándola según nuestras necesidades. Mostraremos un ejemplo para validar una dirección de email; como se puede ver bastará con adaptar una expresión regular y personalizar nuestro mensaje.

['dir', function (v) {
	return Vanadium.validators_types['empty'].test(v) || /^[a-zA-Z0-9 \,\º\-\u00C0-\u00FF\u0100-\u017E\u0391-\u03D6]+\ [0-9]{5}-[a-zA-Z \-\u00C0-\u00FF\u0100-\u017E\u0391-\u03D6]+$/.test(v)   //% C0 - FF (� - �); 100 - 17E (? - ?); 391 - 3D6 (? - ?)
}, 'Introduzca una dirección válida'],

Y posteriormente, en los formularios, bastará con usar el nombre que se le ha dado a la validación, en este caso ‘dir’.

También se pueden hacer cosas más complejas como se puede ver en líneas inferiores siguiendo la misma estructura.

Validación usando la lógica del servidor por medio de AJAX y JSON

En ocasiones no se pueden realizar todas las validaciones por medio del cliente, a veces se necesitan datos que solo se pueden obtener del servidor. El típico ejemplo de esto sería comprobar si una dirección de email ha sido ya usada anteriormente o no. Para este tipo de validaciones lo que se suele hacer es usar AJAX para realizar peticiones al servidor.

En el caso concreto de Vanadium nos va a permitir realizar una petición AJAX a la dirección que deseemos y el esperará un objeto JSON como respuesta a dicha petición que indique si la validación ha sido correcta o no.

Lo primero que haremos será preparar un Servlet Java EE preparado para recibir peticiones en un determinado patrón de url personalizando este ajuste en el descriptor de despliegue.


    CheckEmailServlet
    control.CheckEmailServlet


    CheckEmailServlet
    /checkmail

Posteriormente en la implementación del Servlet lo primero que haremos es definir el tipo de respuesta como un objeto JSON y posteriormente abriremos el flujo de salida en el que escribiremos el JSON que espera Vanadium, que será como este que podemos observar en la web del proyecto. Como vemos primero se indica si la validación fue válida y posteriormente un mensaje para mostrar en caso de error en la validación.

{
  success: true,
  message: "The username is free."
}

mostremos ahora el código de un servlet sencillo que siempre devolverá la misma respuesta. Por supuesto hay que tener en cuenta que las escrituras en el flujo de salida deberían de ir en un try y realizar el cierre de la misma en un bloque finally. Como se puede observar simplemente se va construyendo el objeto JSON en el flujo de salida. Este Servlet en realidad no hace nada pero sería tan sencillo como devolver una u otra respuesta dependiendo de ciertas condiciones; que en nuestro ejemplo concreto sería comprobar si una dirección de email está usada o no.

response.setContentType("application/x-json;charset=UTF-8");
PrintWriter out = response.getWriter();
out.println ("{");
out.println("\"success\": false,");
out.println("\"message\": \"Dirección de email no disponible\"");
out.println("}");
out.close();

Ahora habrá que configurar el campo del formulario que se desea validar al estilo de como se ha hecho en los ejemplos anteriores. Habrá que usar la opción ajax y después del punto y coma (;) habrá que indicar la dirección a la que se quiere realizar la petición. Veamos el ejemplo concreto.

Como vemos la directiva es bastante sencilla, simplemente se indica que se quiere hacer una validación vía AJAX y la dirección a la que se quiere hacer la petición, y como vemos es perfectamente combinable con cualquiera de las opciones ya vistas en apartados anteriores.

Pues hasta aquí con este tutorial sobre el uso de la librería Vanadium para realizar validaciones de formularios en el lado del cliente usando JavaScript y JQuery. Comentar también que en la misma página de Vanadium es posible encontrar más ejemplos.

Espero que os haya sido útil este tutorial y mi parte nada más que decir; solamente deciros como siempre que están los comentarios a vuestra entera disposición para cualquier duda o sugerencia.

Tienda Online Java EE: Solucionada validación ajax en formulario de registro

Juan — Fri, 13 Jan 2012 20:46:11 +0000

Para todos aquellos que no lo sepan, en este blog fue publicado hace tiempo un ejemplo de Java EE, una tienda online, pues bien, hoy vamos a comentar una pequeña actualización.

Seguramente los que ya han usado el ejemplo y visto la documentación se habrán dado cuenta que la validación del lado del servidor usando ajax y JSON para comprobar en el registro que el email no estuviera en uso no funcionaba, como bien deje notificado.

Pues bien, después de tiempo intentando diversas cosas y mirando documentación del autor, ahora después de los examenes de enero he dado con el problema y lo he solucionado, la solución ha sido debidamente actualizada en el control de versiones y está disponible al público.

Más adelante explicaré detalladamente el tema de las validaciones con JavaScript en el cliente para que todos sepamos como han sido implementadas.

También, como sabéis el artículo fue publicado tambien en Javahispano, comentar que para mi asombro, el artículo ha salido entre los 10 más populares de 2011.

Espero que os haya gustado la notica, personalmente estoy contento porque es un tema que me ha traído bastante de cabeza.

Java EE: Seguridad en aplicaciones web (II). Evitando Inyección SQL y XSS con ESAPI

Juan — Tue, 13 Dec 2011 18:04:56 +0000

Después de un tiempo un poco más atareado por fin encuentro un hueco para cumplir mi promesa, vamos a continuar la guía de seguridad en aplicaciones web que se inició hace un tiempo. En esta nueva entrada se cubrirán en detalle los aspectos que quedaron por cubrir en la primera entrega: Inyección SQL y Cross Site Scripting (XSS). Aprenderemos a usar la librería ESAPI para evitar estos problemas de seguridad.

Inyección SQL

Comenzaremos hablando por el primero de los riesgos de seguridad que se comentaban en la entrada anterior. Para hacer un breve recordatorio veíamos que se trataba de intentar comprometer de alguna manera la base de datos de la aplicación.

Para ello, se suelen usar los formularios de las páginas web tratando de cerrar en ellos una consulta SQL e iniciando otra a continuación; dicho esto enviar directamente los datos de los formularios hacia una consulta SQL no es una buena práctica. Veremos en este apartado una serie de buenas prácticas que deberíamos llevar a cabo para evitar la inyección SQL.

Uso de PreparedStatements

En primer lugar una muy buena práctica es cambiar el uso de los Statements por los PreparedStatements. Este tipo de Statement obliga a que la consulta tenga exactamente la estructura que se indica, y no deja que se cambie la estructura de la misma o se cierre una consulta y se abra otra nueva. También lleva a cabo un escapado de caracteres, puesto que podrías poner de nombre “O’Donnell” y no habría problema alguno en poner la comilla simple. Ni que decir tiene que también podríamos evitar la inyección SQL usando procedimientos almacenados.

Para hacer una consulta con un PreparedStatement lo primero que se hace es indicar la estructura de la consulta dejando los parámetros marcados con una interrogación “?” y posteriormente se irá indicando que son cada una de esas interrogaciones y su tipo de dato. Y gracias a que se indica el tipo de dato, Java ya se encarga de poner las comillas que hagan falta dependiendo del tipo de dato. Veremos que hay muchos métodos set dependiendo del tipo de dato a introducir.

Veamos un ejemplo. En el ejemplo se muestra un método sencillo para hacer un insert en la base de datos . He puesto el método completo para que también se observe una buena estructura para un método de este tipo. Siguiendo esta estructura es la mejor manera de asegurarse de que todos los recursos van a ser liberados en cualquier caso, tanto si se produce un error como si la ejecución es normal. Voy a explicar al final de esta entrada en que consiste ese método cerrarConexionYStatement (), ya que considero que es un punto importante a tener en cuenta para ahorrarnos unas cuantas líneas de código.

public boolean addUser(Usuario user) {
    Connection conexion = null;
    boolean exito = false;
    PreparedStatement insert = null;
    try {
        conexion = pool.getConnection();
		//Definir la estructura de la consulta
        insert = conexion.prepareStatement("INSERT INTO " + nameBD + ".Usuarios VALUES (?,?,?,?,?)");
		//Indicamos cada uno de los parámetros
        insert.setString(1, user.getMail());
        insert.setString(2, user.getNombre());
        insert.setString(3, user.getDir());
        insert.setString(4, user.getPass());
		//Incluso si no encontramos un método set para incluir un tipo de dato se puede personalizar como en este caso
        insert.setObject(5, user.getPermisos(), java.sql.Types.CHAR, 1);

        int filasAfectadas = insert.executeUpdate();
        if (filasAfectadas == 1) {
            exito = true;
        }
    } catch (SQLException ex) {
        logger.log(Level.SEVERE, "Error insertando usuario", ex);
    } finally {
        cerrarConexionYStatement(conexion, insert);
    }
    return exito;
}

En el código de la tienda online podemos encontrar numerosos métodos de este estilo y se pueden ver ejemplos en los que se use un ResultSet e incluso algún ejemplo en el que se realizan varias transacciones dependientes entre si y se realizan rollbacks y commits manualmente.

Hay que comentar que aunque no se vea siempre se realizan commits en todos los métodos, solo que por el hecho de ser consultas simples la conexión realiza los commit de manera automática, pero esto se puede cambiar como se puede ver en el código de la tienda online.

conexion.setAutoCommit(false);

Realizar validaciones con expresiones regulares

¿Esto es todo lo que podemos hacer? Pues no, podemos usar como medida de apoyo una validación de todos los datos de entrada de los usuarios en los formularios. Para realizar esta validación usaremos la librería que nos proporciona OWASP que se hace denominar ESAPI.

Y ahora como es lógico veremos como usar esta librería y configurarla. En primer lugar hemos de bajar el paquete que nos proporcionan en el que se incluye en jar de ESAPI y todas las librerías que requiere ESAPI para funcionar (carpeta libs del paquete descargado). Hemos de añadir todas esas librerías a nuestro proyecto.

Una cosa importante. Entre las librerías requeridas es posible que se incluya la librería de servlets. Esa librería no la debéis de incluir en el proyecto puesto que es una versión más antigua de los Servlets y cambian métodos como por ejemplo la forma de acceder al contexto de la aplicación, por lo que nos interesa conservar la especificación de Servlets moderna que tenga nuestro servidor de aplicaciones.

La siguiente parte importante son los ficheros de configuración que necesita ESAPI para funcionar: ESAPI.properties y validation.properties. Podemos encontrar una plantilla de cada uno de los ficheros en el paquete descargado en configuration/.esapi.

La siguiente tarea es colocar los ficheros de configuración en un lugar adecuado para que se reconozcan. ESAPI buscará los ficheros en varios lugares en el orden en el que indico a continuación. Encontraremos esta información en la página de ESAPI o de la manera que lo he hecho yo que es mirando la consola del servidor de aplicaciones

INFO: Not found in 'org.owasp.esapi.resources' directory or file not readable: /Applications/NetBeans/glassfish-3.1/glassfish/domains/domain1/ESAPI.properties
INFO: Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
INFO: Not found in 'user.home' (/Users/Usuario) directory: /Users/Usuario/esapi/ESAPI.properties
INFO: Attempting to load ESAPI.properties via the classpath.

En mi caso me pareció lo más cómodo incluirlo en el classpath. Para ello cree en la raiz del proyecto una carpeta llamada setup, que por otra parte es estándar que los proyectos web puedan tener esta carpeta para archivos de configuraciones, y posteriormente se ha de añadir dicha carpeta al classpath del proyecto.

Una vez que hemos colocado los archivos en su lugar comenzaremos configurando cada uno de ellos. Lo que se va a configurar en estos ficheros principalmente serán las expresiones regulares que se van a usar para validar cada uno de los campos que deseemos.

El primer fichero que hemos nombrado, ESAPI.properties es un fichero que en lo que a nosotros nos concierne no hemos de tocar nada, la librería se sirve de él para hacer sus operaciones; nuestras personalizaciones irán en el segundo fichero nombrado. Pero no está de más echar un ojo al fichero para ver las validaciones que ya incluye y se verá que incluye validación para Email y alguna otra cosa más. Mirándolo también veremos cual es la forma de las expresiones regulares que admite.

Ahora pasemos al segundo fichero en el que hemos de configurar las expresiones regulares que consideremos necesarias. Para ello hemos de poner una clave y una atributo; al estilo de un fichero de propiedades. La clave será siempre Validator.Campo, siendo Campo lo que usaremos posteriormente para referirnos a esa expresión regular.

Esto no pretende ser un tutorial sobre como crear expresiones regulares, sin embargo haré algunas anotaciones. Si alguien necesita más ayuda con el tema puede preguntar y no tendré problema alguno en resolver sus dudas.

El símbolo “^” indica el inicio de la cadena, mientras que el símbolo “$” indica el final de la cadena. Es bueno escapar caracteres como el guión y el punto puesto que el guión se usa para indicar un rango y el punto significa cualquier cosa. Otra anotación importante es que a la hora de poner caracteres regionales debéis ponerlos con su correspondiente código en UTF-16; si no se hace de esta manera después puede que no funcione correctamente. Se puede encontrar una tabla de correspondencia básica en la wikipedia. Por ejemplo, si se quiere poner una ‘a’ acentuada “á” se debe poner así \u00e1.

Si tenéis problemas con las expresiones regulares hay una web que podéis usar que puede resultar interesante. También se puede usar un software específico para expresiones regulares que nos puede ayudar a crearlas en unos sencillos pasos y también nos ayudará a crearlas. Su nombre es RegexBuddy y RegexMagic. El primero de ellos es sobretodo para aprender y verificar expresiones regulares mientras que el segundo está orientado a su creación.

Veamos ahora un pequeño ejemplo que son las que usé yo para la tienda online. Decir que no hace falta crear expresiones regulares para números porque tiene su verificación a parte que ya veremos.

Validator.Pss=^[A-Za-z0-9._$%&/()= -#@áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.Name=^[A-Z][a-zA-Z -áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.Adress=^[A-Z][a-zA-Z0-9\-\ \,ºáÁéÉíÍóÓúÚüÜñÑ]+\ [0-9]{5}\-[A-Z][A-Za-z\ \-áÁéÉíÍóÓúÚüÜñÑ]+$
Validator.NameDescProd=^[A-Za-z0-9.,-_ @#%&=áÁéÉíÍóÓúÚüÜñÑ¿?¡!]+$

Una vez que estos ficheros han quedado correctamente configurados pasaremos ha explicar como han de usarse dentro de nuestra aplicación.

Veamos por ejemplo un método para validar un nombre usando la expresión regular que hicimos para validar un nombre. He dejado comentados cada uno de los argumentos necesarios y también se encuentra disponible el javadoc en la página de los repositorios del proyecto o en el paquete descargado; por ejemplo puede existir un argumento más para que la cadena de caracteres se pase a forma canónica antes de ser validada.

public static String validateName(String input) throws IntrusionException, ValidationException {
    Validator validador = ESAPI.validator();
	//Nombre a referirse, entrada, nombre de la expresión regular, máxima longitud, permitir nulo o no
    return validador.getValidInput("Nombre", input, "Name", 100, false);
}

El método devuelve la cadena validada y en caso de error hay dos tipos de excepciones, ValidationException es lanzada cuando simplemente no se ha pasado la validación, mientras que IntrusionException se lanza cuando se cree de manera muy clara que ha ocurrido un intento de ataque.

El primer argumento es un nombre para nuestro uso personal que posteriormente lo usará si hay un error para indicar donde ha ocurrido. Y el nombre de la expresión regular ha de ser el mismo que dimos en el fichero de propiedades, de esta manera se elige con que expresión regular se desea validar una entrada.

Como dije no hace falta crear expresiones regulares para los números puesto que usan validaciones a parte. Veamos un ejemplo.

public static int validateNumber(String input) throws IntrusionException, ValidationException {
    Validator validador = ESAPI.validator();
	//Nombe para referirse, entrada, mínimo, máximo, permitir nulo o no
    return validador.getValidInteger("Entero", input, 0, 999999, false);
}

Como se puede ver en el ejemplo validar un número es tremendamente sencillo sin tener siquiera la necesidad de especificar una expresión regular para la validación de los mismos.

Ahora veremos un ejemplo de como usar estas validaciones dentro de nuestra aplicación.

try {
	String name = Tools.validateName(request.getParameter("name"));
} catch (IntrusionException ex) {
	request.setAttribute("resultados", "Detectada una intrusión");
	Tools.anadirMensaje(request, ex.getUserMessage());
} catch (ValidationException ex) {
	request.setAttribute("resultados", "Error en el formulario");
	Tools.anadirMensaje(request, ex.getUserMessage());
}

Escapar las entradas de usuario

ESAPI también nos permitirá escapar las entradas del usuario para introducirlas en la base de datos; pero la verdad es que usando PreparedStatements este paso no sería necesario, y en caso de querer hacerlo habría que hacerlo después de pasar la validación por expresiones regulares puesto que al escapar una cadena se van a incluir nuevos caracteres como la contrabarra “\”. Veamos a continuación un ejemplo sencillo para escapar las entradas preparado especialmente para MySQL (ESAPI proporciona métodos de escape para MySQL y para Oracle si no recuerdo mal).

protected String scapeUserEntries (String input){
	Encoder encod = ESAPI.encoder();
	return encod.encodeForSQL(new MySQLCodec(MySQLCodec.MYSQL_MODE), input);
}

Recomiendo que partiendo de los ejemplos y explicaciones que se han dejado aquí se eche un vistazo al javadoc de ESAPI puesto que contiene opciones bastante interesantes. Entre ellas tiene una forma de hacer validaciones seguidas poniendo los errores en una lista para hacer todo el conjunto de validaciones seguidas sin detenerse por el fallo de alguna de ellas.

Cross Site Scripting (XSS)

Ahora que hemos visto como evitar las inyecciones SQL veremos ahora las formas de evitar Cross Site Scripting, que a modo de resumen a lo que se comentó en el capítulo anterior se podría decir que el fin que se persigue con este tipo de ataques es introducir alguna información en la base de datos para que posteriormente sea mostrada a otros usuarios. La información que se suele introducir serán scripts que persiguen realizar alguna actividad ilegítima.

De la misma manera que en el apartado anterior se validaban las entradas de los usuarios para evitar la inyección SQL realizando esa validación es evidente que se puede evitar también el XSS.

Aunque el problema puede venir de un caso en el que no queramos usar una expresión regular para validar, por ejemplo un campo de comentarios para el usuario en el que se permite cualquier caracter. En este caso lo que habrá que hacer es buscar etiquetas html sospechosas como script, pero… ¿realmente vale con buscar este tipo de etiquetas? Pues la respuesta es que no, porque si se usa otra codificación ya no van a aparecer así las etiquetas. A continuación veremos una buena forma de validar las entradas para evitar el XSS.

El problema de las codificaciones

Lo primero veamos el problema de las codificaciones. En el siguiente ejemplo ambas líneas son equivalentes.


%3C%2Ftitle%3E%3Cscript%3Ealert%28%22%A1Este+Sitio+es+un+peligro%21%22%29%3C%2Fscript%3E

Ahora si vemos que no se puede proteger simplemente buscando etiquetas html ¿no?. Por lo tanto lo primero que habrá que hacer es pasar la cadena a una forma canónica.

Obtener la forma canónica de una cadena consiste en convertir toda la cadena a una codificación conocida y admitida para que de esta manera se eviten problemas en la posterior validación.

Usando AntiSamy para validar entradas en HTML

ESAPI también nos proporciona soluciones para todos los problemas comentados mediante un módulo llamado AntiSamy. Este se encarga de procesar código html y verificar si está permitido o por el contrario es un posible intento de intrusión, para ello usa un fichero xml de configuración en el que se especificarán con detalle las etiquetas html permitidas y no permitidas; también será posible especificar que tipo de propiedades de CSS se pueden usar.

El archivo xml de configuración de AntiSamy se puede colocar donde nosotros queramos, aunque, obviamente no sería una buena medida colocarlo en un directorio que sea accesible publicamente. En mi caso lo he colocado en el mismo sitio que los archivos de configuración de ESAPI, que si recordamos estaban en la carpeta setup que habíamos añadido al classpath.

En la página del proyecto de AntiSamy es posible encontrar varios archivos de configuración de ejemplo, de más a menos restrictivos. Lo mejor es partir de alguno de estos archivos y en caso de querer modificarlos hacerlo observando las directivas que ya contiene puesto que no es una tarea sencilla hacer un archivo de estos desde cero, por ello nos proporcionan varios ejemplos. También hay un ejemplo en su página de descargas muy interesante pensado para enviar datos al servidor que provienen de un TextArea con TinyMCE (Librería JQuery para dotar a un TextArea de un editor con WYSIWYG).

Ahora que hemos visto lo referente al fichero de configuración ya estamos en disposición de poner un ejemplo de un método que valida una entrada HTML. Este método que muestro a continuación valida una entrada que se le pasa como argumento y lanza una IntrusionException si la validación no ha pasado, dicha excepción la he lanzado yo para detectar los errores puesto que la librería no lanza excepciones ante una validación fallida, sino que anota los errores que han ocurrido y también tiene la posibilidad de eliminar aquello que no es válido según la configuración que hayamos hecho en el fichero xml.

Es importante ver también que como anoto en los comentarios antes de pasar la validación se obtiene la forma canónica del String usando un método que nos proporciona ESAPI. Y finalmente observar como se ha indicado donde esta el fichero xml de configuración, que se ha realizado usando el classpath y obteniendo su flujo de entrada.

public static void validateHTML(String input) {
    try {
		//No se admite una entrada vacía
        if (input.isEmpty() == true) {
            throw new IntrusionException("No se admite el campo vacío", "");
        }
		//Se obtiene el archivo de configuración a través del classpath
        Policy politica = Policy.getInstance(Tools.class.getResource("/antisamy-tinymce-1.4.4.xml"));
        AntiSamy validator = new AntiSamy();
		//Antes de analizar la cadena es convertida en su forma canónica
		//ESAPI.encoder().canonicalize(input)
        CleanResults cr = validator.scan(ESAPI.encoder().canonicalize(input), politica);

		//Si ha ocurrido un error se lanza una excepción indicando el error
        if (cr.getNumberOfErrors() != 0) {
            throw new IntrusionException("Ha introducido código HTML que no está permitido",
                    cr.getErrorMessages().get(0).toString());
        }
    } catch (PolicyException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
    } catch (ScanException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
    }
}

Anexo – Cerrar Conexiones, Statements y ResultSets. Varargs en java

En este apartado vamos a ver una buena manera de hacer esos métodos que decíamos para cerrar las conexiones y Statments. Aquí el problema viene de hacer un método que nos sirva para todos los métodos de la clase manejadora de la base de datos. No van a tener todos los métodos un Statement o un ResultSet, pueden tener varios de cada uno.

Se puede pensar en hacer métodos que reciban listas de Statements, pero estaríamos a lo mejor escribiendo líneas construyendo esas listas en cada método, líneas que se supone intentamos ahorrarnos. Pues bien java tiene algo llamado varargs para facilitarnos esta tarea, aunque internamente este construyendo listas el caso es que no tenemos que construirlas nosotros.

Lo único que hemos de hacer es colocar en la cabecera de los métodos de cierre unos puntos suspensivos detrás del tipo de dato. El argumento que vaya con varargs debe ser el último y debe haber solo uno (esto es debido a que sino java no tiene forma de saber los tipos de datos de los argumentos). Posteriormente dentro del método podemos recorrer los elementos con un bucle for-each, como si de un lista normal se tratara (que es de hecho lo que hace internamente como ya he dicho).

private void cerrarConexionYStatement(Connection conexion, Statement... statements) {
    try {
        conexion.close();
    } catch (SQLException ex) {
        logger.log(Level.SEVERE, "Error al cerrar una conexión a la base de datos", ex);
    } finally {
        for (Statement statement : statements) {
            if (statement != null) {
                try {
                    statement.close();
                } catch (SQLException ex) {
                    logger.log(Level.SEVERE, "Error al cerrar un statement", ex);
                }
            }
        }
    }
}

private void cerrarResultSet(ResultSet... results) {
    for (ResultSet rs : results) {
        if (rs != null) {
            try {
                rs.close();
            } catch (SQLException ex) {
                logger.log(Level.SEVERE, "Error al cerrar un resultset", ex);
            }
        }
    }
}

Estos métodos podrían admitir toda una serie de llamadas no dependiendo del número de Statement o ResultSet.

cerrarConexionYStatement(conexion, select);
cerrarConexionYStatement(conexion, deleteHistorialCarros, deleteProdCarro);

cerrarResultSet(rs);
cerrarResultSet(consultaDatosCarro, rs);

Como podemos suponer nos hemos ahorrado bastantes líneas en cada uno de los métodos, ahora como máximo habrá dos líneas en cada método para cerrar los recursos independientemente del número de recursos que haya.

Bueno, y hasta aquí esta guía de seguridad para aplicaciones web junto con el uso de ESAPI que como vemos llega a ser muy útil para las tareas de seguridad en nuestra aplicación.

También comentar que puede venir bien la lectura de los consejos que nos da OWASP para los dos problemas que hemos tratado en esta entrada (en inglés): Inyección SQL y Cross Site Scripting (XSS).

Comentar que todo lo que hemos aprendido en estos dos capítulos se refiera a la lógica de servidor como es evidente, esta lógica siempre debe existir, pero debo comentar que si se realizan validaciones en el cliente por ejemplo usando JavaScript se puede quitar un poco de carga al servidor, ya que ante una validación fallida esa petición no llegará al servidor.

Espero que os hayan sido útiles estas guías de seguridad, y como siempre digo a vuestra disposición quedo para cualquier duda problema o sugerencia.

Tutorial ANT: Uso con librerías externas y generadores JFlex y CUP

Juan — Mon, 28 Nov 2011 10:35:36 +0000

He dedicado tiempo ultimamente a aprender al menos de manera básica el uso ANT, que para los que no lo sepan es una herramienta para compilación de proyectos JAVA al estilo del make para C. Justo me proponen en la universidad que realice una presentación en clase sobre ello; no me ha podido venir más bien después de haber estado yo haciendo algunos ejemplos. Así que me dispuse a ordenar mis investigaciones para crear un ejemplo sencillo que aunara lo que considero más importante, y sobre ese ejemplo realizar una presentación que me ayudara a explicarlo en clase de la manera más ordenada posible.

Bueno, y ya que he hecho la presentación y el ejemplo pues me animo también a presentar aquí el tutorial

¿Qué es ANT?

Como ya he comentado ANT es una herramienta para compilación de proyectos JAVA, y como tal escrita en el mismo. Se podría decir que es una herramienta como make para programas en C solo que especialmente diseñada pensando en JAVA; nos proporciona los medios para la realización de las tareas que componen el proceso de compilación, documentación, distribución, etc de un proyecto JAVA.

Es muy útil para los casos en los que se trabaja con distintos entornos de desarrollo para disponer de una manera estándar y fácil de compilar el proyecto, y sobretodo en proyectos complejos con muchas librerías o en proyectos web en los que las tareas de compilación comprenden más pasos. Además la mayoría de los entornos de desarrollo disponen de opciones para la ejecución de scripts de ANT.

Por último comentar que actualmente no es ant la herramienta más usada para esto, sino que se está usando cada vez más una herramienta similar llamada Maven, la cual tiene algunas ventajas sobre el que ahora nos ocupa.

Instalación de ANT

La instalación de ANT es bien sencilla, básicamente consiste en situar los archivos de ant en las variables de entorno del sistema. Podemos conseguir los archivos de instalación en la web del proyecto. Pese a ser una obviedad comentaré que se necesita tener instalado el JDK (Java Developer Kit) puesto que ant está escrito en Java.

Mac OS

Yo no he tenido que hacer nada para instalarlo, o viene por defecto o se instaló con el Xcode de Mac OS.

Linux

Si suponemos que hemos situado los archivos ANT en /usr/local/ant

export ANT_HOME=/usr/local/ant
export JAVA_HOME=/usr/local/jdk-1.5.0.05
export PATH=${PATH}:${ANT_HOME}/bin

Windows

Si suponemos que hemos situado los archivos de ANT en C:\ant\

set ANT_HOME=c:\ant
set JAVA_HOME=c:\jdk-1.5.0.05
set PATH=%PATH%;%ANT_HOME%\bin

Si hemos instalado ant correctamente podremos teclear el comando para ver su versión en la consola y nos deberá reconocer el comando.

Para ejecutar ant sobre un fichero build.xml nos situaremos en el directorio donde este el fichero y teclearemos ant para ejecutar el objetivo por defecto o ant y un objetivo en concreto para ejecutar ese objetivo concreto (se ejecutarán también sus dependencias obviamente)

#Obtener la versión instalada de ant
$ant -version

#Ejecutar un script de ant con el objetivo por defecto
$ant

#Ejecutar un script de ant con el objetivo que elijamos
$ant objetivo

Algunas definiciones

Vamos a ver en este apartado algunos conceptos que hemos de conocer para trabajar con ANT.

Mientras que en el famoso make de C teníamos un fichero llamado makefile, en este caso tendremos un fichero xml llamado build.xml en el que estarán escritos los pasos que se han de seguir para la compilación de nuestro proyecto. Pasemos ahora a definir los elementos de dicho fichero (o etiquetas puesto que es un fichero XML).

project: Es el elemento raíz del fichero XML y como tal solo puede haber uno en el fichero. Es el propio proyecto con el que estamos trabajando
target: Elemento que agrupa un conjunto de tareas que se desean realizar en un momento determinado. Como veremos puede haber unos objetivos dependientes de otros
task: Es el código ejecutable que será aplicado a la aplicación en algún momento, puede contener distintas propiedades.
property: Parámetros en forma de par clave-valor (los nombres serán case-sensitive) para personalizar el proceso de construcción o simplemente como accesos directos a un dato que se use de manera repetitiva en el fichero xml.

Continuemos ahora viendo una estructura de directorios para un proyecto Java.
En primer lugar tenemos el directorio classes en donde se almacenarán las clases Java compiladas.

Dentro del directorio dist se encontrará la aplicación empaquetada en forma de jar autoejecutable, también se podía incluir aquí la documentación para su distribución aunque he optado por ponerla en la raíz del proyecto.

En el directorio doc estará la documentación del proyecto en formato javadoc.

En el interior del directorio lib estarán almacenadas las bibliotecas externas que hayamos usado en nuestro proyecto.

Por último el directorio src en el que estará el código fuente de la aplicación organizado en los paquetes que hayamos decidido nosotros mismos.

Nuestro primer build.xml

Vamos a ver aquí nuestro primer ejemplo y sobre él explicaremos las partes básicas a parte de las etiquetas ya explicadas.

Lo primero que nos encontramos es que la raiz del fichero tiene dos atributos que no hemos explicado anteriormente. El primero de ellos es default, este especifica cual es el objetivo que se ejecutará por defecto al ejecutar este script de ant salvo que se especifique uno concreto. El atributo basedir indica donde están situados los directorios del proyecto. En este caso como tendremos el fichero buid.xml al mismo nivel que los directorios del proyecto hemos puesto un punto.

Lo siguiente que nos encontraremos serán las propiedades que como dije son pares clave valor. En este caso yo las he usado para tener un acceso más rápido a los distintos directorios y menos problemas si alguno de ellos fuera cambiado. Accederemos a ellas posteriormente así ${propiedad}

Finalmente nos encontramos con un objetivo sencillo que realiza la compilación con la tarea javac, tiene como atributos srcdir que indica donde está el código fuente a compilar y destdir indica en que directorio se han de dejar las clases compiladas.

Los objetivos pueden tener dependencias, las cuales se indican con el atributo depends. Las dependencias entre objetivos indican que un objetivo que depende de otro no será ejecutado sin que se haya ejecutado previamente ese otro del que depende. Veamos un ejemplo sencillo

Empaquetado del proyecto

En este apartado veremos como crear un objetivo que se encargue de empaquetar las clases compiladas en un único jar autoejecutable.

Un archivo jar es como un archivo zip, incluso con la misma compresión; y en su interior contiene las clases java organizadas en paquetes y una carpeta más llamada META-INF, esa carpeta es la usada para meter en su interior meta-información sobre el archivo jar.

Dentro de la carpeta nombrada se suele encontrar un fichero llamado manifest.mf, el cual tiene en su interior un conjunto de pares clave valor que pueden ser necesarios. En nuestro ejemplo lo que indicaremos en el fichero será cual es la clase main (Main-Class) de nuestro proyecto para que se sepa por donde tiene que empezar la ejecución. Sin esto no podríamos ejecutar el archivo jar, al menos con el típico doble click, habría que hacerlo pasando por la consola y llamando directamente a la clase Main.

Como hemos visto, la tarea jar contiene dos atributos, el primero de ellos llamado destfile que indicará la ruta donde queremos el fichero jar generado, el atributo basedir indica donde se encuentran las clases compiladas a incluir y finalmente el atributo includes que me indicará que tipo de ficheros se incluyen dentro del fichero jar creado.

Como se puede ver, un nivel por debajo de la tarea jar nos encontramos con la etiqueta manifest, la cual, como podemos suponer, sirve para incluir conjuntos de pares clave valor dentro del fichero que comenté anteriormente. Como se observa se indica la ruta a la clase main tal y como hemos comentado.

Generación de documentación

En este apartado veremos como crear un objetivo que cree documentación javadoc sobre nuestro proyecto. Vamos a poner aquí un pequeño ejemplo y lo explicaremos posteriormente.

Como vemos la tarea que se encarga de generar la documentación javadoc del proyecto tiene bastantes atributos, los primeros de ellos son los más importantes de todos. El primero de ellos, packagenames, indica los paquetes sobre los que se desea generar la documentación, esta vez hemos puesto asterisco para generar la documentación de todos ellos, sourcepath es el directorio donde se encuentran los archivos fuente del proyecto, destdir indica el directorio donde se van a guardar los archivos generados en el proceso de documentación (el resultado final).

Los demás atributos que observamos son de menos importancia que los anteriores ya que se refieren más a la personalización de esa documentación a generar, por ejemplo tomar en cuenta etiquetas @author o @version, el título y el pie de página del documento, etc…

Limpieza e Inicialización

Entre las muchas tareas predefinidas con las que cuenta ant podemos encontrar tareas para crear y borrar carpetas (y archivos).

Puede ser que queramos borrar las clases compiladas antes de una nueva compilación para que no haya problemas, y obviamente también habrá que crear las carpetas después de borrarlas.

Veamos aquí dos ejemplos de objetivos de ejemplo para crear y borrar carpetas. En este ejemplo haremos que se borre el paquete jar autoejecutable, las clases compiladas y la documentación generada; parece lo más lógico hacerlo así para evitar problemas si hay cambios grandes en la estructura de clases y paquetes.

Como podemos ver la tarea delete tiene como función borrar directorios y con los atributos se indica que es lo que se quiere borrar. Y, con la tarea mkdir se hace lo contrario, crear directorios.

Como podeis ver el objetivo init depende del objetivo limpiar. Lo que quiere decir que llamar al objetivo init impicará borrar todo lo anterior y dejar las carpetas listas para la compilación, empaquetado y generación de documentación.

Utilización con librerías externas

En este apartado veremos como trabajar con librerías externas y veremos como hacer las tareas que ya hemos realizado pero usando librerías externas.

Es posible hacer referencia a una carpeta con librerías de varias formas, pero si se quiere usar esa referencia en varios lugares del fichero build.xml la mejor forma es hacer uso del elemento path, dentro del cual se selecciona la carpeta con las librerías, pudiéndose también hacer uso de filtros para seleccionar solo determinados ficheros.

Posteriormente habrá que usar ese elemento para incluirlo en el classpath durante la compilación y la generación de la documentación

Y en lo que respecta a la tarea del empaquetado de las clases compiladas hay que tener en cuenta dos cosas, en primer lugar para incluir un fichero jar de librerías en el paquete autoejecutable jar generado lo que se realiza es una descompresión del jar de las librerías para incluirlo en el jar final. Como resultado de este proceso obtendríamos la carpeta META-INF del paquete de las librerías, que de no ser excluido sobreescribiría la carpeta META-INF junto con el manifiesto creado, por lo que se perdería la meta-información que añadíamos a nuestro fichero jar final, y si esta información se perdiese la máquina virtual de JAVA no sabría cual es la clase Main para ejecutar el paquete.

Por lo tanto, para realizar estas tareas usaremos el elemento zipfileset indicando el fichero comprimido a incluir junto con un filtro para excluir la carpeta META-INF como ya hemos dicho.

Ejecución

En este apartado veremos como ejecutar el proyecto tanto desde una clase java como desde el proyecto empaquetado en un jar.

Ejecución desde clase Java

La tarea que nos ayudará a la ejecución es java, y usaremos el atributo classname para indicar la clase a ejecutar, para que pueda encontrar dicha clase tendremos que definir el atributo classpath con la ruta donde esta el paquete y la clase que hemos dicho que tenga que ejecutar.

Para poner los argumentos tendremos que usar arg y el argumento se pondrá en el atributo value. También hay que tener en cuenta que habrá que indicar la ruta de las librerías referenciando al elemento path que creamos en el apartado anterior.

Ejecución desde un archivo jar

Para este caso seguiremos usando la tarea java pero en este caso con el atributo jar en el que indicaremos la ubicación del archivo jar a ejecutar. Recordemos que para que la máquina virtual de java (VM) sepa que clase tiene que ejecutar tendremos que haber definido bien las propiedades en el manifiesto como ya explicamos anteriormente.

Es obligatorio el uso del atributo fork puesto que para ejecutar este jar la VM creará una nueva instancia. Como opción podemos usar el atributo maxmemory para indicar la máxima memoria que se reservará para la nueva instancia de la VM.

El resto será igual que en el caso anterior indicando los argumentos y añadiendo al classpath el elemento path que se definió anteriormente.

Usando ANT con JFlex y CUP

Como consecuencia de haber preparado la presentación para una asignatura sobre procesamiento de lenguajes vamos a tener un apartado extra en este tutorial. Este añadido tratará sobre como automatizar la utilización de Jflex (Generador de analizadores léxicos) y CUP (Generador de analizadores sintácticos).

Pues bien, lo primero que tendremos que hacer es decargar las librerías de JFlex y CUP para situar sendos Jar en la carpeta de librerías.

Conviene saber que ambos generadores contienen en el interior de sus librerías una tarea de ant, por lo que nuestro trabajo consistirá únicamente en usar dichas tareas.

Como vemos usamos el elemento taskdef y como atributos señalamos la carpeta de librerías que ya habíamos definido anteriormente en el apartado donde veíamos como usar librerías externas, posteriormente indicamos la clase en la que se encuentra esa tarea de ant y finalmente se indica el nombre bajo el que se usará esa tarea en el documento build.xml.

Mostramos ahora un objetivo encargado de la generación de los analizadores y posteriormente pasaremos a explicar cada uno de los atributos usados.

JFlex

En lo que se refiere a la tarea de jflex contamos con el atributo file en el cual se indica el fichero flex del que se partirá para la generación del analizador léxico, y finalmente destdir que indica el directorio en el que se generará el fichero java generado organizado en paquetes según se indique en el fichero flex.

CUP

En la tarea de CUP tenemos el atributo srcfile, equivalente al file de Jflex y destdir también equivalente al atributo del mismo nombre en Jflex. También se pueden usar otros atributos como interface para crear una interfaz java en vez de una clase. CUP también producirá su salida organizada en el paquete que se haya especificado en el fichero cup.

Recursos

Como parte de este tutorial dejaré aquí la presentación a modo de resumen y un proyecto de ANT como ejemplo.

En el proyecto de ejemplo se ha creado un objetivo de ant para explicar su uso, por lo que si queremos saber las opciones que tiene este fichero de configuración habrá que usar la siguiente orden en la consola situados en la carpeta del proyecto.

$ant usage

Hasta aquí este tutorial sobre ANT. Espero que os haya sido de utilidad, como siempre digo quedo abierto a todo tipo de sugerencias o adiciones; tenéis los comentarios a vuestra disposición.

Java EE: Seguridad en aplicaciones web (I)

Juan — Mon, 31 Oct 2011 23:03:37 +0000

Hace ya unos meses, publiqué una presentación que hice en la universidad sobre seguridad en las aplicaciones web, en concreto con Java EE. Ahora lo que me dispongo a hacer es repasar las partes más importantes de aquella charla en incluso aportar alguna cosa más sobre el tema después de haber estado trabajando con ello en la tienda online. Al ser un tema bastante amplio será distribuido entre varios artículos.

En esta serie de artículos aprenderemos a usar las herramientas que nos proporcionan las librerías de la empresa OWASP. También aprovecharemos para fijarnos en sus consejos ya que se dedican a estudiar entre otras cosas los problemas que yo voy a nombrar aquí.

Introducción – Principios de seguridad

Antes de nada vamos a dar una guía de buenas prácticas que es interesante conocer antes de empezar a construir aplicaciones para conseguir un trabajo lo más bueno posible.

No dar nunca nada por hecho ni en cuestiones de seguridad ni en cuestiones del flujo normal de la aplicación. Todo el riesgo que se corra debe ser por parte del usuario (no hay nada que hacer contra eso). Me explico, no supongamos que si le pido el nombre al usuario no me va a poner un número de teléfono. No se si sería una forma acertada de decirlo pero hay que pensar con pesimismo, en los peores casos, y por remotos que sean pueden ocurrir.

Siempre que usemos servicios externos estamos asumiendo riesgos añadidos. Podemos haber hecho una página web muy segura y muy bien construida, pero si incrustamos contenido externo nadie nos asegura que el contenido externo sea vulnerable a algún tipo de ataque.

La oscuridad no es seguridad. No poner un botón acceso a la administración no impide que se pueda acceder a ella. Ocultar nuestro código no debe ser parte de nuestra seguridad.

Principio del mínimo privilegio: El usuario del sistema debe tener únicamente los privilegios que necesita para llevar a cabo su actividad.

Fallar de manera segura: Hay que tratar de manera muy cuidadosa los fallos en la aplicación. Por poner un ejemplo, si se produce un fallo en la aplicación mientras se realizan tareas administrativas no debe seguir iniciada la sesión como administrador. Otro ejemplo, no debe mostrar en un fallo información técnica sobre el mismo al usuario del sistema. Si el usuario sabe datos acerca de nuestro sistema podría tener más fácil la búsqueda de vulnerabilidades.

Los riesgos

Ahora que hemos dado unos pequeños consejos sobre seguridad a la hora de la construcción de aplicaciones ya podemos pasar a explicar los riesgos que hay en las aplicaciones web. No vamos a ponernos a programar nada sin saber los riesgos existentes y el porque de las medidas que se toman para combatirlos.

Voy a nombrar aquí los riesgos que considero más importantes.

Inyección SQL: Consiste en intentar “engañar” al sistema para que realice peticiones contra la base de datos que no son las que han sido programadas y que podrían comprometer gravemente la base de datos o incluso mostrar al atacante toda la información de la misma.

Cross Site Scripting: El atacante intentará enviar información a nuestro servidor por medio de nuestros formularios u otros medios con la intención de que dicha información sea almacenada en nuestra base de datos y posteriormente sea mostrada a los demás usuarios del sistema. Un ejemplo sencillo: Un código JavaScript que borre el contenido de la página, si eso es mostrado a los demás usuarios de la aplicación verán siempre una página en blanco. Esto es un ejemplo sencillo, pero imaginarios que lo que se consigue introducir es un código que tome el control de los navegadores de los usuarios de la aplicación web.

Robo de sesión: Como sabemos HTTP es un protocolo sin estados, lo que significa que las credenciales o información de sesión deberá ir en cada petición; debido a esto dichos datos resultan muy expuestos. Un robo de estos datos podría tener como resultado que alguien se estuviera haciendo pasar por nosotros y realizando acciones con unos privilegios que nos pertenecen. Y tampoco hemos de olvidar que se pude robar la sesión intentando obtener nuestros credenciales de alguna manera (averiguar nuestra contraseña).

Acceso a URLs restringidas: Consiste en la observación de una URL e intentar cambiarla para intentar acceder a otras zonas. Estas es una de las razones por las que la seguridad a través de la ocultación no es efectiva.

Solucionando los problemas de seguridad

Ahora que ya hemos identificado y visto en que consisten los problemas que nos podemos encontrar en las aplicaciones web, o al menos lo más importantes y peligrosos vamos a ir uno por uno explicando como hemos de solucionarlos. Iremos primero a los dos últimos que son los más sencillos y en posteriores entradas explicaremos la solución a los dos primeros que son los más importantes de los cuatro y quiero dedicarles una entrada completa.

Robo de sesión

Ya hemos visto el riesgo que tiene el robo de una sesión. Podríamos decir de manera resumida que el peligro está en la exposición de los datos de sesión. En la ilustración de la presentación de seguridad que hice podemos ver una posible situación de robo de sesión.

Para solucionar este problema de seguridad hay que atenerse a varios aspectos de la seguridad: la autentificación y la sesión; para cada uno de ellos veremos varios aspectos importantes a cubrir para solucionar problemas con el robo de sesión.

La Autentificación

El más importante de todos. Usar SSL sobre HTTP (HTTPS) para transferir los datos y asegurarse de que el cifrado cubre los credenciales y el ID de sesión en todas las comunicaciones. De esta manera los datos de sesión de los que hablábamos siguen estando expuestos pero esta vez se encuentran cifrados, por lo que no se pueden usar. Alguien podría pensar: “¿Y si se obtiene la sesión y se rompe la encriptación?”, la respuesta es sencilla, y es que con los medios actuales para cuando hayas conseguido romper la encriptación esa sesión habrá dejado de existir.

Usar un sistema de autentificación simple, centralizado y estandarizado. Es mejor que usemos métodos de autentificación que nos proporcione el propio servidor de aplicaciones en vez de soluciones implementadas por nosotros, debido a que lo que implementa el servidor de aplicaciones es usado en muchos lugares y ha sido suficientemente probado. Por ejemplo los filtros de Java EE (que veremos posteriormente) o los métodos de autentificación que proporciona Java EE (no los he usado).

Posibilitar el bloqueo de autentificación después de un número determinado de intentos fallidos. Esto podría evitar ataques de fuerza bruta intentando averiguar la contraseña del usuario.

Implementar métodos seguros de recuperación de contraseñas: Es común que se intenten usar estos métodos para intentar ganar acceso a una cuenta del usuario, podemos ver una serie de consejos para implementar estos métodos. Pedir al usuario al menos tres datos o más, obligar a que responda preguntas de seguridad. La contraseña que recuperada deberá generarse de manera aleatoria (con una longitud de al menos 8 caracteres) y enviada al usuario por un canal diferente (E-mail); de esta forma si el atacante consiguió sortear los primeros pasos es difícil que logre sortear el canal usado para transmitir.

La Sesión

Usar los métodos de sesión que nos proporciona el servidor de aplicaciones que estemos usando, y digo esto por las mismas razones que aconsejé usar los métodos de autentificación que proporciona el servidor de aplicaciones. En este caso no estamos refiriendo a la sesión y a las cookies.

Asegurar que la operación de cierre de sesión realmente destruye dicha sesión. También fijar el periodo de expiración de la sesión (periodo de tiempo en el que no se realice ninguna acción bajo dicha sesión); por ejemplo para aplicaciones críticas de 2 a 5 minutos, mientras que para otras aplicaciones más comunes se podría usar de 15 a 30 minutos.

En el descriptor de despliegue podemos fijar la caducidad de la sesión en minutos.

Ahora que hemos visto las formas de evitar el robo de sesión; o al menos de manera teórica, ahora vamos a ver como se hacen esta serie de cosas en la práctica.

Hemos hablado de usar métodos proporcionados por el servidor de aplicaciones para realizar la autenticación usando filtros y la sesión. Vamos a ver en concreto como podría hacerse. En primer lugar habrá que comprobar si los datos de usuario son correctos y posteriormente se podría hacer algo como añadir algún parámetro a la sesión indicando que esta autenticada. Voy a simplificar mucho un código para que nos centremos en lo fundamental.

if (password.equals(user.getPass()) == true) {
	//Se añade a la sesión un boolean indicando que está autentificado
	request.getSession().setAttribute("auth", true);

	//Se añade a la sesión el identificador del usuario
	request.getSession().setAttribute("usuario", user.getMail());
}

Respecto a bloquear el inicio de sesión después de un número determinado de intentos fallidos podría ser tan fácil como añadir a la sesión el número de intentos fallidos y en el caso de que superen un determinado número no ejecutar ningún mecanismo de autenticación ni mostrar el formulario de login, únicamente habría que lanzar un timer para desbloquear el inicio de sesión pasado un tiempo.

protected void starTimer(final HttpSession sesion) {
	//Tarea que se lanzará cuando el Timer la ejecute
    TimerTask timerTask = new TimerTask() {

        @Override
        public void run() {
            sesion.invalidate();
        }
    };

    Timer timer = new Timer ();
	//El tiempo esta en milisegundos y se lanza la tarea que definimos anteriormente
    timer.schedule(timerTask, 600000);
}

Luego, para comprobar este parámetro (el que se ha añadido a la sesión para comprobar si se ha autentificado o no) sería factible usar filtros para todas las URLs para las que se necesite permiso y en ellos comprobar si existe el parámetro añadido en la sesión o no.

Lo primero de todo en el descriptor de despliegue (web.xml) hemos de configurar el filtro. Definiremos el filtro para un patrón de URL, en este caso todas las estén dentro del directorio /admin. Como sabemos los filtros actúan ante las peticiones de cliente para los patrones de URL para los que estén definidos. ¿Es esto del todo cierto? Pues no, en Java EE 6 esto ha cambiado un poco y podemos especificar que un filtro se ejecute sin necesidad de que el cliente haga una petición, simplemente con que el servidor haga una redirección porque así lo especifique el código (repito, sin que el cliente tenga nada que ver y sin que sepa nada de esa redirección). Podemos hacer esto mediante las sentencias que he dejado resaltadas.



	AdminFilter
	control.admin.AdminFilter



	AdminFilter
	/admin/*
	REQUEST
	FORWARD
	INCLUDE
	ERROR

Ahora veremos la clase que implementa el filtro y veremos que es a la misma clase a la que se hace referencia en el descriptor de despliegue. En ella simplemente se comprueba la existencia de los parámetros que se añadieron a la sesión en el proceso de autenticación. Los nombres de las variables son claros por lo que no he hecho comentarios, me parece que se ve claro el objetivo del código

Unicamente comentar que un Servlet no es exclusivo de una aplicación web, un ServletHttp es una clase de Servlet especial por así decirlo, de ahí que con el ServletRequest que nos da el filtro no podamos obtener la sesión y por eso necesitamos la primera línea del método doFilter en la que se hace un casting.

package control.admin;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

/**
 * @author Juan Díez-Yanguas Barber
 */
public class AdminFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		//Obtenemos un HttpServletRequest con un casting
        HttpServletRequest requestMod = ((HttpServletRequest) request);
        if (isPermited(requestMod) == false){
            requestMod.getSession().setAttribute("requestedPage", requestMod.getRequestURL().toString());
            RequestDispatcher noPermited = request.getRequestDispatcher("/WEB-INF/paginasError/restricted.jsp");
            noPermited.forward(request, response);
        }else{
			//Continua la secuencia de ejecución normal
            chain.doFilter(request, response);
        }
    }

    private boolean isPermited(HttpServletRequest request) {
        if (request.getSession().getAttribute("auth") == false || request.getSession().getAttribute("usuario") == null) {
            return false;
        } else{
            return true;
        }
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void destroy() {
    }
}

Ahora veremos como cerrar la sesión de la manera más correcta. Lo más correcto sería destruir la sesión, de esta manera nuestra sesión dejará de existir a todos los efectos. Para ello usaremos la siguiente sentencia, cuya función es destruir la sesión. La podríamos usar por ejemplo en un Servlet encargado del cierre de sesión.

request.getSession().invalidate();

Respecto al tema de las contraseñas voy a dedicar al final de esta entrada un apartado donde explicaré como trabajar correctamente con ellas.

Acceso a URLs restringidas

Como ya hemos visto en el apartado teórico sobre este problema la seguridad a través de la ocultación no sirve de nada. Si por ejemplo para la parte pública se usara un patrón de URL /public el atacante podría pensar que la parte privada pudiera ser /admin o cosas parecidas, con no dar a conocer el detalle de ese directorio no es suficiente, hay que protegerlo.

Como a estas alturas supondremos no hay que hacer nada especial si se ha realizado lo anterior, es decir, si hemos realizado una autenticación y un control de sesión correctos. Con el uso de los filtros podríamos solucionar este problema perfectamente.

Se que es un problema que a la vista parece bastante evidente y con una solución sencilla; pero mientras siga apareciendo como uno de los problemas más graves de seguridad será porque no está tan bien solucionado aunque sea evidente el problema y la solución.

Trabajando correctamente con contraseñas

Las contraseñas son un dato delicado, la palabra secreta que usa el usuario para acceder a su cuenta en el sitio web, algo suyo y personal. Por este motivo únicamente el usuario debería conocer su contraseña. Ahora bien, si solo conoce él la contraseña… ¿Cómo la comprobamos cuando inicie sesión? Vamos a ver que si que es posible hacerlo sin conocer la contraseña; lo haremos usando una huella digital MD5 o SHA1 (he puesto los enlaces en inglés, me parecían más completos).

En definitiva estos dos son los algoritmos más usados para la generación de huellas digitales, consistentes en crear una suma siempre de igual longitud independientemente del tamaño del mensaje y con la particularidad de que no se puede volver al mensaje original a partir del mensaje encriptado; pero un mismo mensaje siempre genera el mismo código.

//Método para generar la huella MD5
public static String generateMD5Signature(String input) {
    try {
		//Cambiando MD5 por SHA-1 podríamos obtener la huella usando este otro algoritmo
        MessageDigest md = MessageDigest.getInstance("MD5");
        byte[] huella = md.digest(input.getBytes());
        return transformaAHexadecimal(huella);
    } catch (NoSuchAlgorithmException ex) {
        Logger.getLogger(Tools.class.getName()).log(Level.SEVERE,
                "No se ha encontrado el algoritmo MD5", ex);
        return "-1";
    }
}

//Método para transformar el array de bytes en una cadena hexadecimal
private static String transformaAHexadecimal(byte buf[]) {
    StringBuilder strbuf = new StringBuilder(buf.length * 2);
    for (int i = 0; i < buf.length; i++) {
        if (((int) buf[i] & 0xff) < 0x10) {
            strbuf.append("0");
        }
        strbuf.append(Long.toString((int) buf[i] & 0xff, 16));
    }
    return strbuf.toString();
}

A sabiendas de lo anterior podríamos darnos cuenta de que si en vez de guardar la contraseña de los usuarios guardamos la huella digital de la misma podremos verificar su identidad cuando él inicie sesión, y no tendremos su contraseña guardada ni modo alguno de obtenerla. Lo que habrá que hacer es obtener la huella de su contraseña cuando el usuario la introduzca y la compararemos con la huella que nosotros teníamos guardada.

Así estaremos protegiendo al usuario; si nuestra base de datos se viese comprometida y llegamos a tener guardadas las contraseñas todos nuestros usuarios estarían expuestos, mientras que de esta manera que explico esto no ocurriría.

¿Es este método infalible? Pues no, existen tablas de huellas de palabras clave que se suelen usar, ya se sabe que no solemos ser bastante ocurrentes poniendo las palabras clave (solemos usar 1234, password, etc…), así que si disponen de una tabla de este tipo podrían obtener las contraseñas a partir de las huellas de nuestra base de datos comprometida (si bien no obtendrán todas, alguna seguro que sí).

Pues bien, aún con estos problemas nos quedan armas a usar. Si en vez de guardar las huellas de las contraseñas, guardamos las huellas de las contraseñas sumado con algo más. Si obtienen el mensaje que formó esa huella con una tabla de esas obtendrían la contraseña más eso que añadimos nosotros, luego no obtienen la contraseña. Y esto podría admitir muchas variaciones, como poner caracteres por enmedio de la contraseña, al final, al principio, lo que se añada a la contraseña podría ser tan complejo como desearamos. Pero sin olvidarse que al comprobar la contraseña habrá que hacer el mismo proceso.

Vamos a ver un ejemplo sencillo, mostraremos como se introduce la contraseña cuando el usuario se registra y como se comprueba cuando inicia sesión. En este caso vamos a añadir al final de la contraseña el nombre de usuario del sistema (Podría haber problemas si se cambiara el nombre de usuario en la máquina, pero no me voy a centrar en eso ahora, esto pretende ser solo un ejemplo ilustrativo).

String pass = request.getParameter("pass");
pass = Tools.generateMD5Signature(pass + System.getProperty("user.name"));

Veamos ahora el proceso de comprobación (user será el usuario que tenemos guardado ya en la base de datos y del cual tenemos su huella de la contraseña más el añadido).

String pass = request.getParameter("pass");
if (Tools.generateMD5Signature(password + System.getProperty("user.name")).equals(user.getPass()) == true) {
	//Contraseña correcta
} else {
	//Contraseña incorrecta
}

Ahora la cuestión viene cuando hacemos un método para recuperar la contraseña, no la podemos recuperar de forma alguna, no la hemos guardado. Por lo tanto, lo que habrá que hacer es generar una nueva y asignarla al usuario y mandarle la nueva contraseña por correo.

//Como argumento la longitud de la contraseña
String newPass = RandomStringUtils.randomAlphanumeric(19);
String newPassHash = Tools.generateMD5Signature(newPass + System.getProperty("user.name"));
//Asignar newPassHash al usuario

Hasta aquí llegamos con este artículo, como ya he comentado, trataré los otros problemas de seguridad de artículos posteriores. Espero que os haya sido de utilidad y os ayude a hacer aplicaciones web más seguras. También podeis encontrar más información en la web de OWASP sobre la autentificación y sobre más cosas que hemos estado tratando.

Digo lo mismo de siempre, estoy a vuestra disposición para dudas, comentarios o lo que sea; por supuesto también podeis aportar alguna otra cosa que consideréis interesante.

Java EE 6: Subida de imágenes al servidor (Servlet 3.0)

Juan — Wed, 12 Oct 2011 09:12:12 +0000

Vamos a ir poco a poco centrándonos en algunas partes concretas del proyecto que presente de la tienda online y así veremos en detalle determinadas partes. Hoy nos vamos a centrar en ofrecer la posibilidad de que el cliente de nuestra web pueda subir imágenes a nuestro servidor web de una manera muy sencilla

Antes de la especificación 3.0 de los Servlets esta tarea se tenía que hacer usando las librerías de Apache Commons y se convertía en una tarea más larga y menos clara; desde la nueva especificación no es necesario usar ninguna librería externa dado que nos da esta posibilidad de serie y de una manera muy sencilla. Pues bien, comencemos.

El formulario

Lo primero que hay que hacer es una pequeña modificación en el formulario donde se quiera subir la imagen, puesto que ahora los datos no se van a enviar en modo texto sino como un flujo binario, y teniendo en cuenta esto último el verbo HTTP usado será POST y nunca GET; de manera que la cabecera de nuestro formulario tendra una forma como la que os muestro.

Una vez que ya tenemos la estructura del formulario HTML, ya podemos añadir los campos que queramos al formulario al igual que lo hacemos normalmente, sabiendo que el campo para seleccionar la imagen sera de tipo file. Una vez hecho nos quedaría algo como lo que sigue.


            Nombre 

            


            Escoja una foto de producto (Opcional)

            


            Detalles 

            Puede usar etiquetas html (si usa etiquetas invalidas sera bloqueado)

Procesando el formulario

Una vez que ya tenemos el formulario HTML preparado ya estaríamos en condiciones de pasar a la parte de servidor para procesar este formulario que hemos creado; es decir, crear el Servlet encargado de procesar este formulario; que veremos que se procesa de una forma algo distinta a como estamos acostumbrados; principalmente debido a que ahora no hemos recibido texto sino un flujo de datos y de ahí tendremos que obtener el texto normal y la fotografía. En el formulario he puesto tres tipos de campos para que veamos como procesar cada uno de ellos (texto, archivo, textarea).

En primer lugar el Servlet encargado de procesar el formulario deberá llevar la anotación @MultipartConfig. Y ahora puede haber varias preguntas clave.

¿Cómo se si se ha enviado la imagen o no? (el usuario pudo no poner la imagen). Sencillo, si el Part (nombre que se le da a un campo en un formulario de este tipo) ocupa cero bits.
¿Cómo se si el archivo que se ha seleccionado es una imagen? Hay un método para saber el tipo de archivo subido. Si contiene la cadena image sabremos que es una imagen (image/jpeg, etc…)
¿Cómo guardamos la imagen en disco? Tendremos que obtener el InputStream del Part.
¿Cómo obtenemos los campos que son de tipo texto, ahora no recibo texto? Ahora veremos que hay una manera sencilla de hacerlo. Os enseñaré los métodos de la clase estática Tools.

Ahora os muestro el código del Servlet completo, he puesto algunos comentarios en el mismo. Está basado en uno de los Servlets de tienda online, he quitado bastante código para mostrar prácticamente solo lo referente al tema que nos concierne ahora en concreto, obviamente entendiendo lo fundamental podemos modificarlo para que cumpla con la función que cada uno desee. En el código veremos que se resaltan las líneas fundamentales que responden a cada una de las preguntas que he planteado en el párrafo anterior. Por supuesto el Servlet estará dado de alta en el descriptor de despliegue y atendiendo peticiones en la ruta a la que se envía el formulario HTML.

import control.Tools;
import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.MultipartConfig;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * @author Juan Díez-Yanguas Barber
 */

//Anotación necesaria para procesar formulario
@MultipartConfig
public class AddServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
				response.sendError(404);
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        if (validateForm(request)) {
				//Extraemos el texto del formulario
                String nombre = Tools.getcontentPartText(request.getPart("name"));
                String detalles = Tools.getContentTextArea(request.getPart("detail"));                               

				//Comprobamos si el formulario contiene o no la imagen (usamos el tamaño para comprobar si existe el campo o no)
                if (request.getPart("foto").getSize() > 0) {
					//Nos aseguramos que el archivo es una imagen y que no excece de unos 8mb
                    if (request.getPart("foto").getContentType().contains("image") == false ||
                            request.getPart("foto").getSize() > 8388608) {
						// TIPO DE ARCHIVO NO VALIDO
                        request.setAttribute("resultados", "Archivo no válido");
                        Tools.anadirMensaje(request, "Solo se admiten archivos de tipo imagen");
                        Tools.anadirMensaje(request, "El tamaño máximo de archivo son 8 Mb");
                        request.getRequestDispatcher("/admin/add.jsp").forward(request, response);
                        return;
                    }else{
						//Obtenemos la ruta absoluta del sistema donde queremos guardar la imagen
                        String fileName = this.getServletContext().getRealPath("/images/products/imagen");
						//Guardamos la imagen en disco con la ruta que hemos obtenido en el paso anterior
                        boolean ok = Tools.guardarImagenDeProdructoEnElSistemaDeFicheros(request.getPart("foto").getInputStream(), fileName);
                        if (ok == false){
                            request.setAttribute("resultados", "Fallo al guardar archivo");
                            Tools.anadirMensaje(request, "Ocurrio un error guardando la imagen");
                            request.getRequestDispatcher("/admin/add.jsp").forward(request, response);
                            return;
                        }
                    }
                }
				//TODO CORRECTO SE REDIRIGE A UNA PAGINA DE VISUALIZACIÓN
				Producto prod = new Producto(nombre, detalles);
				request.getSession().setAttribute("productoEnCursoAdd", prod);
				request.setAttribute("operation", "add");
                RequestDispatcher previsualizacion = request.getRequestDispatcher("/WEB-INF/admin/view.jsp");
                previsualizacion.forward(request, response);
        } else {
            request.setAttribute("resultados", "Formulario no válido");
            Tools.anadirMensaje(request, "El formulario recibido no tiene los campos esperados");
            request.getRequestDispatcher("/admin/addproduct.jsp").forward(request, response);
        }
    }

	//Método para validar que el formulario contiene los parámetros correctos
    private boolean validateForm(HttpServletRequest request) throws IOException, ServletException {
        if (request.getParts().size() >= 4 && request.getPart("name") != null &&
                request.getPart("detail") != null && request.getPart("send") != null) {
            return true;
        }
        return false;
    }

    @Override
    public String getServletInfo (){
        return "Servlet para añadir productos al catálogo";
    }
}

Resumiendo, lo primero que hace el servlet es comprobar que se reciben los parámetros correctos y no menos, si la validación ha sido correcta se obtienen los campos de texto como veremos ahora. Posteriormente comprobamos si hay archivo o no, y en caso de que lo haya comprobamos que es una imagen y que el tamaño no exceda de 8 Mb, posteriormente se guarda en disco el archivo. Si quereis obtener más información sobre el archivo os animo a que investigueis los métodos del objeto Part. Es enviado un error 404 para una petición GET que llegue a este servlet debido a que no tendría porque accederse por dicho verbo HTTP (no hay ninguna razón para hacerlo) y podríamos evitarnos así posibles problemas, evitamos que se “hagan experimentos” con nuestra aplicación web.

Los atributos que yo añado a la petición son usados para dar el mensaje correspondiente en la jsp a la que se redirige, por lo tanto vosotros hacer caso solo al texto de los mensajes.

Y ahora nos falta ya por concretar como obtener los campos de texto y como guardar la imagen en disco que tal como aparece en el Servlet aparece simplificado al aparecer en una única línea, pero claro, hay que ver lo que hace esa línea.

Para el caso del texto veremos que podemos obtener un InputStream del Part del formulario y podemos leerlo por ejemplo con la clase Scanner de Java. La única diferencia entre obtener el texto de un campo de texto y un textarea será que tenemos que mantener los saltos de línea para el segundo como veremos ahora. Mientras que en un campo de texto solo habrá una línea. Otro apunte importante sería especificar la codificación para evitar errores con caracteres como tildes, eñes o similares. Por último decir que observeis como se abren y se cierran los objetos de tipo Scanner asegurándonos de que se cierren siempre ocurra o error o no.

public static String getcontentPartText(Part input) {
		Scanner sc = null;
		String content = null;
        try {
            sc = new Scanner(input.getInputStream(), "UTF-8");
            if (sc.hasNext()) {
                content = sc.nextLine();
            } else {
                content = "";
            }
            return content;
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
			content = null;
        }finally{
			sc.close();
		}
		return content;
    }

    public static String getContentTextArea(Part input) {
		StringBuilder sb = null;
		Scanner sc = null;
        try {
            sc = new Scanner(input.getInputStream(), "UTF-8");
            sb = new StringBuilder("");
            while (sc.hasNext()) {
                sb.append(sc.nextLine());
                sb.append("\n");
            }
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
            sb = null;
        }finally{
			sc.close();
		}
		if (sb == null){
			return null
		}else{
			return sb.toString();
		}
    }

Bueno, y ahora ya solo nos faltaría ver como guardar la imagen en disco, como hemos dicho obteniendo el InputStream del Part del formulario (que ya lo obtuvimos en el Servlet y se lo pasamos ahora a este método estático) y también asegurándonos de cerrar los flujos de datos en todos los casos de error y de éxito.

public static boolean guardarImagenDeProdructoEnElSistemaDeFicheros(InputStream input, String fileName)
            throws ServletException {
        FileOutputStream output = null;
        boolean ok = false;
        try {
            output = new FileOutputStream(fileName);
            int leido = 0;
            leido = input.read();
            while (leido != -1) {
                output.write(leido);
                leido = input.read();
            }
        } catch (FileNotFoundException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
        } catch (IOException ex) {
            Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, ex.getMessage());
        } finally {
            try {
                output.flush();
                output.close();
                input.close();
                ok = true;
            } catch (IOException ex) {
                Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, "Error cerrando flujo de salida", ex);
            }
        }
        return ok;
    }

Hasta aquí creo que no se me queda ningún aspecto por cubrir, únicamente añadir alguna anotación. Comentar que sería interesante para administrar las imágenes guardar sus nombres en una base de datos haciéndolas corresponder con productos por ejemplo en el caso de una tienda. Y aspectos a corregir de mi modo de hacerlo en el proyecto de la tienda sería guardar las imágenes con extensión, puede ser que no todos los navegadores muestren la imagen correctamente, también sería interesante guardar las imágenes con nombres normales y no con códigos, esto último más que nada para el SEO (Search Engine Optimization), debido a que con nombres normales las imagenes se indexarán mejor en los buscadores.

Ahora ya si que he dicho todo lo que tenía que decir y se han cubierto todos los aspectos sobre el tema. Espero que os sea de utilidad esta guía y como siempre digo estoy abierto a dudas sugerencias o lo que os haga falta.

Fallece Steve Jobs

Juan — Thu, 06 Oct 2011 10:01:21 +0000

Hoy según me he levantado por la mañana me he llevado una sorpresa en mi recorrido habitual de noticias por la web. Ha fallecido Steve Jobs esta noche. Una desagradable sorpresa sin duda alguna, el mundo ha perdido una gran persona.

Yo personalmente llevo ya un año manejando un MacBookPro y desde entonces estoy más pendiente de las noticias del mundo apple. Steve Jobs sin duda alguna fue un gran visionario y es el responsable de que hoy hagamos muchas cosas de manera totalmente distinta a como las solíamos hacer. Ha sido un gran emprendedor.

Desde aquí mi más sincero pésame por la pérdida de una gran persona y visionario como dice su sucesor en el cargo Tim Cook.

“Si vives cada día como si fuera el último, algún día acertarás… Cada día me miro al espejo como si fuera el último” Steve Jobs 2005 (Stanford)

En la página de la compañía le rinden homenaje.

Jdiezfoto » Informática

Internet, ¿Qué es y como funciona?

Artículos más comentados

Spotbros: Un ejemplo de como hacer las cosas bien

Artículos más comentados

JRebel: Stop Redeploying

También te puede interesar:

Vanadium: Validación de formularios con JQuery

También te puede interesar:

Tienda Online Java EE: Solucionada validación ajax en formulario de registro

También te puede interesar:

Java EE: Seguridad en aplicaciones web (II). Evitando Inyección SQL y XSS con ESAPI

También te puede interesar:

Tutorial ANT: Uso con librerías externas y generadores JFlex y CUP

También te puede interesar:

Java EE: Seguridad en aplicaciones web (I)

También te puede interesar:

Java EE 6: Subida de imágenes al servidor (Servlet 3.0)

También te puede interesar:

Fallece Steve Jobs

Artículos más comentados