Hace algunas semanas hablábamos de Publicar en Twitter las entradas de este sitio usando Python y prometíamos hacer lo mismo con Facebook.

Echando un vistazo al API de Facebook y haciendo algunas pruebas me encontré con que no podía publicar enlaces con su texto (Facebook los transforma para que podamos pinchar en ellos, pero no permite -o no encontré la forma- que los pongamos con su texto y esas cosas). Por otro lado, quería experimentar con la posibilidad de publicar las entradas de esta bitácora completas allí; Facebook no favorece que introduzcamos textos largos porque nos muestra un trocito y permite abrir ‘el resto’.

Siempre me ha llamado la atención la ‘netiqueta’ de algunas listas de correo donde suele ponerse al lado del texto de los enlaces un número y al final del mensaje la lista de esos enlaces, cada uno asociado al número correspondiente.

Esto fue lo que decidí hacer para publicar en la página de Facebook de fernand0.github.io (y otras, claro). El programa que traemos hoy hace justamente eso, como paso previo a la publicación en la página de Facebook (y, tal vez, ¿para poder enviar las entradas por correo a los interesados?).

El programa puede verse en rssToLinks.py (apuntamos, como siempre, la versión actual por si hubiera cambios en algún momento).

Algunas formas de extraer los enlaces serían: buscarlos con expresiones regulares, o también con algún parser de HTML (en el Blogómetro hace años utilizábamos el Simple SGML parser. Buscando un poco encontré el proyecto Beautiful Soup que presume de ser una manera rápida de recorrer el contenido de una página web y decidí darle una oportunidad.

Para utilizarlo incluímos los módulos necesarios. Para obtener el contenido utilizamos la fuente RSS, así que también necesitaremos feedparser:

import feedparser
from bs4 import BeautifulSoup
from bs4 import NavigableString
from bs4 import Tag

Leemos la fuente RSS y vamos recorriendo las entradas:

feed = feedparser.parse(url)

for i in range(len(feed.entries)):

Y empieza la ‘magia’ de Beautiful Soup:

        soup = BeautifulSoup(feed.entries[i].summary)
        links = soup("a")

Esto es, le pasamos los datos al analizador, y lanzamos la pregunta de lo que queremos extraer. En este caso tenemos una entrada en el summary y queremos obtener los enlaces (etiqueta a) para la entrada que ocupa la posición i. Nos devolverá una lista de elementos html que incluyen dicha etiqueta.

En algunas entradas ponemos imágenes, que no queremos que aparezcan en el texto, así que utilizamos isinstance para comprobar si dentro del contenido del enlace hay otra etiqueta para evitarla (¿es posible que encontremos algún caso más adelante que sea problemático?). Recorremos la lista de enlaces (que vienen con las etiquetas y todo, claro). Ademas utilizamos el contador j para ir asociándoles números a los sucesivos enlaces (en el HTML original, todavía no lo hemos eliminado):

	j = 0
	linksTxt = ""
	for link in links:
		if not isinstance(link.contents[0], Tag):
			# We want to avoid embdeded tags (mainly <img ... )
			link.append(" ["+str(j)+"]")
			j =  j + 1

El contenido del enlace (ahora que ya sabemos que no es una etiqueta HTML) estará en link.contents[0] (puede haber más contenido, nuestros enlaces suelen ser ‘sencillos’).

	linksTxt = linksTxt + "["+str(j)+"] " + link.contents[0] + "\n"

El enlace está en link['href'].

	linksTxt = linksTxt + "    " + link['href'] + "\n"

Ahora necesitamos el texto del HTML:

	print soup.get_text()

En algunos casos el texto puede tener muchos saltos de línea, espacios, … Se podrían eliminar. Nuestras entradas suelen estar bien estructuradas y no aparece ese problema.

Ahora, si había algún enlace (¿publicaremos alguna vez una entrada sin ningún enlace?), lo añadimos al final:

	if linksTxt != "":
		print
		print "Links :"
		print linksTxt

El tema de los números aleatorios de calidad para aplicaciones con requerimientos de seguridad no aparece habitualmente más que en los comentarios más técnicos. En Proper use of Java’s SecureRandom hay un texto donde se comenta el uso del generador de números seudo aleatorios seguro de Java.

When generating random numbers in Java for cryptographic purposes, many developers often use the java.security.SecureRandom class. And while the java.security.SecureRandom class is designed to generate cryptographically secure random numbers, there are a few subtleties in the API, and if it is used improperly the output can become predictable. At Cigital we have witnessed a number of cases where this is true. The following is a guide to the proper use of Java’s java.security.SecureRandom class.

Los consejos:

• Always specify the exact PRNG and provider that you wish to use. If you just use the default PRNG, you may end up with different PRNGs on different installations of your application that may need to be called differently in order to work properly. Using the following code to get a PRNG instance is appropriate: SecureRandom sr = SecureRandom.getInstance(“SHA1PRNG”, “SUN”);
• When using the SHA1PRNG, always call java.security.SecureRandom.nextBytes(byte[]) immediately after creating a new instance of the PRNG. This will force the PRNG to seed itself securely. If for testing purposes, you need predictable output, ignoring this rule and seeding the PRNG with hard-coded/predictable values may be appropriate.
• Use at least JRE 1.4.1 on Windows and at least JRE 1.4.2 on Solaris and Linux. Earlier versions do not seed the SHA1PRNG securely.
• Periodically reseed your PRNG as observing a large amount of PRNG output generated using one seed may allow the attacker to determine the seed and thus predict all future outputs.

Esto es, especificar el generador que se va a utilizar explícitamente (para evitar terminar utilizando diferentes generadores en diferentes configuraciones e instalaciones); cuidado con que la incialización se haga de manera correcta (e imprendecible); las versiones recomendadas eran en aquel momento JRE 1.4.1 para Windows y JRE 1.4.2 para Solaris y Linux por lo menos; reinicializar la semilla del PRNG para reducir la utilidad de la información generada.

El otro día hablábamos del Generador de números aleatorios de Intel y allí se pueden encontrar un par de enlaces más sobre el tema.

La autentificación parece ser el gran problema de los últimos tiempos: elegimos malas contraseñas, picamos con facilidad en muchos sitios que nos engañan para que las divulguemos ….

Las soluciones tecnológicas existen, y se pueden utilizar: pero en muchas ocasiones estaremos consiguiendo molestar a nuestros usuarios, que reutilicen contraseñas o que hagan todo lo posible para no seguir nuestras directrices (o peor: irse con la competencia).

Por eso me gustó Risk-based Authentication: A Primer donde se introduce la idea de mezclar la autentificación con una estimación del riesgo (que es, por otra parte, lo que creo que están haciendo últimamente muchos sistemas de uso masivo): se asocia a la sesión una ‘puntuación’ que determina si nuestros parámtros son ‘normales’.

Esto es, mira la localización geográfica, datos de conexión, pautas de comportamiento… Se trata, en definitiva, de ver si todo parece razonable o hay algo que no se ajusta a lo habitual y en caso de que haya motivos para desconfiar se toman medidas adicionales:

If the risk score for a user’s access attempt exceeds the system’s risk threshold, authentication controls are automatically elevated, and the user may be required to provide a higher level of authentication, such as a PIN or token. If the risk score is too high, it may be rejected outright.

Ya hemos hablado en vidas anteriores de la seguridad y los coches: es el caso típico de una cierta configuración, pensada en un contexto que de pronto (o poco a poco) cambia sin adaptarse a los nuevos riesgos. Esta vez traemos un artículo generalista de divulgación, Car hackers mess with speedos, odometers, alarms and locks.

Por ejemplo, acceso a la red de comunicación interna:

… they gained access to the CAN and began fuzzing against to identitfy which of the arbitration ID packets were sent to particular components of the vehicle such as the speedometre, brakes and dashboard indicators.

Incluso poniendo a disposición de otros una herramienta:

The trio were keen for others to enter the hacking field and have produced a $25 open-modular source hardware tool for reading CANs that has the capability of those worth tens of thousands.

Como decía, hemos hablado más veces de este tipo de ataques a coches:

¿Pueden atacar tu coche?

Más ataques a coches

Seguridad ‘hogareña’

El coche, el mp3 y cosas malas que pueden suceder

Ataques a los sistemas de arranque sin llave en coches

Los sistemas de inmovilización de coches no funcionan bien

Un compilador no sólo genera código ejecutable a partir de nuestros programas escritos en un lenguaje de alto nivel. Tradicionalmente los compiladores han tratado de mejorar el código desarrollado por los programadores para hacerlo más eficiente (sacando partido de las características de la arquitectura en la que se va a ejecutar, los mecanimos de los procesaores, sus recursos…).

Compilers are great at taking your hand crafted human-readable program, translating it into machine code and, in the process, optimizing it so it runs as efficiently as possible

Los investigadores del MIT Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek y Armando Solar-Lezama han presentado un artículo donde se evalúan las consecuencias de seguridad que puede tener la eliminación de código que puede hacer el compilador por ser considerado innecesario.

… research from MIT points out, in their zeal to optimize your code, compilers can go too far and remove code that they shouldn’t, which can make the system or application more vulnerable.

También han desarrollado una herramienta, que nos avisará del código que es susceptible de tener este tipo de problemas, para que lo podamos arreglar:

The good news is the researchers have developed a model and a static checker for identifying unstable code. Their checker is called STACK, and it currently works for checking C/C++ code. The idea is that it will warn programmers about unstable code in their applications, so they can fix it, rather than have the compiler simply leave it out. They also hope it will encourage compiler writers to rethink how they can optimize code in more secure ways.

En Dude, where’s my code? se pueden ver más ideas y algún ejemplo:

A classic example, explains Xi Wang, a graduate student in EECS and first author on the new paper, is the assumption that if a program attempts to store too large a number at a memory location reserved for an integer, the computer will lop off the bits that don’t fit. “In machines, integers have a limit,” Wang says. “Whenever you exceed that limit, the input value basically wraps around to a smaller value.”

Seasoned C programmers will actually exploit this behavior to verify that program inputs don’t exceed some threshold. Rather than writing a line of code that, say, compares the sum of two numbers to the known threshold for an integer (“if a > int_max - b”), they’ll check to see whether the sum of the numbers is smaller than one of the addends (“if a + b < a”) — whether, that is, the summation causes the integer to wrap around to a smaller value.