Conceptos

Generalmente cuando tenemos problemas, empezamos a buscar herramientas poco comunes para encontrar la causa o causas raices de la situación (actitud reactiva). En fin, el problema que se nos presentó en su momento fue en una aplicación que autentica Vs un directorio Novell, utilizando el standar LDAP. Sin embargo, la librería que se utiliza para esta actividad, es propietaria de la aplicación y contiene un bug que en cada cierto número de petición genera threads nuevos para atenderlas y cuando la petición fue concluída, el thread permanece con estado ALIVE y espera hasta una recolección de basura (FGC) para ser eliminado. "WRONG", es un leak en el heap de java pues se desperdicia una cantidad considerable de memoria y tiempo de ejecución del GC, cuando hablamos de instancias de Java de 32G.

En la siguiente gráfica (Cacti) muestra el comportamiento de los Threads vs FGC:

La solución fue hacer un switch del módulo LDAP a OpenLDAP que sorprendentemente no presentaba el problema.

Tal vez algunos hayan escuchado de memcached, un software que provee un cache en memoria para cualquier cosa que quieran almacenar de manera temporal. El concepto detrás de este software es muy simple: es como tener un mapa gigante, al cual ustedes le pasan una llave, un valor y una duración o fecha de expiración. El software almacena el valor, que será accesible al pedirlo por la llave bajo la cual fue almacenado; cuando la fecha de expiración pase, el cache ya no devuelve el valor para esa llave, porque ya expiró.

Este software se ha vuelto muy utilizado en varias aplicaciones web por las siguientes razones:

• Es muy fácil de instalar (en Linux/*NIX al menos) y configurar.
• Meter valor al cache y leerlos es bastante rápido, incluso cuando hay varias miles de llaves vigentes.
• Se puede utilizar de manera distribuida, teniendo varias instancias en distintos equipos y ninguna tiene que saber de la existencia de las otras; el cliente es quien hace la distribución de valores a las distintas instancias.
• Hay clientes para varios lenguajes y plataformas: Ruby, C, PHP, y por supuesto Java.

Muchas veces nos encontramos con problemas de conversión de tipos de datos, principalmente cuando le solicitamos datos al usuario el API de java nos provee clases útiles para manejar estas situaciones.

Lo que les dejo aquí es un simple resumen de uno de los muchos puntos que se ven en el capitulo 3 de:

SCJP Study guide - Katy Sierra

Las clases envolventes tienen dos principales funciones en java:

Existe para cada tipo primitivo una clase envolvente, nombrada igual que su dato primitivo pero su nombre empieza con mayuzcula.

El tercer y último ejemplo que vimos en la plática de Seguridad en Aplicaciones Java, fue el de Cross-Site Scripting, conocido por su abreviatura como XSS.

Este ataque puede ser bastante complejo en cuanto al daño que se pueda hacer y los lugares por donde se puede realizar (vectores de ataque). Sin embargo, el fundamento es muy similar al de la inyección de SQL: usar datos que capturan los usuarios, sin validarlos apropiadamente.

La inyección de SQL permite que un usuario malicioso pueda enviar a una aplicación ciertos datos que incluyan sentencias de SQL que se ejecutarán en el servidor de base de datos. Los ataques de XSS usan ese mismo principio pero los datos que se envian, pueden incluir código HTML y/o Javascript; la principal diferencia es que dicho Javascript es inocuo en el servidor pero al ser incluido en páginas que se envían a otros usuarios, sus navegadores posiblemente ejecutarán dicho Javascript.

El siguiente ejemplo que hubo en la plática de seguridad en aplicaciones Java fue de inyección de SQL. Este ataque es posible cuando se capturan datos y se concatenan directamente dentro de una sentencia SQL, sin validarse; este método de hecho también es el fundamento de los ataques XSS (cross-site scripting).

En seguimiento a la plática del sábado (seguridad en aplicaciones Java), aquí están nuevamente los ejemplos que expuse ese día. Comencemos con el de DoS (Denial of Service: negación de servicio)

Este ataque se puede dar cuando tenemos un ServerSocket aceptando conexiones y manejando un protocolo propietario. En este caso el protocolo es muy simple y consiste simplemente en un mensaje de texto que primero lleva dos bytes de encabezado indicando su longitud (en binario). De modo que para recibir las conexiones tenemos el siguiente código: