Mostrando entradas con la etiqueta sql. Mostrar todas las entradas
Mostrando entradas con la etiqueta sql. Mostrar todas las entradas

lunes, julio 11, 2011

Los 25 Errores de Software Más Peligrosos del 2011

"SQL Injection. Una de las más peligrosas y comunes vulnerabilidades en los sistemas"

Recientemente me entero de una comunidad online de programadores y especialistas en seguridad que cada año se encargan de enumerar las vulnerabilidades de sistemas informáticos que más daño han realizado y que más se han popularizado entre los sistemas para que cada uno tome las medidas necesarias al momento de desarrollar sus sistemas especialmente cuando manejamos datos que al ser vulnerados causarían pérdidas significativas de información en nuestra empresa.

Esta comunidad, denominada Common Weakness Enumeration, liberó recientemente la lista de los 25 errores de software que más se han utilizado y que más daño han causado durante el presente año de manera que podamos tomarlos en cuenta para evitar que nuestros sistemas sean atacados.

Además de la lista, en el sitio puedes encontrar información detallada del error, las variaciones que pudieran existir del mismo, código fuente de ejemplo de utilización del ataque y posibles alternativas de corrección a las vulnerabilidades que este aprovecha. Es una fuente bastante completa de ítems a tomar en cuenta al momento de diseñar la seguridad de nuestro sitio. De hecho, si en su equipo de desarrollo o calidad no poseen un checklist de vulnerabilidades a cubrir, les recomiendo usar este sitio como referencia.

Me remito a describir en español las tres primeras vulnerabilidades de la lista:

1. La inadecuada neutralización de comandos especiales utilizados en SQL (A.K.A. SQL Injection). La número uno de la lista. Tal como lo ilustra la imagen del post, si utilizamos SQL simple para validar nuestras páginas de login, algo como por ejemplo:

"SELECT * FROM SYSTEM.USERS WHERE NAME = '" + inputBox1.text + "' AND PASSWORD = '" + inputBox2.text + "'";

cualquiera podría escribir cualquier comando SQL dentro de los textboxes y con suficiente astucia obtener acceso total al sistema saltándose la validación del login o peor aún, obteniendo acceso total a la base de datos.

Esto me recuerda a una vieja ilustración que XKCD elaboró para el día de las madres:

"...'Little Bobby Tables' xD"

En el blog de El Rincon de Cisko pueden encontrar más información en español acerca de este tema.

2. La inadecuada neutralización de comandos especiales utilizados en un sistema operativo (A.K.A. OS Command Injection). Aplica el mismo principio que el SQL Injection pero en este caso nos referimos a comandos del sistema operativo. Pueda ser menos común que nuestros programas ejecuten comandos directamente sobre el sistema operativo pero aunque sea menos común, esta vulnerabilidad es mucho más peligrosa que el SQL Injection ya que en el sistema operativo pueden residir no solamente el servidor de aplicaciones, servidor web y servidor de bases de datos sino muchos otros servicios sin mencionar que una vez que el atacante ha logrado ingresar a un servidor, es mucho más fácil que este logre acceso a cualquier otro servidor dentro de la intranet, especialmente si nuestro servidor de aplicaciones posee privilegios de administrador (root) lo cual es mencionado en otro elemento de la lista: "11. Ejecución de aplicaciones/servicios con privilegios mayores a los necesarios".

3. Copia de búffers sin la comprobación del tamaño del dato de entrada (Buffer Overflow). Este es nuevo para mí. Según la documentación del sitio leo que aplica mayormente para lenguajes de programación que no poseen un manejo automático de la memoria utilizada, como por ejemplo C y C++ ya que estos no revisan previamente si la porción de memoria donde se están escribiendo los datos está reservada para su fin o si su tamaño excede lo esperado y termina escribiéndose información en la memoria reservada del sistema operativo, por ejemplo.

La recomenadación para evitar esta vulnerabilidad consiste en verificar previamente el tamaño de los búffers de entrada, utilizar librerías o frameworks que realizan esta comprobación por nosotros o utilizar lenguajes de alto nivel que poseen un manejo automático de la memoria a utilizar por aplicación o grupo de aplicaciones.

Les recomiendo nuevamente y con gran énfasis leer el resto de la lista de vulnerabilidades y sus respectivos detalles técnicos, causas y soluciones para que como programadores y administradores de sistemas podamos dormir bien por las noches sin preocuparnos porque el operador nos va a llamar en la madrugada avisándonos que vulneraron un server y robaron información confidencial y valiosa de nuestra empresa. Mas aún teniendo en cuenta los recientes ataques de LulzSec, AntiSec y Anonymus.

vía Java Code Geeks.

sábado, enero 08, 2011

Propósito de Año Nuevo: Un Nuevo Lenguaje de Programación.


Llegó el año nuevo y muchos suelen establecer propósitos que intentarán cumplir durante el nuevo año. Unos pueden proponerse hacer más ejercicio, conseguir un nuevo trabajo, procrastinar menos, etc. En esta ocasión les propongo como propósito aprender un nuevo lenguaje de programación.

Posiblemente seas ya un master en .Net, ya conozcas todo lo que se debe saber sobre los foundation y hasta tengas tu certificación. Quizá tengas años de experiencia trabajando con java y sus stacks, quizá spring, faces, ejbs. Quizá seas uno de los mejores con Python o Ruby o quizá tengas un enorme portafolio de sitios elaborados con PHP en tu currículum. Es muy importante escoger un lenguaje de programación, aferrarnos a el y conocerlo a fondo pero no debemos quedarnos hasta ahí. Es importante seguir avanzando y no necesariamente en la misma rama que ya dominamos porque llegará un momento en el que nuestro lenguaje ya no sea el más popular o el mejor pagado en el mercado y sea hora de migrar a uno nuevo.

Lenguajes de programación hay muchos allá afuera, unos más populares que otros, unos más fáciles que otros, con mayor o menor soporte, con su única manera de abstraer el mundo real y expresarlo mediante su sintaxis y frameworks. Cada lenguaje tiene su especialidad y principal enfoque y pueda que nos sea una ventaja conocerlo en algún momento.

Para todo aquel programador Java que a veces siente que le hace falta un poco de scripting language pero no quiere soltar las bondades del JDK es un buen momento para animarse a aprender Groovy. Un lenguaje que te permite experimentar esa agilidad del "write less, do more" haciendo uso de las ya conocidas bondades del JDK de java.

Posiblemente seas un programador de backends y siempre te ha impresionado la calidad de las interfaces gráficas que se pueden desarrollar hoy en día mediante CSS y Javascript. Puede ser un buen momento de pasarse al lado de los frontends y aprender un poco de jQuery, Scriptaculous o Motools y sacarle provecho a lo que estos frameworks pueden hacer con el DOM y el CSS de tus sitios.

En lo personal, siempre me he sentido esa apatía por el SQL y he sufrido mucho cuando he tenido que realizar grandes consultas
con SELECT anidados, JOINs y CASEs pero a la vez he podido comprobar la ventaja de utilizar procedimientos almacenados escritos con PL/SQL por lo que espero poder aprender y poner en práctica este lenguaje en este año.

En conclusión, un nuevo lenguaje de programación te abre la mente a una nueva forma de abstraer el mundo, resolver tus problemas/necesidades de información y escribir su lógica mediante una sintaxis diferente. Además, agregas una nueva habilidad a tu currículum por lo que te vuelves un profesional más valioso y con un horizonte más amplio de oportunidades de empleo. Documentación existe de sobra en la red por lo que esto nunca será una excusa mucho menos un obstáculo para aprender. Además, los programadores tendemos a tomar esa buena costumbre de volvernos autodidactas por lo que en la mayoía de las veces no es necesario pagar por cursos presenciales para aprender.

Qué nuevo lenguaje de programación les interesaría aprender este año?

miércoles, abril 21, 2010

Herramientas Online de Formato e Indentación de Código

Mas de alguna vez nos ha tocado revisar algún mensaje XML o JSON fuera de la oficina, donde no tenemos nuestras herramientas de desarrollo que tan agradablemente se encargan de formatear e indentar nuestros archivos para que podamos leerlos, analizarlos y encontrar posibles fallas en ellos. En estas ocasiones nos ha tocado manualmente estar partiendo el archivo en diferentes líneas y agregando sangrías para darle el formato adecuado y se nos vuelva más fácil su análisis

Si de casualidad nos encontramos en estas circunstancias pero tienen la bondad de contar con una conexión a Internet, pueden aprovechar algunas herramientas online que se encargan de formatear, colorear e indentar nuestros archivos de código fuente.

Hay muchos otros que no he listado acá por el hecho de que solamente colorean el código y considero mas útiles aquellos que además del syntax highlight también te agregan los respectivos espacios de tabulación.

XML:


"Captura de pantalla de xmlindent.com, formateando un xml de ejemplo (click para agrandar)"

JSON:


"Captura de pantalla de jsoneditor.net, quien te forma la estructura jerárquica de tu mensaje JSON"

Múltiples lenguajes de programación:


