Pescando…

Imagino que la mayoría de ustedes conocen el sistema de mensajería instantánea Microsoft MSN. Seguramente sabrán también que puede uno cambiar el nombre o «nick» con el que le «ven» los demás, que es posible «bloquear» a otros usuarios de manera que para ellos aparezcas a todos los efectos desconectado y no puedan hablar contigo, y que el MSN y la cuenta de correo de Hotmail comparten el identificador de usuario y la contraseña. Dicho esto, hace unas semanas, mi novia —que comprueba que no la estoy mirando cada vez que introduce su contraseña de correo, a pesar de que lo consulta desde mi portátil— me saludó una mañana con el siguiente mensaje como nombre:

«www.QuienTeAdmite.com < -- Fijate quien te elimino y quien te desadmitio en el MSN, enterate TODO"

Aunque ya había visto eso antes, en este caso indagué un poco y llegué a sitios web como www.quienteadmite.com o blockoo.com, aunque hay muchas más, en las que aseguran que proporcionando el usuario de Hotmail y la contraseña, muestran qué personas tienen «bloqueado» a tu usuario en el MSN. Pese a que el método de proporcionar tu usuario y contraseña puede considerarse cuanto menos sospechoso y nada recomendable, no voy a entrar a cuestionar hasta qué punto el sistema funciona o no. Cabe decir, no obstante, que incluso aunque funcionase, eso no elimina los riesgos de «regalar» libremente el acceso a tu correo personal.

Lo que me llama la atención es que a pesar de que las «víctimas» de este tipo de iniciativas son por lo general usuarios experimentados de Internet (menores de treinta años) que conocen o deberían conocer los —a menudo exagerados— «peligros» de este medio, acaban confiando en una página web sin ninguna garantía que les pide su usuario y contraseña de correo personal. Lo que en mi opinión demuestra que, teniendo en cuenta que en gran parte de las relaciones a través de MSN la amistad y la confianza tienen un papel importante (y que el hecho de que una persona bloquee a otra se considera una afrenta relativamente seria), sólo hay que buscar el reclamo adecuado para que cualquier persona, en cualquier momento, revele información personal a extraños o sitios web desconocidos.

No me sorprende, por tanto, que el phishing funcione, y como es habitual, aunque no voy a aconsejarles que como suele decirse, no se fíen ni de su padre, cuando se trate de asuntos privados —finanzas, correo privado, datos personales…—, desconfíen. Esa suele ser siempre una buena política.

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

Cuidado: cuando borra, no siempre borra

Si alguna vez piensa usted en sacar un dinerillo vendiendo ese ordenador, esa llave USB o ese disco duro cuya capacidad es ya irrisoria o que no le sirve de nada, acuérdese de borrar los datos que contiene, porque con toda probabilidad, aparte del teléfono de su suegra o de su ex, no querrá que sus correos personales, las fotos de su pareja o los teléfonos de sus amigos acaben en manos de un desconocido, ¿verdad?

Y le digo esto porque, aunque no sea usted el gobernador de Arkansas, estoy seguro de que se aprecia sus datos tanto como él. Ah, y por si hay alguna duda, cuando hablo de «borrar», no quiero decir borrar. Quiero decir «hacer los datos irrecuperables».

Visto en Kriptópolis.

(Buen fin de semana a todos)

Escuchas telefónicas made in USA

Aunque no pensaba actualizar hasta mañana al menos, y no acostumbro a poner nada en inglés, no me he podido resistir a esto, que describe el impresionante y complejo sistema de escuchas telefónicas montado por el FBI, basado en un informe de cerca de mil hojas hecho público gracias a la Freedom of Information Act (FOIA) y destinado a la Electronic Frontier Foundation (EFF). Les recomiendo que vayan al artículo de Wired, mucho más completo y realmente interesante:

The FBI has quietly built a sophisticated, point-and-click surveillance system that performs instant wiretaps on almost any communications device, according to nearly a thousand pages of restricted documents newly released under the Freedom of Information Act.

The surveillance system, called DCSNet, for Digital Collection System Network, connects FBI wiretapping rooms to switches controlled by traditional land-line operators, internet-telephony providers and cellular companies. It is far more intricately woven into the nation’s telecom infrastructure than observers suspected.

It’s a «comprehensive wiretap system that intercepts wire-line phones, cellular phones, SMS and push-to-talk systems,» says Steven Bellovin, a Columbia University computer science professor and longtime surveillance expert.

DCSNet is a suite of software that collects, sifts and stores phone numbers, phone calls and text messages. The system directly connects FBI wiretapping outposts around the country to a far-reaching private communications network.

Visto en el blog de Bruce Schneier.

