JavaScript debe desaparecer de la Web

script

En recientes días escribí un post sobre cómo hacer nuestra navegación más segura usando Opera (en inglés). El principio de operación es simple: deshabilitar JavaScript por defecto excepto para aquellos sitio en los que plenamente confío.

No fue capricho. En alguna ocasión mordí un anzuelo y, sin intención, mi PC participó en un ataque masivo contra Freenode. ¿Cómo ocurrió? Visité una página que tenía un código malicioso de JavaScript, el cual se ejecutó automáticamente (tal vez gracias a onMouseOver o a onLoad) y mandó spam a dicha red. Me bloquearon varias horas y tuve que contactar a los administradores para explicar el caso. Ellos lidian con este tipo de cosas todo el tiempo (¡señal!).

alvarezp-banned

No es el único tipo de problema de seguridad de JavaScript. Tampoco es el único ataque facilitado por JavaScript: como referencia les dejo XSS, X/CSRF, Clickjacking, Revestimiento de interfaz (UI redressing), fuga de datos personales, etc. No que requieran de este lenguaje, sino que con él son mucho más fáciles de implementar sin que el navegador pueda detectarlos.

Busqué formas de evitar llegar a esa conclusión; después de todo, la mayoría de los sitios Web usan JavaScript. ¿Es posible que el navegador sólo ejecute código bien intencionado? No. Una computadora es tonta. No puede distinguir código malicioso. Incluso existe una broma sobre el tema. ¿Cómo le hacen los antivirus? Se basan en firmas y bases de datos alimentadas por humanos y aún así a veces arrojan falsos positivos. Peor aún, también arrojan falsos negativos.

Sin embargo yo necesito una forma de confiar en mi PC. En el momento en que pierde mi confianza, no sé si está interceptando lo que tecleo o lo que transmito, o si las páginas que me muestra son ilegítimas, o si los programas está alterados de otro modo. No sé si mis passwords y datos de tarjetas de crédito están siendo transmitidos por la red a algún cibercriminal. Y no, no estoy exagerando. Desde el momento en que pierde mi confianza tengo que aplicarle un análisis forense, aunque, por lo general, sale más rápido reinstalar.

Sigue leyendo

When is a protocol a tunneling protocol?

This is a note on episode 102 of the fantastic-as-always Packet Pushers Podcast. Initially it was going to be destined for them and less than 140 characters long but I just couldn’t, so I started writing freely and all of this came up.

So, the whole episode is about analyzing if is MPLS tunneling. Maybe somebody asked the question or maybe there is some disagreement in the industry.

I found it very interesting (and fun, as usual) but after listening to the show it got me thinking: it’s the wrong question. It’s not if MPLS is tunneling, but if MPLS *can be used for* tunneling.

So before going deeper I also have to say that I have never implemented MPLS; I have labbed it but that’s about it. I don’t consider myself to have enough foundations or experience as these guys. I hope not to shoot myself in the foot. With that said…

Tunneling is an application of encapsulation. Transport, multiplexing and delivery are other applications of encapsulation. Protocols encapsulate their payload. I see Ethernet as layer 2 «delivery», IP as layer 3 «delivery» (or «transport» across multiple layer 2 domains), and 802.1Q as 1-factor multiplexing. I’m thinking TCP and UDP are 2-factor multiplexing.

I think we agree that IPv4 and IPv6 are network protocols, but you can create a tunnel with Hurricane Electric by setting the Protocol to 41 in IPv4, and without using GRE. The tunnel gets created by the way they are stacked and used.

So a valid question can be stated: am I setting up a tunnel when I start LDP and MPLS? So, from my point of view, the following are requirements for a tunnel to be made:

1. It is set up by or for a user outside of the domain of the transport network (even if the user is a network engineer in a data center). If I create a tunnel over the Internet, I’m the user outside of my ISP’s network. Note that I can tunnel over my own enterprise network; there is some interest in doing that and I’m the end user for that particular case. This takes away MPLS, but not MPLS VPN.

2. The tunnels created deliver the packet between two endpoints but neither of them are the final destination; or… well, technically yes, it can, but my point is that there is another endpoint higher in the OSI layers, even if it ends up being the same one. Once a packet gets delivered it gets decapsulated and further processed again for its delivery. Yes, Ethernet may fit here, but it doesn’t fit #1.

3. Two same or different delivery protocols with usually different address spaces are stacked onto each other. As such, there must be source and destination endpoint addresses endpoints in the encapsulated packet and in the lower-layer protocol. You may use the same address space, but most of the time it’s only a trick to get around some weird limitation. Oh, wait, just like tunnels! 😉

So, by how it works, no protocol is a tunneling protocol (well, except maybe IPSec in tunnel mode). It’s only by what it was designed for that can be called a «tunneling protocol».

Examples:
* ICMP is not a tunneling protocol but it can be used to create tunnels.
* Same for HTTP.
* It can be said that GRE is a tunneling protocol, but it doesn’t work by creating tunnels, but by encapsulating packets and making it easy to layer a protocol on top of another.

Was MPLS designed to do tunnels?

Best regards.

stats.gawk

$ cat bin/stats.gawk 
#!/usr/bin/gawk -f

{
	d = $1 ~ /^[0-9]/;
}

d && !f {
	M = $1;
	m = $1;
	f = 1;
}

d && $1 > M {
	M = $1;
}

d && $1 < m {
	m = $1;
}

d {
	c += 1;
	s += $1;
	ss += $1*$1;
}

END {
	OFS = "t";
	a = s/c;
	print "cnt,min,max,sum,avg,stdev:", c, m, M, s, a, sqrt(ss/c-a**2);
}

Ejemplo de uso:

$ ls -s1 | ./stats.gawk
cnt,min,max,sum,avg,stdev:	53	4	33064	78860	1487.92	6125.08

Super Happy Dev House, Tijuana, 24 de marzo de 2012

Invitación al SuperHappyDevHouse Tijuana, marzo 2012.

Cartel SuperHappyDevHouse Tijuana, marzo 2012.

Esto es muy simple. A desarrollar se aprende desarrollando. Este 24 de marzo (sábado) de 2012 estaremos reuniéndonos en el SHDH Tijuana a ver qué sale. 🙂 Algunos van a trabajar sobre proyectos de su página, otros sobre proyectos de negocio, otros van a ver qué hay de nuevo en el desarrollo de software, etc. La mejor forma de conocer en una comunidad local es participando. Así que no hay más: regístrate y llégale.

Nos vemos ahí. Lleva tu laptop y tu multitoma o extensión. Sugiero que te lleves todas las herramientas instaladas porque todavía nadie dice que va a llevar Internet… o mejor aún, lleva Internet. 🙂

Tweaking Opera for safer Web browsing

Sometimes I deeply hate the Opera browser, as with its RAM consumption behavior, but most of the times I just love it.

One of the reasons I do is because it allows me to pretty easily tweak my browsing safety.

There are several aspects to browsing safety. When working on your own computer the most important one after having an updated browser is JavaScript.

JavaScript is really useful, as it allows you to make websites interactive, but it can be easily misused to do all kinds of bad stuff, from personal tracking to attacking IRC networks, passing through personal information stealing, cross-site scripting, clickjacking, etc., even if you use Linux, Mac OS or any other non-Windows operating system. Although not strictly necessary, most of the new browser-related attack vectors require JavaScript to work or be useful.

Sigue leyendo