El justiciero que llevamos dentro

A finales del pasado mes leí un artículo de Raúl Morales titulado “Proponen nodos suicidas para proteger las redes de los hackers”. En él se comentaba la propuesta de la Universidad de Cambridge para la protección de redes descentralizadas o distribuidas: permitir a cualquier nodo de una red terminar con un nodo considerado malo con la contrapartida de que el nodo “ejecutor” se vea obligado a “suicidarse” (desconectarse) como justificación al acto de “eliminación” de ese nodo malo (en pocas palabras, doy mi vida por el bien común).

Hay que remarcar que se trata de una propuesta, y claro, para eso estamos los “chicos” de Security Art Work, para sacarle punta a (casi) todo. Teniendo eso muy en cuenta, ¿qué soporte tiene esta propuesta? ¿No nos lleva a sacar al justiciero que llevamos dentro?

Puesto que los investigadores de Cambridge se basan en la naturaleza para establecer este mecanismo de autodefensa (las abejas atacan con su aguijón perdiendo con ello la vida), se puede establecer como hipótesis de trabajo el argumento contrario basado en la naturaleza humana, por ejemplo, los terroristas suicidas. Al otorgarse total derecho a eliminar nodos malignos sin otro fundamento legal que la obligación de desconectar nuestro propio nodo, esta medida podría utilizarse por parte de grupos criminales con gran capacidad para establecer nodos “nacidos para el suicidio”, de manera que, al amparo de esta propuesta, se dediquen a destruir con carta blanca nodos que realmente no tienen actividad sospechosa o delictiva.

Por otro lado, de sobra es conocida la existencia de mecanismos reguladores para la obtención de licencias de armas, en los que se deben pasar exámenes médicos y psicológicos que ratifiquen nuestra capacitación. Si la libertad de agredir a otro nodo está al alcance de la mano de cualquiera, por muy loable que sea el fin de esta acción, podremos llegar al caso de nodos de “gatillo fácil”, es decir, nodos que no estén lo suficientemente preparados o entrenados para distinguir patrones de ataques que en algunos casos puedan tratarse de falsos positivos (mi nodo pensó que el tuyo era maligno).

Tanto por el hecho de dejar una puerta a la impunidad, como por la capacidad de no estar lo suficientemente preparados para tomar la decisión correcta, considero que debe dejarse en manos de los profesionales la investigación y análisis de las actividades que puedan considerarse delictivas en el entorno de la red, y no delegarla en mecanismos semiautomáticos que pueden fallar o ser utilizados con fines poco dudusos. Porque para ello ya existen las Brigadas de Delitos Informáticos de los distintos Cuerpos de Seguridad del Estado.

En seguridad informática o en cualquier otro aspecto de la vida, más vale prevenir que curar.

El riesgo de la movilidad

Se habla cada día más de la seguridad —o inseguridad— relacionada con los dispositivos móviles que todos, en mayor menor medida, llevamos con nosotros en nuestro día a día. Sin duda, nos encontramos ante uno de los principales quebraderos de cabeza que en la actualidad comparten todos los responsables de seguridad, y previsiblemente seguirá siéndolo a medio plazo. Y aunque la amenaza no es nueva, conforme avanza la tecnología aumentan el riesgo y el impacto asociados a ella. Un ejemplo: si hace unos años, lo que podíamos perder (o lo que nos podían robar) era una agenda (de papel, de las de toda la vida), un bloc de notas o, a lo sumo, un par de diskettes, hoy podemos perder gigas de información en un simple lápiz de memoria USB, una detallada agenda electrónica con nuestros contactos, o incluso el portátil en el que tenemos almacenado todo nuestro trabajo.

Nadie pone en duda los beneficios que introducen en nuestro trabajo diario este tipo de dispositivos, pero igualmente nadie pone en duda los problemas de seguridad que nos pueden acarrear; ninguno de nosotros está exento de perder uno de estos gadgets (o chismes, en una posible acepción castellana), así que es imprescindible implantar controles que, en caso de robo o pérdida, minimicen el impacto para la organización. Para empezar, una buena salvaguarda es la definición de procedimientos, normativas, políticas o como les queramos llamar, para regular el uso de estos dispositivos. Estas normas deben marcar el tipo de datos que podemos almacenar en los mismos, las medidas de prevención básicas para evitar un compromiso (robo, pérdida o ataque), los pasos a seguir si dicho compromiso se produce, etc. Además, una medida técnica siempre recomendable es el cifrado de los datos almacenados: se trata de una medida barata y efectiva, que todos deberíamos implantar.

Antes de acabar, un ejercicio sencillo. Marque cada uno, mentalmente, los dispositivos que lleve consigo en su trabajo diario:

— Teléfono móvil.
— PDA.
— Ordenador portátil.
— Memorias USB.
— Tarjetas inteligentes.

Ahora piense en la información almacenada en cada uno de estos dispositivos, o en los privilegios que otorgan… y en qué sucedería si perdiera cada uno de ellos, o si se los robaran. Es como para tomarlo en serio, ¿verdad?

Saludos, Profesor Falken

«Saludos Profesor Falken, ¿le apetece una partidita de ajedrez?»

Muchos de los lectores de este blog recordarán esta mítica frase de la película Juegos de Guerra, película de culto para todos los apasionados de las nuevas tecnologías. Fue en esta película, siendo apenas un niño, en la que oí por primera vez el término PUERTA TRASERA, cuando los dos programadores amigos del protagonista le desvelan que suelen ocultar en el código puertas traseras para poder acceder a los sistemas posteriormente a su entrega.

Evidentemente, la posibilidad de que software que controla infraestructuras tan críticas como el lanzamiento de misiles pueda contener puertas traseras es aterradora, y más aún si el acceso está protegido por una contraseña como “Joshua” (¿y por qué no “patata”? Falken, te lo has currado…). Lamentablemente el riesgo existe, ya que los programadores siguen teniendo la costumbre de dejarse algún tipo de acceso oculto que queda fuera del control de los administradores de sistema que les permita entrar en caso de necesidad.

juegosdeguerra.jpgAunque esté lejos de controlar un lanzamiento de misiles (espero), esta reflexión viene al hilo de una serie de acusaciones realizadas desde ciertos entornos que indican que Microsoft podría tener algún tipo de puerta trasera oculta en el código del Windows Update.

¿Y si fuera cierto? Evidentemente sería un problema muy serio de seguridad, porque querría decir que cualquier empleado de Microsoft (o servicio de inteligencia, o hacker particular que haya descubierto la puerta oculta como sucede en Juegos de Guerra) podría acceder en cualquier momento a los equipos de un gran número de personas y robar información, contraseñas, accesos a otros sistemas no-Microsoft y en definitiva vulnerar completamente la seguridad de un particular, organización o incluso de un país.

¿Es posible detectar estos usos? Lamentablemente es una tarea bastante complicada, sobretodo tratándose de Software propietario, ya que no permite que podemos auditar el código para saber que hace exactamente. A nivel de red también es complicado detectar este tráfico, ya que puede estar oculto en tráfico habitual en el funcionamiento del sistema operativo, resultando difícilmente reconocible (Un “ALT” de un tag “IMG” que cambie al visitar la web de Windows Update para realizar las actualizaciones puede contener instrucciones codificadas, o pueden existir instrucciones codificadas en el propio paquete de actualización). De hecho incluso auditando el código puede ser difícil de detectar, puesto que la puerta trasera puede estar basada en vulnerabilidades dejadas en el código a propósito para poder ser explotadas a posteriori y entrar así en los sistemas.

Otra opción es recurrir a los controles de índole legal, pero eso no va a proteger realmente nuestra información, y menos aún si la fuga de información ha sido producida debido a un “lamentable error” en forma de vulnerabilidad en el desarrollo del software.

Visto lo visto, parece que los usuarios de software propietario tendrán que adoptar una política de “confianza” con su proveedor de software, al igual que lo hacemos muchos de nosotros diariamente con nuestro mecánico, fontanero, etc, y al igual que con ellos, confiar en su profesionalidad y en su buena fe.

¿Más alternativas?
Yo, LINUX. ¿Y ustedes?

[Actualización a posteriori: Kritópolis reporta esta noticia que procede de Cryptome, que es cuanto menos sospechosa. Pero, ¿dónde acaban las sospechas y comienzan la paranoia y las teorías conspiratorias?]

(Having fun with) Internet Explorer & PDF

Desde hace unos meses se están publicando una serie de vulnerabilidades que afectan a los navegadores web más utilizados, Internet Explorer, Firefox, etc., convirtiéndose en un vector de ataque nuevo de gran peligrosidad para cualquier usuario u organización. En el siguiente video pueden ver un ejemplo donde se explota una vulnerabilidad que afecta a Internet Explorer y Adobe Acrobat Reader:

[Vía raffon.net. Versión de mayor calidad (wmv) aquí]

Después de ver el video, ¿no se les ponen los pelos de punta? Espero que sí, porque si es así han comprendido la peligrosidad de este tipo de vulnerabilidades. ¿Cuántas veces hemos descargado un pdf de alguna página web y lo hemos ejecutado (abierto) en nuestra máquina? Cientas, miles, millones (quizá no tantas)…

Con esta acción tan corriente podrá alojarse en nuestra máquina un troyano, virus, malware, spyware, keylogger, o cualquier otro especímen de esta variada fauna. ¿Se imaginan lo fácil que podría ser para un atacante enviarse a una cuenta de correo todas las contraseñas tecleadas por usted mediante un simple keylogger y obtener acceso a datos privilegiados? Y todo eso simplemente consiguiendo que se baje un pdf y lo abra en su máquina…

Si al llegar a este punto, tienen una leve sensación de inseguridad, no se preocupen, no es cuestión de ser alarmistas, sólo prudentes; con unas pautas sencillas es posible reducir (que no eliminar) sensiblemente el riesgo que corremos debido a este tipo concreto de vulnerabilidades (claro que todo depende de la aversión al riesgo que cada uno tenga):

1.- Tener el sistema operativo actualizado, con los últimos parches de seguridad que ofrezca el fabricante aplicados. A causa de que suele existir cierto retraso en la publicación de parches oficiales por parte de los fabricantes desde que una vulnerabilidad se hace pública hasta que ésta se “consuma”, este punto no es garantía “de estar a salvo” al 100%. En el caso concreto de Microsoft Windows la latencia en publicar parches suele ser considerable, por lo que pueden haber periodos en los que que pese a disponer de todas las actualizaciones seguimos siendo vulnerables.

2.- Tener las aplicaciones actualizadas (Adobe Reader, Máquina Virtual de Java, etc), haciendo especial énfasis en aquellas aplicaciones integradas en los navegadores.

3.- Asegurarnos de que las fuentes desde donde nos descargamos contenidos sean lo más fiables posibles.

4.- Tener el antivirus instalado y actualizado.

Todas estas medidas son preventivas, pero siempre puede escaparse a nuestro control por distintos motivos, por lo que les aconsejo que tengan mucho cuidado y hagan especial hincapié en la tercera medida, ya que como en muchas otras cosas, el factor humano es el más importante. Nada más. Ya saben, “naveguen con libertad, y precaución”

Información versus inteligencia

En su página de preguntas frecuentes, el CNI nos ilustra acerca de la diferencia entre información e inteligencia:

«El término información debe diferenciarse del de inteligencia. Información equivale a noticia de un hecho en su sentido más amplio. El concepto información debe entenderse, por tanto, como el elemento de partida para la elaboración de inteligencia, considerada ésta como el resultado de valorar, analizar, integrar e interpretar la información.»

Actualización (a 5 de octubre): casualmente (o no), ni el enlace original ni la versión cacheada por Google funcionan ya… ¡Pero no todo está perdido!

Actualización (a 31 de octubre): Ahora sí, todo está ya perdido.

Bichos et al. (II): ¿Malware indetectable?

(Después de algún tiempo de ausencia, y aprovechando que está de vacaciones, José Selvi nos trae la segunda parte de “Bichos et al” que tuvo su primera parte en una fecha tan lejana como el 13 de junio.)