Asimetrías en las transacciones digitales futuras

El pasado mes de junio se aprobó la Ley de acceso electrónico de los ciudadanos a los Servicios Públicos, en la que se establece que la Administración no es que sólo «pueda», sino que «debe» ofrecer todos sus servicios de manera electrónica. Sin ninguna duda, esta ley acompaña de manera definitiva al DNI electronico, y a otras opciones de certificación digital como puede ser la ACCV. No hay ninguna duda de que todas estas iniciativas pueden mejorar en mucho los trámites de los ciudadanos, pero por otro lado abren una gran cantidad de incógnitas frente a las garantías que tienen los ciudadanos al realizar trámites de manera digital, entre las que queremos destacar la asimetría de las transacciones digitales en la presentación de la declaración de Hacienda.

Recientemente muchos contribuyentes han realizado su declaración de Hacienda de manera digital a través de Internet. El proceso de presentación telemático asociado tiene visos de ser bastante completo: los usuarios deben acreditarse para obtener su certificado digital (formado por una clave pública y una privada), y la clave privada es generada por el PC particular de cada uno, con lo que este certificado digital permite que el usuario «firme digitalmente» su declaración. Todo ello a traves de la Fábrica Nacional de Moneda y Timbre, una autoridad de certificación con en principio todas las garantías.

Hasta aquí, todo bien (en realidad, no esta bien «del todo» al ser un certificado software, pero la tecnología que le sucederá en breve como es el DNI digital, sí tiene características como para considerarse firma electrónica); el proceso en su conjunto parece que sigue técnicas en principio bastante robustas en cuanto a los aspectos de seguridad, tanto organizativa como técnicamente.

Ahora analicemos el proceso de presentación de la declaración: preparamos ésta con el programa PADRE y nos conectamos a la página web de Hacienda donde nos aparece un applet, mediante el cual firmamos digitalmente nuestra declaración, y puesto que la firma digital equivale a la firma manuscrita, esto constituye en última instancia el equivalente a la entrega de nuestra declaración firmada. Ahora sólo cabría esperar que Hacienda tambien nos firmara (o cuñara) nuestra declaración con la misma robustez como nosotros se la hemos firmado, mediante un documento firmado digitalmente por la Administración (por la aplicación) que justifique que hemos entregado nuestra declaración. No obstante, en su lugar lo unico que recibimos es un número de registro, no firmado digitalmente ni de ninguna manera: un simple número de serie.

Por ello la autentificación y firmado de la declaración se produce de una manera completamente asimétrica: mientras que el ciudadano se autentica con ciertas medidas criptográficas y de seguridad, el justificante que obtiene es técnicamente muy debil, y con evidentes riesgos sobre su validez en caso de problemas. Y esta es la principal razón de que año tras año no presente la declaración por Internet sino a través del banco, del que al menos recibo un documento cuñado por la oficina con el que demostrar que la he presentado en caso de presentarse problemas futuros, ya que este documento sellado es a mi entender bastante más robusto que un simple número.

Muchos de los lectores podrían pensar que el tema de la declaración no tiene al fin y al cabo demasiada importancia, y quizá tengan razón, ya que al fin y al cabo Hacienda también permite maneras poco robustas de aprobar borradores de declaración como puede ser a través de SMS o medios similares. Pero el problema reside en que es esta es la tecnología que viene, y esta es por tanto la asimetría con la que nos vamos a encontrar en los futuros desarrollos con firma digital, como por ejemplo el nuevo DNI; ¿se imaginan ustedes firmando un contrato con algun operador de Telecomunicaciones en el que el usuario firma el contrato digitalmente y el operador simplemente entrega una hoja para imprimir? No parece un procedimiento demasiado apropiado, ¿verdad?

A la vista de este tipo de problemas que van apareciendo, no cabe duda de que los usuarios tendremos que estar alerta ante las futuras transacciones basadas en firma digital, que seguro que con el nuevo DNI electrónico van a comenzar a surgir.

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.

Security Theater

No sé si conocen el concepto de «Security Theater», y permítanme que no traduzca la expresión. La idea, acuñada por Bruce Schneier, viene a representar la presencia de medidas de seguridad que aportan poca o nula protección, pero por contra son publicitadas ostensiblemente dando una falsa sensación de seguridad. De ahí la combinación de «seguridad» con «teatro». Por ejemplo, hace unos días Bruce Schneier puso en su blog un caso que estoy seguro de que se repite en otros lugares: nadie vigila las 178 cámaras de seguridad de San Francisco, y en varios casos en los que diversos crímenes se realizaron frente a ellas, estaban incorrectamente orientadas. Por si esto no fuese suficiente, al parecer la visión «nocturna» es de ínfima calidad, lo que resta validez a las grabaciones. Por supuesto, como todo, este concepto tiene un efecto positivo, y uno negativo.

