Pues sí, declaro que no me gusta mucho el fútbol, aunque tampoco sea del Comité Antifútbol (ni del comité antitaurino, ni de ningún otro anti). Entiendo, eso sí, ese gusanillo de ver jugar a la selección y el ambiente que conlleva (en algunos casos terminando en insoportable euforia), pero no soporto el griterío, cánticos y banderas que suelen acompañar.
También declaro que mi sonrisa surge cuando imagino, de manera perversa, a los chicos de ETA o PCTV viendo el partido y, en su interior, salirles un ¡España, España! maldito, acompañando las paradas de Iker Casillas.
Pero es que, además de no gustar, ayer tenía otra inaguantable actividad: acompañar a mi hijo Ángel a ver un absurdo espectáculo de Pressing Catch (absurdo porque si ya lo es cuando participan las figurillas, imaginaos como será cuando los protagonistas son conocidos por sus abuelas).
En fin, espero buscar actividades más creativas e interesantes para la final del domingo.
Ya comenté lo loco que me volvió la visualización de esta bitácora con el tema Mandigo por algún error que nunca llegué a descubrir del todo. Lo decía en WordPress, Mandigo, los virus y los misterios el pasado 6 de mayo y al final tuve que optar por poner otro tema (en concreto Talian)
Hoy, veo que ha salido la última versión de Mandigo (la 1.35), la pruebo y funciona tanto en Firefox como en Explorer. ¡Al fin!
En la primera parte comentábamos cómo empezar a obtener datos, centrándolo en las entrevistas familiares y en el registro civil. Por su parte, en la segunda, comenzábamos a ver qué fuentes documentales nos pueden servir para nuestro fin, enfocando la importancia de los libros eclesiásticos.
Aunque volveré a este tipo de documentos de la Iglesia más adelante, en esta tercera parte comentaremos uno de los tipos de fuente documental más utilizado al comenzar estas investigaciones: los censos o padrones municipales.
Los censos y padrones municipales
Podemos catalogar los censos y padrones como fuentes documentales civiles. Desde finales del siglo XIX se establecieron algunos censos electorales, siendo uno de los más amplios y antiguos el de 1890, establecido según Ley del Ministerio de la Gobernación “por la que se establece la obligatoriedad de estar censado y cómo hacer el censo”. Esta ley la podéis encontrar en la Gaceta de Madrid (lo que ahora llamamos Boletín Oficial del Estado BOE), en concreto en fecha 29 de junio de 1890, Gaceta de Madrid 180, páginas 901 a 908.
En este y en otros censos posteriores, se establece cómo realizar el censo, correspondiendo únicamente a varones mayores de edad (entonces mayores de 25 años). Tendremos que esperar a la Segundo República para tener censos con mujeres.
Genealógicamente esta fuente de información es parcial pero interesante. Parcial porque únicamente encontraremos a los ascendientes masculinos de nuestras familias, pero interesante porque se nos dará información más allá de la puramente genealógica: domicilio, profesión, si sabe leer o escribir, etc.
Uno de los problemas fundamentales de esta fuente de información es el de su escasa antigüedad, ya que difícilmente encontraremos censos anteriores a la fecha indicada, aunque en algún caso sí. Tener datos de 1890 supone disponer de información de nuestros abuelos o bisabuelos, cosa que seguramente ya tendremos con nuestro primer tipo de investigación (oral y del registro civil). Además un censo o un padrón nos dice que en esa fecha vivía una persona en concreto en ese lugar, pero no nos aporta dónde nació (fundamental para seguir con nuestro árbol) ni quiénes eran sus padres o abuelos.
La forma de obtener censos es relativamente sencilla: suelen encontrarse en Archivos Históricos Provinciales de las distintas provincias. En algún caso también se encuentran en ayuntamientos u otros archivos, pero por ejemplo en el caso de Zaragoza, los encontraremos en el Archivo Histórico Provincial de Zaragoza (C/ Diego Dormer, 8 50001 Zaragoza, tfno. 976397566, ahpz@aragob.es, ver localización). Allí bastará con dirigirnos a la recepción y pedir el municipio y año que deseemos estudiar; nos dejarán acceso a los microfilms (de muy fácil uso) y podremos sacar las copias en papel que deseemos (bajo una pequeña tasa).
Desde hace algún tiempo, en la Asociación AragónGen, estamos digitalizando los censos que disponemos los asociados y publicándolos en la sección privada de nuestra web. Esto nos permite la consulta de los mismos pero también buscar apellidos, profesiones y datos estadísticos que iremos trabajando y que, más adelante, servirán para una publicación.
Pues sí, tras tres años de obras, molestias, polvo, destrozos, construcciones, moles faraónicas y pequeños sarcófagos secretos, llegó la Expo.
La inauguración me pillo en casa (ya se sabe, niño pequeño, madrugón al día siguiente, etc.) y tomé un poquito de vídeo cutre desde la terraza.
Pasado el fin de semana fuera, hemos ido los tres días (bono noche ad hoc) y sentimientos contradictorios: amabilidad mucha; aspecto en algunos edificios imponente, en otros discreto; contenidos flojitos hasta ahora (sólo he visto pabellones nacionales), alguno incluso malo, directamente; actuaciones buenas (excelente “Hombre vertiente”); y conciertos, por ver…
A pesar de saberlo, tengo cierta desilusión por los pabellones de países. Posiblemente el problema es el recuerdo de los colosales pabellones de Sevilla 92, que ahora son pequeños bazares, en la mayor parte de los casos.
Pero no puedo opinar de mucho más. La organización, de momento, excelente.
Enhorabuena a quien le toca y ya iremos comentando.
Toda una sorpresa, la verdad. He ido esta tarde con mi disfraz más pulido de bitacorero (quien lo iba a decir, vamos) a la presentación de la nueva radio Aragón Radio 2 que comentaba ayer y me encuentro con que me quedaba corto en casi todo. Y es que veo que el proyecto va más allá de lo que se ve (me decía Emiliano, director técnico de CARTV, que ahora solo se ve un 15% de lo que se va a poner en marcha), que es como tiene que ser, actual, comprometido, con vocación de servicio (varias veces repetido por Rosa, directora de Aragón Radio, que además se lo cree, bendita sea), con elementos Web 2.0 ó 3.0 o lo que sea, etc. y que, la verdad, hay unos pedazo de profesionales detrás.
Por eso uno se alegra, motiva que en esta comunidad tan dada a veces a la mediocridad y el desánimo, encontrar a gente que trabaja y bien, tanto en el propio ente como los que han colaborado (que han sido muchos).
Desde que conocí, hace un par de semanas o tres, la nueva radio por Internet Aragón Radio 2, es mi onda habitual en el trabajo. Reúne unas cuantas características que me resultan atractivas: música agradable, posibilidad de ver la programación de canciones, abundantes podcast, informativos breves y, especialmente interesante y novedoso, una web bien desarrollada e integrada con lo que debe ser la Web hoy en día. Y, como no podía ser de otro modo, con una bitácora interesante.
Y me comunica Rosa Pellicero (¿de dónde ha sacado mi dirección?) que el jueves 12 nos la presentan a nosotros los bitacoreros. Pues nada, que intentaré sacar un ratito para tomar una cerveza, ver amigos, conocer a la gente de la radio y visitar las instalaciones.
El lunes y martes (9 y 10 de junio de 2008) han realizado una muestra de danza los chicos del Conservatorio Profesional de Danza de Zaragoza en el Teatro Principal. Esto sirve como botón de muestra del encomiable trabajo que realizan estos niños que sacrifican buena parte de su tiempo libre en esta actividad artística.
Entre todos ellos, mi hija Lucía de 12 años, para mí, claro, es un ejemplo. Su capacidad de sacrificio me admira cada día y se empeña en continuar pese a todos los pesares. Compartimos esas calamidades pero una vez al año se nos “cae la baba” viendo a las artistas.
Dejo la actuación de ayer de 3º de Educación Elemental (donde está Lucía):
Disculpad la falta de calidad pero sirva como simple homenaje.
La semana pasada era atacado un sitio Web alojado por nosotros y, para colmo, realizado también por nuestro equipo. El ataque era trivial, como siempre, mediante inyección SQL (SQL-injection) y había seguido los procedimientos habituales.
Para quien no esté familiarizado, describo a continuación la técnica, bien explicada y masivamente difundida (demasiado, a buen seguro) por Chema Alonso:
Generalidades
Los ataques de inyección SQL se realiza mediante el envío de una sentencia SQL hacia un parámetro o campo de formulario que va a ser leído por una aplicación web para su procesamiento. En otras palabras, los atacantes intentarán completar una instrucción SQL especialmente “maligna” cuando ofrezcamos en una página web un formulario o un parámetro dentro del encabezado (del tipo, por ejemplo, http://midominio.com/listado.asp?id=23).
Esto es empleado, generalmente y menos mal, para cambiar datos en las bases de datos que almacenan la información que se presenta en la web. Y digo “menos mal” porque también podría ser utilizado para borrar una tabla, conseguir un usuario de la base de datos, etc.
Usualmente el fin consiste en cambiar de cara (defacement) de la web para colocar otro texto o imágenes identificando al hacker o con un mensaje alusivo. Estos delincuentes “menores” (ha habido ataques hace muy poco de este tipo que han limpiado webs tan concurridas como la Jazztel, Izquierda Unida y otras; han sido pillados -lee la crónica de Chema Al talego o a por talegos-) parece que pretenden ser los primeros en el top de Zone-h o cosas por estilo, no les da para mucho más. El problema es que los que están detrás sufrimos y mucho.
Técnica
La técnica no es muy complicada y suele ser parecida a la siguiente:
Lo primero es buscar una víctima, pero para eso qué mejor que Google, para eso está. Introducimos una cadena que pueda representar una vulnerabilidad (por ejemplo una búsquda del tipo “inurl:listado.asp?id” y a ver que nos dice el buscador (para comprender mejor esto recomiendo el libro “Hacking Google” de Johnny Long
Una vez localizada una posible víctima, se suele probar a ver si es vulnerable. Las pruebas suelen hacerse intentando romper una cadena y ver lo que canta.
La técnica se basa en romper la sentencia SQL que haya programado el desarrollador y anexar otra sentencia maliciosa.
Imaginemos que presentamos un formulario para buscar un nombre que presenta un campo llamado “apellido”. El valor introducido por el usuario lo tratamos por una página que tendrá una sentencia del tipo "SELECT * FROM usuario WHERE usr_apellido='" & apellido & "' ".
Si un hacker nos introduce “algo de SQL” en el campo “apellido” puede hacer romper la sentencia SQL y realizar otras acciones. En este ejemplo, se podría introducir algo similar a:
Apellido: kk' or 1=1 --
Con esto la sentencia quedaría: "SELECT * FROM usuario WHERE usr_apellido='kk' or 1=1 -- ' "
Observad que esa condición (con el “or 1=1”) se cumple siempre y, por tanto, devolverá algún registro (seguramente el primero aunque no exista el apellido “kk”, ideal para romper formularios de validación). El doble guión medio es usado para que el resto de la sentencia se entienda como comentario (según MS SQL Server, en otros SQL es parecido) y no produzca errores.
Siguiendo así, seguramente probarán distintos valores para conocer nombres de campo, tablas, usuarios, etc. En esto les ayuda nuestro generoso sistema que le va diciendo dónde está el error, con su nombre de campo, tabla, etc. En el ejemplo del ataque sufrimos la semana pasada, el hacker incluso hizo: www.miweb.com/listado.asp?id=Convert(int,(select+user));--
en la URL y nuestro sistema, amable de verdad, le contestó: Error de sintaxis al convertir el valor nvarchar 'usuario_de_la_bd' para una columna de tipo de datos int.
Siguiendo así, al final realizará una sentencia: UPDATE tabla SET campo='Hacked by SuperHackilistico'
y todos los valores tendrán esa cadena, que a buen seguro se lucirá flamante en la página de inicio de nuestra web.
El problema
El problema está en el desarrollo, no en el sistema que alberga la web ni en el de base de datos. Hace tiempo la gente ni se planteaba hacer cosas así, por lo que se programaba sin seguridad de ese tipo, pero hoy en día es muy frecuente este tipo de ataques.
En concreto, el día 28 del mes pasado, recibía un mensaje de Jorge Chinea del INTECO-CERT advirtiendo lo siguiente:
Estimados colaboradores,
En los últimos días se han detectado ataques masivos contra sitios web con el objetivo de manipular su funcionalidad y contenido. Una vez comprometidas, las paginas Web manipuladas redirigirán a sus visitantes a sitios web maliciosos expresamente diseñados para descargar e instalar todo tipo de códigos maliciosos en el ordenador que podrán permitir al atacante su control.
Desde INTECO-CERT se alertó en anteriores ocasiones la existencia de este tipo de ataques para comprometer los sitios web. Se trata de ataques de tipo inyección SQL, aprovechando una vulnerabilidad en el Internet Information Server (IIS), provocada por una errónea programación del código ASP (Active Server Pages).
Estos ataques masivos están apoyados en herramientas automáticas con las que logran infectar gran número de sitios web en poco tiempo. El número total de páginas comprometidas a día de hoy ronda los 1’5 millones, aunque muchas de ellas ya han sido o están siendo corregidas.
Recomendamos a todos los webmasters que tengan sus páginas ASP alojadas en servidores IIS comprobar, lo antes posible, si sus páginas web han podido verse afectadas. Un síntoma claro de la infección puede ser la existencia de código javascript externo desconocido y que apunte a alguno de los dominios indicados en el siguiente listado (y que iremos actualizando):
De cara a los usuarios finales, para evitar infecciones, aconsejamos seguir las recomendaciones básicas que siempre se deben adoptar ante incidentes de seguridad:
* Utilizar software de seguridad como antivirus, cortafuegos, antiespias, etc.
* Tener actualizadas todas las aplicaciones de nuestro sistema, sobre todo sistema operativo y navegador, con los últimos parches de seguridad.
* Utilizar por defecto cuentas limitadas de usuario -no de administrador- con lo que limitaremos en gran medida los efectos de una posible infección.
Usuarios con conocimientos técnicos más avanzados pueden optar por deshabilitar el javascript en el navegador de manera temporal o instalar alguna extensión, como NoScript, que permita tener un control más exhaustivo sobre la ejecución de secuencias de comandos.
Es evidente que los desarrolladores deben prestar más atención en el código y poner filtros que anulen algunos caracteres y sentencias peligrosas.
En nuestro caso, ahora lo hacemos de forma usual, pero es cierto que siempre quedan desarrollos antiguos no actualizados que pueden ser vulnerables.
Contramedidas
Ya que conocemos el problema, solo nos falta ponerle solución. Esta se encuentra “simplemente” en filtrar lo que nos venga a páginas que admiten parámetros (ya sea por GET o por POST). Y digo “simplemente” porque hay que completar código y eso a veces da más que pereza.
El mismo Jorge Chinea planteaba la cuestión de la forma siguiente:
Con respecto a los ataques masivos contra sitios Web de los últimos días hemos estado viendo diferentes soluciones:
1.- La solución definitiva, que sería revisar todas las paginas asp verificando la entrada de datos para que no permitan inyecciones de SQL.
2.- El parche para las inyecciones que modifican datos: Usar un usuario para las consultas genéricas de la base de datos con permisos de solo lectura en las tablas y otro para la administración de la web, añadir/modificar contenidos… Con esto ya no se podrían modificar datos en la web
Pero me parece mucho más elegante otra solución que se planteó en el mismo foro (denominado RESCATA -Red Nacional de Sensores Antivirus- en la que colaboro) ofrecida por Juan Cascón de Vocento-ABC y que incluyo a continuación:
Function ControlSQLInjection(texto)
' Autor: Juan Cascón: xxx@abc.es
on error resume next
Dim res
res = LCase(texto)
res = Replace(res, "[", "[[" & Chr(0))
res = Replace(res, "]", "[]]")
res = Replace(res, "< ", "")
res = Replace(res, ">", "")
res = Replace(res, "script", "")
res = Replace(res,"select","")
res = Replace(res,"table","")
res = Replace(res,"create","")
res = Replace(res,"insert","")
res = Replace(res,"update","")
res = Replace(res,"delete","")
res = Replace(res,"drop","")
res = Replace(res,"exec","")
res = Replace(res,"declare","")
res = Replace(res,"alter","")
res = Replace(res,"union","")
res = Replace(res,"null","")
res = Replace(res,"schema","")
res = Replace(res,"execute","")
res = Replace(res,"-","")
res = Replace(res,";","")
res = Replace(res,"""","")
res = Replace(res, "[[" & Chr(0), "[[]")
res = Replace(res, "'", "''")
res = Replace(res, "%", "[%]")
res = Replace(res, "_", "[_]")
res = Replace(res, "#", "[#]")
res = Replace(res, CHR(13), "")
res = Replace(res, CHR(10), "")
res = Replace(res, CHR(0), "")
res = Replace(res, "=", "")
res = Replace(res, "&", "")
res = Replace(res, "$", "")
res = Replace(res, "@", "")
res = Replace(res, "(", "")
res = Replace(res, ")", "")
res = Replace(res, "\", "")
res = Replace(res, ",", "")
res = Replace(res, "\'", "")
res = Replace(res, "+", "")
ControlSQLInjection = res
End function
Invocando a esta función en cada recepción de datos de un formulario o enlace, podemos considerar que estamos protegidos frente a este tipo de amenazas.
Me llamo Antonio y tengo cuarentaytantos. Trabajo como profesional TIC en una empresa de Zaragoza. Casado, dos hijos y una vida muy normal...
Algunas aficiones confesables y otras inconfesables. Genealogía, fotografía, montaña, deporte, lectura y la convergencia afición-profesión: sistemas, Internet, programación, ...
Alguna pasión: mi tierra, Aragón; y algún objetivo: Desperta ferro!
Entradas (RSS)