En la anterior entrega de esta serie de artículos relacionados con el software malicioso hablabamos de las dificultades que tenían los sistemas antivirus para detectar software malicioso desconocido, es decir, aquel sobre el cual no han podido trabajar y por tanto extraer las firmas adecuadas para su detección. Para solventar estas deficiencias, comentábamos que los desarrolladores de sistemas antivirus dotaban a sus producto de capacidades heurísticas de detección, con el fin de identificar virus desconocidos a partir de partes de su código o de su comportamiento.

Etimológicamente, la palabra “Heurística” es derivada de la palabra Eureka (¡Lo encontré!), por lo que la palabra Heurística significa, ni más ni menos, encontrar una solución a algo. Con un significado tan amplio como este, como se pueden imaginar, es lógico pensar que cada fabricante de sistemas antivirus puede haber optado por soluciones muy diferentes a la hora de implementar sus sistema heurístico, de ahí los diferentes resultados que muestran cada uno de ellos a la hora de realizar pruebas sobre dicho sistema.

bichos2.jpgEn general, podemos aproximar la problemática de detección heurística de software malicioso a un sistema de reconocimiento automático de patrones, similar al empleado por los sistemas antispam. De esta manera, dado un elemento a analizar, se extraerían N características a considerar, con sus valores correspondientes, definiendo por tanto para este elemento un punto en un espacio N-dimensional de elementos analizados. Si la heurística seleccionada fuera lo suficientemente adecuada, observariamos agrupaciones de elementos en este espacio, tal y como se puede apreciar en la gráfica.

Por lo tanto, una heurística que nos ofreciera un resultado como el aquí mostrado, nos permitiría una detección heurística de software malicioso de una alta efectividad. La efectividad viene determinada, por tanto, por la adecuidad o no de las características seleccionadas y los pesos otorgadas a cada una de ellas, siendo fundamentalmente éste el punto diferencial en las diferentes opciones de implementación de los métodos heurísticos.

¿Es sencilla la selección de características? La respuesta es no, y de hecho en la mayoría de los casos, la gráfica muestra un solapamiento importante entre muestras de software malicioso y muestras de software legítimo, lo que dificulta su detección.

Como contramedida a esta deficiencia, algunos fabricantes ofrecen información al usuario para que sea él mismo quien valore la categorización que darle a un software que se encuentre en una zona de incertidumbre heurística, pero no suele resultar muy efectivo, dado que los usuarios tienden a aceptar sistemáticamente, sin apenas leer la información que se les proporciona, todos los mensajes que se les muestran por pantalla, y aunque decidieran leerlos, la gran mayoría de ellos no dispondrían de los conocimientos técnicos necesarios para valorar el tratamiento que se le debe dar al software.

Ahora, tras toda esta introducción teórica sobre reconocimiento de patrones, tomemos un ejemplo: ¿Qué efectividad tendría un sistema antispam para discriminar el correo electrónico no deseado de un directivo de una empresa de productos farmaceuticos que comercializa fármacos que potencian el apetito sexual (sin citar una marca concreta)? ¿Serían realmente lo suficientemente diferentes los correos legítimos de cierto tipo de correos no deseados como para que estos fueran distinguidos de forma automática?

Ahora traslademos esto a la detección de software malicioso: ¿Qué efectividad tendrá un sistema antivirus para detectar un software malicioso no documentado y que está especialmente diseñado para camuflarse como software legítimo? ¿Sería posible diseñar un software malicioso que resultase indetectable de forma automática?.

Para la última de las entregas de esta serie de artículos se planteará un escenario de ataque en el cual podría utilizarse una prueba de concepto de software maliciso especialmente diseñado para no ser detectado por los sistemas antivirus. Mediante el uso de esta prueba de concepto descubriremos que tal responden diversos productos antivirus a un ataque dirigido como el que aquí se plantea. Mientras tanto, que nadie desinstale todavía sus antivirus, esperen a ver la conclusión final…

Bien por la FIA

Como probablemente muchos de ustedes saben, hay un buen follón montado en la Formula 1. Resumiendo, y ciñéndome a la versión “oficial”, ciertas personas del equipo McLaren estuvieron durante un tiempo recibiendo información confidencial de Ferrari. Después de muchas vueltas, eso desembocó en algo parecido a un juicio que tuvo lugar el pasado 13 de septiembre, que vino a denominarse “Extraordinary Meeting of the World Motor Sport Council“, y en el que los principales implicados en la trama del espionaje dieron sus versiones ante la FIA (Federation Internationale de l’Automobile, Federación Internacional de Automovilismo) y respondieron a preguntas de abogados de una y otra parte. Finalmente, el tema se resolvió con la exclusión de McLaren del campeonato de constructores del presente año y una multa de 100$ millones.