Cabe resaltar algunas características especiales que poseen algunas de estas herramientas como por ejemplo jsbeautifier además de formatear el código, también te lo desempaqueta cuando este ha sido generado mediante la herramienta packer, o la herramienta sqlformat que te genera un output de SQL no solamente formateado y con sintaxis coloreada sino que también te puede generar un output de SQL que generalmente colocamos en una variable String dentro de nuestro lenguaje de programación, así como lo ilustra la siguiente imagen:

"Sqlformat, indentando correctamente un procedimiento almacenado generando un output a manera de StringBuffer para ser utilizado en una clase Java (Click para agrandar)"

Algún otro que ustedes utilicen para formatear su código fuente en línea?

Herramientas Online de Formato e Indentación de Código

Mas de alguna vez nos ha tocado revisar algún mensaje XML o JSON fuera de la oficina, donde no tenemos nuestras herramientas de desarrollo que tan agradablemente se encargan de formatear e indentar nuestros archivos para que podamos leerlos, analizarlos y encontrar posibles fallas en ellos. En estas ocasiones nos ha tocado manualmente estar partiendo el archivo en diferentes líneas y agregando sangrías para darle el formato adecuado y se nos vuelva más fácil su análisis

Si de casualidad nos encontramos en estas circunstancias pero tienen la bondad de contar con una conexión a Internet, pueden aprovechar algunas herramientas online que se encargan de formatear, colorear e indentar nuestros archivos de código fuente.

Hay muchos otros que no he listado acá por el hecho de que solamente colorean el código y considero mas útiles aquellos que además del syntax highlight también te agregan los respectivos espacios de tabulación.

XML:


"Captura de pantalla de xmlindent.com, formateando un xml de ejemplo (click para agrandar)"

JSON:


"Captura de pantalla de jsoneditor.net, quien te forma la estructura jerárquica de tu mensaje JSON"

Múltiples lenguajes de programación:


Cabe resaltar algunas características especiales que poseen algunas de estas herramientas como por ejemplo jsbeautifier además de formatear el código, también te lo desempaqueta cuando este ha sido generado mediante la herramienta packer, o la herramienta sqlformat que te genera un output de SQL no solamente formateado y con sintaxis coloreada sino que también te puede generar un output de SQL que generalmente colocamos en una variable String dentro de nuestro lenguaje de programación, así como lo ilustra la siguiente imagen:

"Sqlformat, indentando correctamente un procedimiento almacenado generando un output a manera de StringBuffer para ser utilizado en una clase Java (Click para agrandar)"

Algún otro que ustedes utilicen para formatear su código fuente en línea?

miércoles, septiembre 02, 2009

¿Qué es ORM?

Object Relational Mapping, u ORM, O/RM y O/R mapping, es una técnica empleada en la programación, para convertir datos entre sistemas incompatibles, como lo son las bases de datos relacionales y los lenguajes de programación. Esta conversión de datos entre los sistemas crea un efecto una base de datos virtual de objetos, que puede ser usada en el programa (en esa forma).



Hay implementaciones comerciales y libres disponibles para crear el "mapeo" (mapping) objeto-relación, aunque algunos programadores (o mejor dicho empresas) optan (por ignorancia o espiritu de aventura... o ambas quizas) por crear sus propias herramientas ORM.


Las empresas siempre poseerán una base de datos normalizada, para "ahorrar espacio" (como algunos individuos administrativos lo ven). Para un programador, la tarea de leer estos datos, manipularlos y finalmente modificarlos o eliminarlos pende de un hilo, de acuerdo al grado de ignorancia a la hora de elegir a las herramientas y/o librerías de software (de ORM) empleadas para tales fines.


Una librería de ORM (como Hibernate, Oracle Toplink o Linq) siempre, absolutamente siempre reducirá la cantidad de código, porque habrá algo que permitirá realizar el proceso de mapeo (como el IDE), y se encargara de crear las clases equivalente u homologas con las tablas en la base, además permitirá manejar diversos tipos de relaciones entre las tablas (uno a uno,
uno a muchos, etc), reducirá la cantidad de defectos en esta delicada area, y todo esto, para beneficio del programador, que se concentrara más en codificar la lógica del negocio, que en hacer "INSERT", "UPDATE", "DELETE" y "SELECT" en la base. Otra razón por la que una librería ORM reduce la cantidad de código, es porque permite centralizar los procesos de búsqueda de datos en la base, liberándonos de escribir consultas ad-hoc innecesarias o "quemadas" en el código. Sin mencionar que, también gestionara el pool de conexiones a la base de datos.
Todo para que el programador, no se convierta en un esclavo codificando algo que ya existe, ustedes ya saben que en una empresa el codigo es el enemigo... y que de nada sirve estar reinventando la rueda...