Empecemos por el segundo. En el caso mencionado, el ciudadano mira, y más allá de consideraciones de privacidad, ve las cámaras que le observan y en cierto modo, se siente seguro, protegido. Sin embargo, su sensación es simplemente una ilusión. Y eso le puede llevar a realizar acciones y correr riesgos que de otro modo no correría; no cambiarse de acera al cruzarse con alguien «sospechoso», por ejemplo. Otro efecto negativo de estas instalaciones, sobre todo a partir del 11S, es la limitación de la libertad de las personas, sobre todo al otro lado del charco; con toda probabilidad muchas de las medidas de seguridad que se aplican en los aeropuertos contra ataques terroristas son inútiles, a causa de la complejidad y tamaño de éste, pero sirven como excusa para coartar la libertar y privacidad de las personas, y generar una falsa sensación de miedo en la persona; que esta consecuencia sea intencionada o un producto de la incompetencia administrativa es algo que no voy a entrar a considerar.

Como aspectos positivos, los security theaters tienen la facultad de actuar, siempre que el criminal no conozca la realidad de las medidas de seguridad, como algo parecido a los espantapájaros: al generar esta falsa sensación de seguridad, impiden que los criminales se sientan seguros para llevar a cabo sus planes. Siguiendo con el ejemplo anterior, la presencia de una cámara de vigilancia puede disuadir al delincuente de atracar a alguien. Otro ejemplo, más allá de la seguridad personal, son los sistemas antirrobo que hay a las puertas de muchas tiendas pequeñas; la mayoría hemos visto alguna vez el sistema de alarma sonando mientras alguien sale de la tienda, pero la mayor parte de las veces, no sucede nada. No hay guardas de seguridad, ningún dependiente sale a mirar, nada; la persona se gira, hace una mueca extraña de sorpresa o sonrojo, y sigue su camino sin que nadie le diga nada o le detenga. A pesar de ello, pueden apostar a que mucha gente que se siente tentada a realizar pequeños hurtos abandona la idea a causa de estos sistemas.

En la misma línea, hoy leía en El Economista que el Departamento de Homeland Security (DHS) de los EEUU está desarrollando un nuevo sistema de seguridad a implantar en los aeropuertos, que se basa en estudiar a distancia todos los indicadores corporales de una persona para conseguir «adivinar» si tiene intención de atentar o no; había leído antes sobre esto, pero no recuerdo donde. Hace poco, un niño de siete años y su familia pasaron un mal trago por la simple cuestión de llamarse éste igual que un paquistaní deportado (Javail Iqbal) por los EEUU [elmundo.es]. Y el mes pasado, salió a la luz que el aeropuerto de Phoenix pasaba 4,5 horas totalmente desatendido en materia de seguridad (ver también el comentario de Bruce Schneier, que entra además en otras consideraciones). Así que pienso que hay cuestiones más importantes a considerar —y solucionar— que este tipo de tecnologías invasivas y casi de ciencia ficción.

Aunque por supuesto, en un cierto sentido paranoico, una cuestión adicional a considerar en algunos de estos security theaters que les comentaba es quién y porqué, o en otras palabras, el coste y empresa encargada de la tecnología, y la razón política o económica detrás de ella.

Y la culpa será del cambio climático II…

cpd.jpgLa verdad es que hay veces que nos pasa poco respecto de lo que nos podría llegar a pasar. En el fondo el ser humano tiene un cupo de suerte razonable, aunque siempre nos parezca poca. No son pocas las organizaciones que gastan sumas importantes de dinero en productos y servicios que incrementan, aparentemente de forma proporcional, la disponibilidad de la información, la confidencialidad y su integridad en el perímetro interior de las organizaciones. Muchos gestores TIC centran sus políticas de seguridad en la protección puertas adentro pero ¿es realmente efectiva, en los tiempos que corren, una política de seguridad que solo contemple el perímetro físico interior de nuestra organización?

En mi opinión no, y si no, piensen ustedes en qué les sugieren las dos imágenes que incluimos en este comentario.

He observado varias reacciones al respecto de esta pregunta, además de la mía propia por supuesto. La reacción inicial dibuja una leve sonrisa en la cara del observador. Al cabo de unos segundos el gesto sonriente se torna en serio, mostrando una cara de preocupación. ¿Será tal vez porque vea a su organización identificada? Pues… tal vez.