Hace unos días, dicha organización, responsable entre otras cosas del Mundial de Rallies y de la Formula 1, decidió que hoy miércoles se publicaría la transcripción de dicha reunión, algo que había generado bastante expectación por la sanción y por otras razones que no vienen al caso. La cuestión es que sobre las 12 p.m., la transcripción (de 115 páginas) se publicó, como estaba previsto, en la página web de la FIA, con diferentes partes del texto cubiertas de negro, conteniendo presumiblemente información confidencial sobre mecánicas de Ferrari y McLaren.

Poco después, dicha transcripción dejó de estar disponible, y volvió a estarlo unas horas más tarde, pero ahora los segmentos en negro estaban en blanco. Aunque todo esto les pueda parecer interesante, estarán pensando qué tiene que ver exactamente con la seguridad de la información.

Pues bien. Seleccionando el texto “oculto” de la transcripción original, copiándolo y pegándolo en el bloc de notas, se puede ver qué era exactamente eso que quería ocultar la FIA. Bien por ellos.

Ya tenemos antivirus… estamos salvados.

El pasado sábado la versión electrónica del periódico local valenciano Levante EMV daba la noticia de que un virus había causado el caos en la Escuela Oficial de Idiomas de Valencia. Al parecer, y según el diario, éste «provocó que las citaciones con el mismo número se duplicaran e incluso se triplicaran en algún caso». No niego que, aún desconociendo la aplicación y el procedimiento de citación, me parece sumamente interesante que un virus pueda actuar de forma tan “inteligente” y llegue a ese nivel de interacción con los datos, pero dejando polémicas, suspicacias y sospechas aparte, la cuestión es que me da la sensación, y entramos en el terreno de la opinión personal, de que para el público en general, y no tan general, los virus suelen residir en un universo independiente al del concepto “puro” de seguridad.

Es decir, que mientras éste parece estar más relacionado con grandes corporaciones, con hackers y crackers, intrusiones, robo de información privilegiada, IDSs, análisis forense, cortafuegos o gestión de contraseñas, los virus, troyanos, gusanos, spam y demás fauna relacionada son una molestia perrmanente y casi necesaria, fácilmente solventable con un antivirus y algún programa de malware. Parece, como digo, que políticas, procedimientos, y todas aquellas medidas típicas de un entorno seguro, orientado a evitar —mitigar— los riesgos relacionados con la seguridad de la información, están “de más” cuando se trata de controlar a estos no siempre pequeños y nunca inofensivos “bichos”. Vamos, resumiendo, que en ese caso no son necesarias.

Desgraciadamente, las cosas no funcionan exactamente así. No sólo es mucho más probable sufrir una infección vírica masiva que sufrir una intrusión o un ataque DoS por alguna banda criminal de Europa del Este (por no salirme de los tópicos), sino que las consecuencias pueden ser igualmente fatales. Y es que aparte de un siempre necesario antivirus, actualizado periódicamente e inmune a las manipulaciones del usuario más molesto, son imprescindibles políticas que gestionen los privilegios de acceso a los recursos compartidos, el control de acceso a los dispositivos, la gestión de permisos y usuarios, las políticas de uso de soportes como USBs, CDs o DVDs,… Y como siempre, es necesaria la concienciación del usuario. Porque las fotos de la última convención no siempre son las fotos de la última convención: las cosas no son siempre lo que parecen aunque a menudo lo descubrimos un poco tarde.

Todo sea, al menos, por no ver aparecer por la puerta de la empresa a doscientas personas pidiendo matricularse en clase de mandarín, ¿no les parece?

Ataques de Inyección SQL (III)

Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad “for educational purposes only” aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