Queda en claro, que una librería ORM, generara el mapeo de tablas a clases de base de datos (que esperamos que este BIEN diseñada) de una forma completamente automatizada. Netbeans por ejemplo, posee una excelente integración con JPA usando Oracle TopLink, y genera el código necesario para manipular toda la información de la base, en menos de un minuto... para 42 (cuarenta y dos) tablas.

¿Me pregunto cuanto se podría tardar una persona, haciendo el proceso a "pie"?

Si estas en un proyecto de software, en el que NO te permiten emplear librerías para ORM, eso simplemente refleja la ignorancia de tus inmediatos superiores o de los encargados de tu proyecto. Si ya tienes algo que te asista en el proceso, bien por ti!, pero deberías de estar pensando en emplear herramientas que son prácticamente el estándar de la industria (Hibernate), de comprobado rendimiento (Oracle Toplink) y que existen, para que nadie tenga que codificar como esclavo, algo que se puede generar en un par de clics y en no mas de "cien segundos".
ORM esta, para facilitar la vida de los programadores, reducir a la mínima expresión un proceso que es terriblemente tedioso, y también, para mejorar y producir mejor software.


¿Cuantos de ustedes utilizan tecnologías ORM en su trabajo o en la Universidad para proyectos de software?

Más información sobre ORM en la Wikipedia.

¿Qué es ORM?

Object Relational Mapping, u ORM, O/RM y O/R mapping, es una técnica empleada en la programación, para convertir datos entre sistemas incompatibles, como lo son las bases de datos relacionales y los lenguajes de programación. Esta conversión de datos entre los sistemas crea un efecto una base de datos virtual de objetos, que puede ser usada en el programa (en esa forma).



Hay implementaciones comerciales y libres disponibles para crear el "mapeo" (mapping) objeto-relación, aunque algunos programadores (o mejor dicho empresas) optan (por ignorancia o espiritu de aventura... o ambas quizas) por crear sus propias herramientas ORM.


Las empresas siempre poseerán una base de datos normalizada, para "ahorrar espacio" (como algunos individuos administrativos lo ven). Para un programador, la tarea de leer estos datos, manipularlos y finalmente modificarlos o eliminarlos pende de un hilo, de acuerdo al grado de ignorancia a la hora de elegir a las herramientas y/o librerías de software (de ORM) empleadas para tales fines.


Una librería de ORM (como Hibernate, Oracle Toplink o Linq) siempre, absolutamente siempre reducirá la cantidad de código, porque habrá algo que permitirá realizar el proceso de mapeo (como el IDE), y se encargara de crear las clases equivalente u homologas con las tablas en la base, además permitirá manejar diversos tipos de relaciones entre las tablas (uno a uno,
uno a muchos, etc), reducirá la cantidad de defectos en esta delicada area, y todo esto, para beneficio del programador, que se concentrara más en codificar la lógica del negocio, que en hacer "INSERT", "UPDATE", "DELETE" y "SELECT" en la base. Otra razón por la que una librería ORM reduce la cantidad de código, es porque permite centralizar los procesos de búsqueda de datos en la base, liberándonos de escribir consultas ad-hoc innecesarias o "quemadas" en el código. Sin mencionar que, también gestionara el pool de conexiones a la base de datos.
Todo para que el programador, no se convierta en un esclavo codificando algo que ya existe, ustedes ya saben que en una empresa el codigo es el enemigo... y que de nada sirve estar reinventando la rueda...



Queda en claro, que una librería ORM, generara el mapeo de tablas a clases de base de datos (que esperamos que este BIEN diseñada) de una forma completamente automatizada. Netbeans por ejemplo, posee una excelente integración con JPA usando Oracle TopLink, y genera el código necesario para manipular toda la información de la base, en menos de un minuto... para 42 (cuarenta y dos) tablas.

¿Me pregunto cuanto se podría tardar una persona, haciendo el proceso a "pie"?

Si estas en un proyecto de software, en el que NO te permiten emplear librerías para ORM, eso simplemente refleja la ignorancia de tus inmediatos superiores o de los encargados de tu proyecto. Si ya tienes algo que te asista en el proceso, bien por ti!, pero deberías de estar pensando en emplear herramientas que son prácticamente el estándar de la industria (Hibernate), de comprobado rendimiento (Oracle Toplink) y que existen, para que nadie tenga que codificar como esclavo, algo que se puede generar en un par de clics y en no mas de "cien segundos".
ORM esta, para facilitar la vida de los programadores, reducir a la mínima expresión un proceso que es terriblemente tedioso, y también, para mejorar y producir mejor software.


¿Cuantos de ustedes utilizan tecnologías ORM en su trabajo o en la Universidad para proyectos de software?

Más información sobre ORM en la Wikipedia.

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...