mascara.jpgEl hecho cierto es que esta situación se repite constantemente, y no sólo con los hogares de directivos y de personal técnico con privilegios suficientes para tumbar las infraestructuras de su empresa. Las fronteras han caído (ver la entrada «La caída de las fronteras digitales») y desde las áreas de seguridad debemos extender nuestras preocupaciones y ocupaciones allende los muros de hormigón de nuestros despachos. Debemos llegar, virtualmente hablando, a la casa de nuestro Director General, a la casa del Director de Recursos Humanos, a la oficina de la gestoría que nos hace las nóminas o a la red de la empresa que está desarrollándonos esa aplicación para la gestión de clientes.

En el caso del “home office» somos nosotros los responsables de establecer las políticas, de implantarlas y hacer que se cumplan. En el caso de proveedores que tratan información de nuestras organizaciones también somos nosotros los “responsables» de marcar las pautas y, aunque sea el proveedor el responsable de aplicar las medidas oportunas, nosotros deberemos velar por el cumplimiento de las mismas “deber in vigilando»

La verdad es que es sorprendente lo duras que pueden llegar a ser las medidas de seguridad puertas adentro de una organización y lo descuidadas que pueden llegar a estar las mismas organizaciones en su seguridad en el exterior. Pero no se preocupen ustedes, si hay algún problema, como ya les dije la otra vez, siempre podremos decir que la culpa es del cambio climático…

LOPD Google Hacking

He hablado más de una vez a favor de la LOPD, incluso, como el otro día, cuando se trata de defender las nada despreciables multas que su incumplimiento conlleva. Considero que, más allá de consideraciones profesionales, la LOPD es una ley necesaria y aunque por supuesto susceptible de ser mejorada, bastante correcta.

Lo que me parece indignante es que una simple búsqueda en Google proporcione listados de admitidos a concursos públicos de todo tipo de organismos (públicos), y no sólo nombres, apellidos y DNI, sino además, la correspondiente información de admitidos en el cupo de discapacitados, que como saben es un dato especialmente protegido, porque además en las bases se suele indicar el porcentaje mínimo de minusvalía que se requiere para entrar en éste. Entiendo que esta información debe estar disponible para que los interesados comprueben sus calificaciones, si han sido admitidos o no, y el porqué no en este último caso. Entiendo que por una simple cuestión de transparencia, estos listados deben estar accesibles a todos los afectados.

Pero en mi humilde opinión, y al margen de que exista alguna instrucción emitida por la AEPD al respecto, cuando a cualquier pequeña empresa se le exige en ocasiones la aplicación de medidas casi imposibles para poder cumplir con los requisitos de la LOPD y (sobre todo) el RMS, y «habida cuenta del estado de la tecnología» y los recursos casi ilimitados de que dispone la administración, que se produzcan este tipo de actuaciones en el sector público resulta casi burlesco.

(Pueden ustedes buscar con una combinación de las palabras clave «listado», «admitidos» y «discapacidad» si tienen curiosidad…)

Ataques de Inyección SQL (I)

Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. sql_inj_xss.jpgEsta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).

Dejando los detalles técnicos para más adelante, este ataque se basa 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, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection«, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.

Se requiere de varias técnicas y algo de dedicación para poder filtrar este tipo de ataques. De nada sirve, por ejemplo, tener un servidor Web sirviendo páginas cifradas si el atacante puede insertar cualquier tipo de parámetros, lo que además invalidaría un sistema de detección de intrusos, puesto que no podría descifrar los accesos. Hay que tener en cuenta que el atacante intentará aprovechar cualquier información que le proporcione indicios de alguna vulnerabilidad, comenzando por algo tan simple como puede ser la versión de nuestro gestor de base de datos, el nombre de cada una de las tablas, usuarios por defecto,… y así sucesivamente, hasta conseguir en el peor de los casos usuarios con permisos de administración e incluso la ejecución a través de comandos en el propio sistema que soporta la base de datos.

Como en la mayoría de los casos, las tareas que hay que realizar orientadas a prevenir este tipo de ataques no suponen un gran esfuerzo en comparación con el trabajo que supondría restaurar la información de una base de datos que ha sido comprometida, así como la credibilidad de los usuarios al comprobar que se ha detectado un ataque culminado en una base de datos con información relevante, entre otros muchos factores negativos (¿… de cuándo dices que es la última copia …?). Como siempre, evitar el robo de información y el tratamiento no controlado ni permitido de ésta requiere una atención especial.

Sin extendernos más, y como cierre de esta introducción, la seguridad aplicada a la integridad y privacidad de los datos almacenados en las bases de datos no es trivial, pero podemos tener cierto grado de tranquilidad si aplicamos algunas recomendaciones para los distintos casos y métodos de ataque.

[Gráfico de Acunetix.com]