En primer lugar, destaca Sqlninja como detector de vulnerabilidades de Injección SQL en servidores basados en Microsoft SQL Server. Esta herramienta es capaz de lanzar diversos exploits que atacan directamente al gestor de base de datos demostrando el grado de seguridad y hasta qué punto puede quedar nuestro servicio comprometido. Es una herramienta muy completa y fácil de utilizar, y cuenta con menus que resultan bastante intuitivos.

Absinthe es otra aplicación de fácil manejo, y que cuenta con interfaz gráfica de usuario, que destaca por la sencillez y rapidez a la hora de parametrizar una auditoría. Admite auditorías sobre varios gestores de bases de datos, como pueden ser Postgres, MySQL, MS SQL, etc…

SQL Power Injector es otra aplicación completísima desarrollada con el lenguaje C# bajo la plataforma de desarrollo de .NET. La interfaz gráfica posibilita realizar una auditoría de forma rápida e intuitiva. Es válida para varios gestores de bases de datos.

Más que una aplicación, SQLIer puede considerarse un script que utiliza un ataque de tipo verdadero-falso para determinar usuario y contraseñas de las bases de datos. Es por tanto un script a nivel informativo, con el que se pueden determinar la fortaleza de las contraseñas utilizadas y el grado de defensa contra ataques de este tipo.

Por último, SQL Injection Pentesting TooL es otra utilidad con interfaz de usuario muy completa para la realización de auditorías. Aunque a diferencia de las anteriores en este caso no se dispone del código fuente de la aplicación, y únicamente se puede ejecutar bajo entornos Windows, su descarga es totalmente gratuita.

Como es habitual, desgraciadamente nada es perfecto y a pesar de las facilidades que estas herramientas introducen, será necesario auditar de forma manual todas las implicaciones que conlleva todo lo relacionado con la conexión, acceso y tratamiento de la base de datos. Por poner un ejemplo, en Java se deberían buscar todas las llamadas execute(), prepareStatement() y prepareCall(), y hacer una traza de las mismas. El uso combinado de estos dos tipos de auditorías, la realizada de forma manual y la automática a través de las aplicaciones mencionadas, nos ayudarán a filtrar todos aquellos “bugs” no tratados durante el proceso de codificación de la aplicación, obteniendo así una aplicación relativamente protegida frente a estos ataques de Inyección SQL.

Y de momento, esto es todo. Como suele decirse, to be continued

Ataques de Inyección SQL (II)

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Sea la siguiente sentencia para mostrar el perfil de un determinado usuario en una página web:

SELECT * FROM users WHERE name = '"+ userName +"';

El atacante manipula la sentencia de esta manera…

SELECT * FROM users WHERE name = 'a' or 't'='t';

(En rojo y negritas, código inyectado por el atacante)

Mientras que la sentencia anterior debería mostrar las características de un único usuario, al incrustar el atacante un operador “or” con una condición que siempre es cierta, consigue que la sentencia sea cierta para todos los usuarios, devolviendo la base de datos por tanto todos los datos de la tabla users.

Como medida de seguridad, los distintos entornos de programación poseen ciertas funciones en las que se revisa estos tipos de entrada para evitar que lleguen a la base de datos. Por poner algunos ejemplos, en PHP por ejemplo existe la función mysql_real_escape_string para MySQL, en JAVA tenemos la función PreparedStatement, en Mono y C# de .NET se trata con las funciones SqlCommand (para Microsoft SQL Server) y OracleCommand (para gestores Oracle). De esta forma, si validamos tanto las entradas de primer orden como las de segundo, es decir, no sólo los posts, gets, cookies, sino también las que provienen de lectura de ficheros, bases de datos, etc… conseguimos filtrar instrucciones no deseadas, errores por tipos de datos, y manejo de tablas de la base de datos.

Como complemento de la seguridad en la aplicación, es recomendable generar las consultas de forma estática en la medida de lo posible, es decir, si predefinimos las consultas obligaremos al usuario de la aplicación únicamente a interactuar con los parámetros, por lo que no existe la posibilidad de que éste modifique las sentencias.

Hay muchas otras recomendaciones, como por ejemplo no acceder a la base de datos desde la aplicación con una cuenta de usuarios con privilegios de administrador, o hacer un uso restringido y controlado de los llamados “procedimientos almacenados”, pero de eso hablaremos en la tercera parte de esta serie.